I'm using VS 2008 on a 64-bit XP machine. I'm debugging a 32-bit C++ DLL via a console program. The DLL and EXE projects are contained in the same SLN so that I can modify the DLL as I test.
What happens is that every once in a while I kill the program with Debug | Stop Debugging (Shift-F5). VS stops the program, but the console window stays open! If I'm sitting at a breakpoint and hit Shift-F5, it will terminate properly, but if the program is running full-tilt when I stop it, I often see this instead.
The big problem is that I can't close these zombie windows. Using End Task in Task Manager does nothing (no message, no nothing). When I shut down the machine, it is unable to due to the orphans and I have to resort to actually turning off the power.
I think this is connected to having the DLL and EXE project in the same SLN, as for months I worked on this project in 2 VS instances, one for the DLL and the other for the EXE. I would continually jump back and forth between the windows as I worked. This problem never happened until I put the two projects into a single SLN. The single SLN works a lot better, but this anomaly is very irritating.
Any ideas anyone?
UPDATE
After a bit of searching (here), I found that it appears to have to do with one of the updates from last Tuesday (KB977165 or KB978037). Thank you Microsoft for your excellent pre-release testing.
It's KB978037. Uninstalling it resolves the issue.
More info here
Console windows are owned by csrss.exe, which is a system process, and actually the only process that you cannot kill (at least on XP, you can kill the other system processes if you do it in the right order, look for the article "Running Windows with No Services" by Mark Russinovich). So unfortunately, power cycling seems to be the only way to get rid of the zombie console windows.
The same thing recently started happening to me. I'm using Windows XP 32-bit, VS 2008. I don't think this is connected to how your projects are organized. Perhaps a patch installed through Windows Update caused this.
The best thing I was able to find is a workaround: binding the detach all to the shift-F5 button. In this way you basically release the window from the debugger and you can close the window itself w/o ending up with an orphaned cmd window.
Hopefully MS will come up with a solution.
Tools -> Options -> Environment -> Keyboard.
By the way the process I described above only works sporadically. Since this problem seems to occur quite often, is there a way to finally resolve it once and for all?
Mcrosoft acknowledge and describe this problem, here:
http://support.microsoft.com/kb/982551/
They have released a hot fix, which you can get from:
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=982551&kbln=en-us
(you have to supply an email address, then they send you a password protected HotFix installer)
Some good solutions have been provided here.
An alternative: Instead of stopping a debug session by pressing SHIFT-F5, hit CTRL-C, that causes the program to end normally eliminating the source of the problem.
I've definitely seen oddities with handles not being released and task manager not working right. I've found that Process Explorer does a good job and figuring out what's going on with orphaned windows, file locks, and generally odd behavior that happens.
