Visual Studio cannot start debugging because the debug target is missing. - by zach bonham

Status : 


Sign in
to vote
ID 526352 Comments
Status Active Workarounds
Type Bug Repros 1
Opened 1/21/2010 11:33:41 AM
Access Restriction Public


Windows 7 x64, 2MB RAM
Visual Studio 2010 Beta 2
WPF application targeting .NET 4.0

This is the first time I have seen this.  I do not know if its a low memory condition (~600MB), or what, but when I [F5] to run the application under the debugger I see this message (below).

Restarting VS2010 seemed to clear the issue.

I have a memory snap of the process just prior to the restart if you feel it might help.  

e.g. adplus -hang -p [xxxx]

Microsoft Visual Studio
Visual Studio cannot start debugging because the debug target 'D:\dev\FO\DEV\Iteration\SAM Portal\MaryKay.SamPortal.TestHarness\bin\Debug\MaryKay.SamPortal.TestHarness.exe' is missing. Please build the project and retry, or set the OutputPath and AssemblyName properties appropriately to point at the correct location for the target assembly.

Sign in to post a comment.
Posted by Program.X on 11/30/2011 at 8:32 AM
I'm now having this issue. I've restarted. I have an Mvc app and Console app that start fine in Solution. Same solution has WinForms and another Console app and they consistently fail to generate exes.
Posted by wangyuan9 on 10/25/2011 at 8:33 AM
has this problem been solved yet?
Posted by CucaMacaii on 4/18/2011 at 9:11 AM
I can reproduce this anytime. My project would not create an exe no matter what I do. It used to build exe up to a few days ago. Since then, it stopped. I have reloade my project. I have changed almost all the settings and properties. I have wasted ONE FULL DAY hunting this #&*^$&*#^ issue. Debug or release. It says Build Succeeded, but there's no exe to be had. I only have an exe from last thursday. What am I supposed to do now ? Should I start to build a completely new project ? I have A LOT OF FORMS, files, classes, resources, etc, in this project !

Thank you.
Posted by Greg Dirst on 4/7/2011 at 11:39 AM
I was able to get this by setting the start up project as a project that was not configured to run in configuration manager. I simply checked the project under configuration manager and it worked fine.
Posted by PCTO on 3/29/2011 at 10:29 PM
I get this same error message in VS 2010 SP1 on windows 7 x64. It did not occur originally, but now no matter what for this project, changes are not detected and if I do not manually build before attempting to debug, it will simply run the last build, or if I have "cleaned" the project or solution, I get this message:

Visual Studio cannot start debugging because the debug target "path to exe" is missing. Please rebuild the project and retry.

Changing settings in Debug->Projects and Solutions->Build and Run to "always build" does nothing. The setting sticks, but it is as if the ide or debugger is unable to detect that the project is out of date, and therefore do a build. Very annoying bug in visual studio!
Posted by SBTeam on 8/13/2010 at 4:46 PM
I can reproduce this consistently with VC# Express for Phone:

-Create new XNA Windows game project in the default location (Docs/VS 2010/ Projects/...)
-Copy the project folder to a new location

Project no longer builds and instead runs the existing exe (if one exists). Clearing the bin, obj, *.user, ... and all other temp folders and files (which usually clears VS's cache) results in the above error and no chance of fixing the project.

Forcefully rebuilding will create the exe, however changing any related project files will not cause the project to build, so the out of date exe runs instead.
Posted by Cliff W Estes on 4/16/2010 at 4:41 PM

I am developing in VS.NET 2008 Express.

I have started a new project, using the project template for .NET plugins provided by Robert McNeel and Associates. The project is a plugin for the popular surface modeling product, Rhinoceros. When I first start working on the project, if I press the build menu item and then click on "Build BOMsAway" Everything works. I can even debug the project in the IDE, which opens a session of Rhinoceros and takes commands from the Rhinoceros command line.

This works fine for about twenty (or so) builds and then all of a sudden I get the error message "Visual Studio cannot start debugging because the debug target 'D:\VB.NET Code\BOMsAway\BOMsAway\bin\Debug\BOMsAway.dll is missing' "

If I start a brand new project and repeat the process, after twenty or so successful debugging sessions, I get the same error.

My output directory is set to "\bin\Debug" and my project is in ":\VB.NET Code\BOMsAway\BOMsAway\"

Posted by Izzy [MSFT] on 3/24/2010 at 1:09 PM
Zach - thanks for the PM follow-up. It seems that our performance work between Beta 2 and RC1 has fixed your particular issue. I'm glad to hear that VS is now more stable and this problem is not happening.

I'll resolve this as "Fixed."

-- Izzy
Posted by Izzy [MSFT] on 2/3/2010 at 2:51 PM
Thanks for the additional information. I wonder if there's something funky going on with your configurations/platforms for the project, since I really cannot explain the behavior that you're seeing. Would it be possible for you to send us the project with which you can repro this problem?

You can also mail me directly offline at

-- Izzy
Posted by zach bonham on 2/3/2010 at 11:25 AM

The plot thickens...I've been getting reports of users VS2010 on our team reporting that VS gets stuck in 'Debug' build configuration, even though its set to 'Release' via the configuration manager toolbar.

The symptoms of this is that they don't see changes they expected to see when hitting 'F5' in a 'Release' configuration. I don't know if this is related to my issue or not. Just thought I'd mention it. When a developer feels they are experiencing this bug they switch the configuration from 'Release' to 'Debug' and then back to 'Release'. This seems to solve the problem. I'll try this when I experience this again to see if it helps.

The particular problem I am encountering doesn't happen all the time (consistently) - it definitely seems to happen during a low memory period, where virtual memory is ~1.2GB for the devenv.exe process.

To answer your questions:

1) I do have Tools | Options | Projects and Solutions 'Show advanced build configurations checked. When I've experienced the problem, I've confirmed that I had 'Release' build configuration selected - which is our default build configuration based on the project I"m working on. We determine whether to use stubbed dependency services, or real services, based on whether the configuration is 'Debug' or 'Release'.

