My only OS-level development experience was in grad school, but I suspect what is happening is this (or something similar):
An error happened while running the last instance that the debugger tried to handle, but some other issue caused that to fail (maybe a debug assertion was encountered, but before you could click on the dialog to Abort/Retry/Ignore, another break was triggered, maybe due to a null pointer). The result, after you stopped debugging, was that the debugger was still waiting for your response to the first debug assertion, so it wouldn't let the process terminate. But then the debugger terminated when you stopped debugging (or did it?), turning the process into a zombie, or its tree into zombies. When you tried to kill the zombie process, an error similar to this happened, but task manager didn't tell you about it:
C:\Windows\system32>taskkill /pid 9564 /f /t
ERROR: The process with PID 9564 (child process of PID 22520) could not be
terminated.
Reason: There is no running instance of the task.
Should you decide to try the same thing on the parent (in my case the parent was the debugger process, msvsmon.exe), it fails the same way:
C:\Windows\system32>taskkill /pid 22520 /f /t
ERROR: The process with PID 9564 (child process of PID 22520) could not be
terminated.
Reason: There is no running instance of the task.
ERROR: The process with PID 22520 (child process of PID 13964) could not be
terminated.
Reason: There is no running instance of the task.
The parent was started by the IDE, but the IDE cut the umbilical cord, so now you have two zombie processes. You can't attach a debugger to the process you were debugging, because there is already a (zombie) debugger attached, and you can't attach a debugger to the (zombie) debugger because, as Visual Studio will tell you when you try:
Unable to attach to the process. An operation is not legal in the current state.
The zombies are still in the process table sufficiently well to prevent you from running another instance through the debugger, but you could probably start another instance outside of the IDE just fine.
This addresses the more specific issue of having VS create a zombie process. But, zombie processes often don't die. Well, often on Windows, sometimes on Linux, not until you shoot them with a shotgun. Or was that a shutdown? But beware the accidental application of pending Windows updates.
I got excited at some of the earlier answers that suggested attaching with the debugger, but the above is the result I got. So I'm submitting my answer and rebooting to clean out the process table.