Topic: Inelegant debugger exit leaves orphan process
A problem I've learn't to be wary of with the new SF2 debugger is that if I exit in an inelegant way, a Win Doze 'process' with the name of the executable I was debugging is left wandering the streets, and this prevents me from re-compiling the same executable after making changes and corrections to the code (as you do, when debugging).
In most cases, it's just a nuisance, because I have to run the Task Manager, find the process that's still there, blocking the compiler from SAVing, and put the process out of its misery.
Sometimes, however, it's a very, very BIG nuisance. Nothing but nothing I can do, save for a cold reboot, will get rid of the unwanted process. The Task Manager can't kill it, and nor can various other tools I keep in readiness for this kind of thing.
I have not yet managed to work out exactly what kinds of inelegant exits leave what kinds of troublesome debris behind, but I thought I'd just mention this straight away whilst I try to gather together a more lucid account of the problem. I daresay you're familiar with it already, Jeff. If it's possible to prevent it from happening, that would be great. If not, then some means of releasing a jammed-up process that SF2 or the debugger had initiated would be a great help.
All of the above used to happen with SF1.45 as well, but not nearly so much. Most of the time, the debugger put all its toys away when I sent it to bed, even if I shouted at it and refused to kiss it goodnight. Just occasionally, it left a process running.
---
John