Press F5, expect a debugger, get a dialog that says “Unable to start debugging” instead. It is a bad error message because it tells you nothing about which layer failed, and the instinct it triggers is the wrong one: you go read your code.
Your code is usually fine. The source article makes that point up front, and it matches how this failure actually behaves. The debugger not attaching is normally a configuration or environment problem, which is a different category of bug than a logic error and needs a different search order. Below is that order, four checks deep, ending at the point where escalating to vendor support is the reasonable move rather than an admission of defeat.
Check the startup project first
A solution with multiple projects needs one of them explicitly marked as the startup project before the debugger has anything to attach to. Per the source article, the startup project runs first, and running first is what lets it load the libraries or data the other projects depend on. Skip that and you get a debugger with no target.
Setting it is four steps in the IDE:
- Solution Explorer. Use the context menu on your main project in that tab.
- Set as Startup Project. Choose that entry from the menu that appears.
- Properties. Reopen the context menu on that project and select it.
- Debug tab. Verify the Enable Debugging box is ticked.
Where that last checkbox lives depends on the project type, and this is the part people miss. Web projects put it under the Web tab rather than Debug. C++ projects keep it under Debugging, then Launch. Python and Node.js projects each have their own debugging options to look at instead. If you go looking for a Debug tab that does not exist for your project type, you have not found a bug, you have found a different tab.
This check is first for a reason worth stating plainly: it is the cheapest one, it requires no restart, and on a multi-project solution it is the most likely single cause.
Retry IIS Express for ASP.NET and PHP projects
IIS Express is a debugging dependency for certain project types on both the ASP.NET and PHP side, and the source article flags something easy to overlook about it: the utility ships with Windows, not with Visual Studio. An installation that is missing or out of date can leave the project without a proper build, and the failure surfaces as a debugger that will not start.
Repairing it happens outside the IDE. Search Windows for “Programs” and open the first result, which should be Programs and Features, though you may land in Control Panel and need to navigate from there. Locate the IIS Express entry, select it, then run either Change or Repair. Let it finish, restart the PC, then try the debugger again.
If that does not clear it, there is a second setting inside Visual Studio. Under Tools, then Options, look in Web Projects for the setting that switches IIS Express to its 64-bit build and enable it. That toggle is worth knowing about because nothing in the error message hints that a bitness mismatch is involved.
Editorial note rather than source guidance: this check only applies if your project type actually uses IIS Express. On a desktop or console project it is a detour, so confirm the dependency before spending a reboot on it.
Force a rebuild of the launch settings
Visual Studio stores the variables it needs to run a project in a file called launchSettings.json. When an entry in that file is wrong or corrupted, the debugger fails to start, and no amount of reading your source code will show you why.
The fix is to delete the file and let the IDE regenerate it:
- Close Visual Studio completely. Not just the solution.
- Find the file. Look in the project’s Properties folder, though some projects put it under
.vsinstead. - Delete it. The IDE recreates it on load.
- Reopen and rebuild. Load the project, choose Build, then Rebuild Solution, then press F5.
Two details make this check less alarming than deleting a file usually sounds. The file is generated configuration rather than source, and the rebuild step is what forces the IDE to write a clean copy. Still, this is the first check on the list that destroys something, so it belongs after the two that do not.
Rule out the antivirus
Antivirus software can interfere with the debugger by blocking internet access to the temporary files it creates, and the source article is explicit that this includes the stock Windows Defender rather than only third-party products. That distinction matters, because plenty of people conclude they have no antivirus to blame on a machine that ships with one enabled.
Testing it means turning protection off temporarily. Open Windows Security, go to Virus and threat protection, open Manage settings, and disable the real-time protection toggle, approving the User Account Control prompt that follows. Then return to the IDE and press F5 once more. Third-party products follow the same shape from their own control panel: switch off both the always-on scanner and its online lookups, and per the article, keep your browser closed during that window.
The important half of this check is what you do when it works. Re-enable the protection you disabled, then register exclusions covering both the IDE’s install directory and the folders your projects live in. Leaving protection off is not a fix, it is an unpatched hole with a working debugger sitting next to it.
Trade-offs
Each of these checks costs you something, and the costs are not equal.
The startup project check is nearly free, which is why it goes first. The IIS Express repair asks for a PC restart, so it interrupts whatever else you had open. Deleting launchSettings.json throws away whatever was in that file, and if someone on your team had hand-edited a profile in there, regenerating it loses that edit. The antivirus check trades security for a diagnostic signal, briefly, and only pays off if you remember to re-enable protection and add exclusions afterward.
There is also a scope limit worth naming. This list covers configuration and environment causes. A debugger that will not attach because of a genuinely broken build, a missing runtime, or a corrupted installation is a different problem, and the source article’s own escalation path acknowledges that: when debug-setting changes come up empty, the next move is repairing the IDE itself, either from Settings or by launching its bundled patcher or installer. It also recommends launching the IDE elevated to rule out permission problems on the files it touches, which is a one-line check you can try at any point in this sequence.
And past the repair step, the answer is support. The article points at the vendor’s help resources, whether that means the general IDE channel or the one dedicated to whichever language environment you are running, as the place where current fixes appear first. That is not a cop-out. Debugger integration changes between IDE versions and runtime versions, so the newest known workaround for a given combination is more likely to live in a support article than in a general troubleshooting list.
What I would tell past me
Stop reading the code when the debugger will not start. The error is about attachment, not about logic, and the two failures live in different places. Work outward from the IDE instead: project configuration, then the external utility the project depends on, then the generated config file, then the security software watching the whole thing.
Order matters more than completeness here. Four checks in the order above cost you one context menu, one reboot, one deleted file, and one brief security toggle. Four checks in the wrong order cost you a reboot to fix a problem the first context menu would have solved.