Re: Win32 TerminateProcess problem

Yep, the kernel will map in and initialise any non-delay loaded DLLs 
before it calls the executable.  The order DLLs are loaded is specified 
somewhere in the PE header of the executable, afaik.


Jim Tilander wrote:
> On Wed, Feb 3, 2010 at 11:22 PM, Emil Dotchevski 
> <[email protected] <mailto:[email protected]>> wrote:
>
>     On Wed, Feb 3, 2010 at 10:47 PM, Jim Tilander <[email protected]
>     <mailto:[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
>   
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com