The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

re: The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

John — Fri, 26 Jun 2009 17:08:30 GMT

This is why the only thing I ever do in DllMain is InitializeCriticalSection and DeleteCriticalSection; pretty much anything else can be lazy-initialized if needed.

re: The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

Tihiy — Fri, 26 Jun 2009 17:58:31 GMT

>must call DestroyWindow from the same window

you meant same thread?

[Fixed, thanks. -Raymond]

re: The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

Ben Voigt [C++ MVP] — Sat, 27 Jun 2009 00:00:53 GMT

Given the problem of global hooks running arbitrary code, is it possible to safely create a window from the DLL_THREAD_ATTACH notification (note THREAD not PROCESS)?

[Was never possible to do safely. Global hooks are just one of many problems. -Raymond]

re: The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

Worf — Sat, 27 Jun 2009 08:46:02 GMT

Which brings up the question - what is the purpose of DllMain, and what would someone normally use it for?

If it's not a replacement for Init()/Deinit() type functions, what should one use it for?

(Especially since there's a default stub if you don't implement one...)

re: The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

Jeff — Sat, 27 Jun 2009 09:58:16 GMT

@Worf

DllMain can be used to initialize/release a few basic low-level primitives that are explicitly designed to be called during DllMain. MSDN gives examples:

"For example, DllMain can create synchronization objects such as critical sections and mutexes, and use TLS."

However, if you don't have any use for it, then by all means just pretend DllMain doesn't exist. (Do still call DisableThreadLibraryCalls though).

Additionally, your programming language's runtime will take care of bookkeeping in or around DllMain. For example: the C runtime initializes global variables, and the C++ runtime calls the class constructors for global objects (a compelling reason to avoid having global C++ objects).

re: The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

Daev — Sat, 27 Jun 2009 22:02:21 GMT

Also, if you have an "atexit function" in your DLL written in C, and that DLL is linked with the static version of the C run-time library, then the atexit function is automatically called from DllMain during DLL_PROCESS_DETACH.

So don't do anything complicated in an atexit function -- in particular, don't call functions which are in some other DLL, 'cause that other DLL might have already been unloaded. (There's no way to guarantee that your DLL gets detached before any DLLs it might be using.)

This bit me, because I had an atexit function which closed any open sockets in case of process termination. But sockets are in the WinSock DLL ... which wasn't there anymore. Crash!

re: The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

Mon, 29 Jun 2009 00:48:27 GMT

The contract of dllmain is one of the most problematic things in Win32. Especially since many programmers don't even realize they are implementing dllmain since their language abstracts that away(static constructors/destructors in C++, initialization/finalization sections in Delphi).

I'm sure I violated it quite often before learning about it. Probably I'm still violating it in my current programs as it is almost impossible to write code which does not call any external functions.

re: The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

Anonymous — Mon, 29 Jun 2009 12:38:45 GMT

Two other useful things to do in a DllMain:

* Stash the first argument to DLL_PROCESS_ATTACH somewhere, it is useful.

* Call DisableThreadLibraryCalls() so you will not be bothered again until the DLL_PROCESS_DETACH.

re: The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

Mike Dimmick — Mon, 29 Jun 2009 13:48:16 GMT

It's one of these things that started out with good intentions, of being a place where you would do initialisation and cleanup. However, the implementation imposed some restrictions, and over time it's become clear that those restrictions stop you doing anything actually useful in it.

There are other good intentions in Windows - the IsBadXxxPtr family spring to mind. Again, the consequences are more serious than were anticipated when they were designed.

re: The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

640k — Tue, 30 Jun 2009 14:27:22 GMT

Unmanaged code is so last millennium.

re: The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

Maurits — Thu, 02 Jul 2009 15:11:37 GMT

> you must call DestroyWindow from the same thread that created it

I'll bite. Why?