2) My Tools | Options | Project/Solutions | Build and Run 'On Run, when projects are out of date' is set to "Prompt to build".

Sorry that this issue is not more readily reproducible!
Thanks for your time!

Posted by Izzy [MSFT] on 2/2/2010 at 2:13 PM
Hi - thanks for providing the logs.

The build log shows that the configuration you're building is "Release" (which by default goes to the bin\Release folder, as the build log shows). However, when you F5, you are actually trying to run the "Debug" configuration.

I was thinking of ways in which this could happen... The only way that I could think of (and actually reproduce locally) was if the following are true:

[1] You're in the Simplified Configurations profile - that is, "Show advanced build configurations" is unchecked under Tools->Options in the Projects/Solutions section. Unchecking this will cause Visual Studio to automatically switch the configuration to Release when you do a build and to Debug when you hit F5. (Otherwise, if this box is checked, the configuration is controlled by the Configuration Manager, which you can access from the Build menu).

[2] You have the option on what to do when projects are out of date set to "Never build." Go again to Tools->Options, expand the Projects/Solutions node in the tree on the left hand side, and click on "Build and Run" under Projects/Solutions. You should see a dropdown labelled "On Run, when projects are out of date:" Make sure that is set to either "Always build" or "Prompt to build".

Do these solve your issue?

-- Izzy

Izzy Gryko
Lead Software Design Engineer
Microsoft Visual Studio Platform Development
Posted by zach bonham on 1/27/2010 at 3:25 PM

I dialed the up to 'diagnostic' for the trace level. If you look at the bottom of the output you see that the build was successful, yet I still get that original message. See attached build log and screenshots from task manager and process monitor.

I am NOT able to reproduce this at will. It very well might be low memory condition. Also, I might be running 'lean' on disk space.

I have < 5GB free on my Windows Partition. This is also where Visual Studio 2010 is installed. I have < 6GB free on the source partition, which is where source files, references, etc, are located...if this has any bearing.

Posted by zach bonham on 1/27/2010 at 11:16 AM

I've been unable to reproduce this issue. If it happens again, I will turn up the verbosity of MSBuild and post that to the issue. I didn't think of that when the issue was occurring unfortunately.

At the time, I was able to verify that the file did actually exist in the output directory.

Thanks for your time!


Posted by Mike Danes on 1/27/2010 at 9:56 AM
Not sure if this is the case here but I've seen this happening after changing the target framework while the build configuration is set to 'Release'. What seems to happen is that VS builds the 'Release' version and the debugger tries to start the 'Debug' version which might not exist.
Posted by Izzy [MSFT] on 1/27/2010 at 9:35 AM
Hi -

This is a bit puzzling - it could be that the build output is really missing from disk, or it could be that the low-memory condition is exacerbating the issue. I'll see what I can gather from the dump file you uploaded, but if you could also email me a diagnostic-level build output log from MSBuild, that would provide some additional information for me to help diagnose this problem.

To get this diagnostic verbosity log, go to Tools/Options, select Projects and Solutions -> Build and Run in the left-hand pane, and then make sure to select "Diagnostic" for the verbosity option dropdowns that appear in the tools/options page.

-- Izzy

Izzy Gryko
Lead Software Design Engineer
Microsoft Visual Studio Platform Development
Posted by zach bonham on 1/26/2010 at 8:38 AM
C# is the language and the only add-in i have installed is the 'Windows Identity Framework Add In'. The project is a Windows WPF application if that adds anything?

Posted by Microsoft on 1/26/2010 at 12:52 AM
May I know what what language you are using (VB or C#)? Do you have any third party extensions installed?
Posted by zach bonham on 1/25/2010 at 10:44 AM
I finally was able to upload a memory snap of the process when the dialog was still visible. I don't expect you to be able to reliably reproduce, just hoping that something in the memory snap might give a clue.

Posted by Microsoft on 1/25/2010 at 12:30 AM
Thanks for reporting this issue. In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided.

Please give us more detailed information to reproduce this issue so that we can conduct further research.

It would be greatly appreciated if you could provide us with that information as quickly as possible. If we do not hear back from you within 7 days, we will close this issue.

Thanks again for your efforts and we look forward to hearing from you.

Visual Studio Product Team
Posted by Microsoft on 1/24/2010 at 5:42 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(