Another thing, which is not built in to the OS but is useful on modern programs that use exception handling, is to break in and make all the threads throw exceptions. This will (might) unwind the stack and call destructors, and may close files and stuff more gracefully than just stopping. Or having it call ExitProcess from that process will at least tell the DLLs to clean up.
My experience in Windows is that sometimes a stuck process will not go away, even when attempted to kill from Sysinternals' Process Explorer. This is probably due to it having pending I/O or otherwise stuck in some system thread. The system shutdown procedure apparently has some stronger way to deal with them, after a long time out.
The MSDN, on Terminating a Process, suggests making a custom window message that is known to both processes, and avoid calling TerminateProcess. More generally, build the program so it can be told to stop in a graceful way.
As for your last question, Windows doesn't track "sub"processes. Any started process is a peer to all others. Process Explorer goes to some effort to figure it out anyway, and its "kill tree" identifies them all and kills each individually.
—John
In reply to Re: Killing a process on Windows (Win32::Process question)
by John M. Dlugosz
in thread Killing a process on Windows (Win32::Process question)
by rovf
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |