Re: Win32 TerminateProcess problem

On Wed, Feb 3, 2010 at 11:22 PM, Emil Dotchevski <[email protected]>wrote:

> On Wed, Feb 3, 2010 at 10:47 PM, Jim Tilander <[email protected]> wrote:
> >
> > TerminateProcess does leak resources, on all NT kernels. Yes, that
> includes
> > whatever you run. I'm not even including Win98 or lesser, they are not
> even
> > production "OS"s anyways. For anyone curious, you should first read the
> man
> > page on TerminateProcess
> > (http://msdn.microsoft.com/en-us/library/ms686714(VS.85).aspx<http://msdn.microsoft.com/en-us/library/ms686714%28VS.85%29.aspx>... yes RTFM).
> > This is not a "theoretical" case, if you have any DLLs attached (and you
> > most probably will for any but the most trivial of applications) you
> *will*
> > leak resources. We had this in our pipeline and it took blood sweat and
> > tears to track this one down (happend during distribution of our "simple"
> > tools, and it leaked every time things timed out. Over the course of
> > hundreds of thousands of these builds machines on the network quickly
> > experience slowdowns and "random" crashes).
>
> Oh dear.
>
> Well, I was referring to this post, which indicates that ExitProcess
> should not be called at random because it can lead to serious
> problems; and injecting a thread that calls it strikes me as rather
> random:
>
> http://blogs.msdn.com/oldnewthing/archive/2007/05/03/2383346.aspx
>
> Then there is this correction, which says that on Vista and on, if you
> call ExitProcess and then hit a synchronization primitive, it'll call
> TerminateProcess on you:
>
> http://blogs.msdn.com/oldnewthing/archive/2010/01/22/9951750.aspx
>
>
Considering the case where we are trying to terminate / exit a process
that's out of our control, I still believe that TerminateProcess is a bad
thing to call routinely and you should do the CreateRemoteThread (which of
course might call TerminateProcess in turn, but not *always*, which makes a
huge difference if you are killing thousands of these buggers). It's simply
the lesser of two evils. As far as I know there is no good way of forcibly
killing another process. Even in UNIX you can leak resources if you start
killing processes nilly willy.



> It seems like the only way to quit safely is to first exit all your
> threads cleanly and then exit the process.
>
>
I assume that you have not written, nor can change the process you are
trying to terminate. If it's your own app, and you also trying to terminate
the app from your own app, there are of course classical network message
passing (through IPC or any other thing) ways to shut down the application
inside the app code, no need to go through the OS and hit the app with a
large hammer.


> In my particular use case however, I'm calling TerminateProcess on
> another process before any of its DLLs have a chance to load. So I
> still need a way to get the exit code I pass to TerminateProcess
> propagate correctly...
>
>
I digress though, I'm interested in how you know that in your case you have
code before the DLLs have attached? AFAK the kernel loader is attaching the
DLLs before any of your code in the app is allowed to run... Are you loading
all the DLLs through LoadLibrary explicitly?


-- 
Introspection is just a ladder for people who have dug them an object
oriented hole.

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com