DLL_PROCESS_DETACHED relentlessly not working for you? Fear not!

Does atexit() / _onexit() accidentally happen not to work for you? Same was in my case. Most of the explanations  I could find for this situation on the web can be wrapped up in these two bullet-points:

* Things done wrong in DLL_PROCESS_ATTACHED handler;
* Not all library handles closed;

Guess what: there’s more to it! In my case (64-bit Windows 7, dynamically-linked library automatically sucked in on start-up by application) the solution turned out to be very odd. Here’s an outline of what I was doing:

* Main thread spawns a child thread, which is used for message pumping purposes;
* (..all kind of the usual application’s sorcerery goes in here..)
* Main thread decides it’s high time for the process to die.
* Main thread requests the window to close (sends a message to the window, waits till a system event telling “Message pump thread waves good bye” is set by the pumping thread right before it quits)
*  Main thread deinitializes stuff, calls ExitProcess()

Now, if you do a little bit of a reading, you’d expect ExitProcess() to call back your handler(s) of choice in an instant. Nope, nada. In my case, what I was seeing was.. well. the process just killed itself without no apparent reason 🙂 No debugging output, no crashes, no breakpoints, no feed-back from CRT library, no nothing.

So what was the reason? As simple as that: you have to do a WaitForSingleObject() call on the main thread to make sure the message pump thread is already dead before you attempt to exit the main thread. What’s funnier – it doesn’t matter if you have other threads you spawned running in the background – window hosting threads must be no longer present in order for the “on exit” callback to work.

Hope this saves somebody a few hours I had to spend investigating this.

Leave a Reply

Your email address will not be published. Required fields are marked *