12

It seems that when a thread is created from within DllMain upon DLL_PROCESS_ATTACH it won't begin until all dll's have been loaded. Since I need to make sure the thread runs before I continue, I get a deadlock. Is there any way to force the thread to start?

sold
  • 2,041
  • 5
  • 25
  • 32

4 Answers4

13

You shouldn't be doing any API calls, especially for things like creating threads or windows, from DLLMain. Raymond Chen has written about this many times; here's one that's particularly relevant.

Michael Bikovitsky
  • 903
  • 2
  • 10
  • 20
Ken White
  • 123,280
  • 14
  • 225
  • 444
  • 12
    CreateThread is one of the few things you can do inside DllMain, because it's a call to kernel32 which is guaranteed to be already loaded. – Ben Voigt Feb 06 '10 at 18:24
  • 4
    @Ben Voigt but be extremely careful, as it's easy to get dead-lock if current DllMain call is asked to wait for return from the new thread. – mloskot Nov 09 '10 at 13:43
  • 1
    @mloskot: Calling wait functions in `DllMain` is very bad no matter what kind of object you're waiting for. Generally any thread that's executing code from a DLL needs to have a reference count on that DLL, less the code get mapped out from under it. Which prevents the issue from ever occurring, since `DllMain` then won't be called (for process detach) as long as the thread is running. – Ben Voigt Nov 09 '10 at 14:06
  • 4
    @BenVoigt: Although `CreateThread` can be safely called from `DllMain` (assuming you're ok with it being suspended and not calling any wait functions), it's still a bad idea, for precisely the reasons mentioned in Raymond's blog post: if your DLL is briefly loaded and unloaded by some other dependent DLL, you don't want to be creating unnecessary resources (like threads) in that scenario. – Adam Rosenfield Dec 30 '12 at 03:25
  • 4
    I believe [Does creating a thread from DllMain deadlock or doesn’t it?](https://blogs.msdn.microsoft.com/oldnewthing/20070904-00/?p=25283/) is even more relevant. Bottom line: Calling `CreateThread` from `DllMain` is safe (even if not recommended). – IInspectable May 04 '16 at 19:55
6

What does your thread do?

If you're trying to move stuff onto a second thread to avoid restrictions on what you can do inside DllMain, tough luck. Those are not restrictions on what DllMain can do, they are restrictions on what can be done while DllMain is running (and holds the loader lock). If your thread needs to take the loader lock, it will wait until the first thread finishes using it. If your thread didn't need the loader lock I don't see why it couldn't continue immediately... but there's no such thing as a thread that doesn't need the loader lock. Windows has to send DLL_THREAD_ATTACH messages to all DLLs before your thread can start running, which means it also calls your own DllMain, and Windows protects against re-entrancy.

There's no way around this. The thread can't start until after DLL_THREAD_ATTACH processing, and that can't happen while your first thread is inside DllMain. The only possible way around it is to start a new process (which has an independent loader lock and won't block waiting for yours).

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • I tried a simple exercise of using `CreateThread()` for a very simple worker function in a `DLLMain()` during the processing of a `DLL_PROCESS_ATTACH` messages. The thread function used `Sleep()` for 1000 milliseconds. Everything worked fine. I could see the `DLL_THREAD_ATTACH` messages and `DLL_THREAD_DETACH` messages from both the initial thread doing the `DLL_PROCESS_ATTACH` and the thread created during the attach processing. However this worker thread did nothing other than the `Sleep()`. Kernel32.dll calls are supposed to be fine. Tested with VS 2005 Windows 7. – Richard Chambers Feb 21 '16 at 18:39
  • Oddly enough, this really is the only answer that addresses the question that was asked. I don't know why the OP decided to accept an answer that isn't. – IInspectable May 04 '16 at 20:04
4

No. You shouldn't call CreateThread (or any varation) from DllMain. Attempting to synchronize will result in a deadlock. What exactly are you trying to do?

Best Practices for Creating DLLs

genpfault
  • 51,148
  • 11
  • 85
  • 139
lyricat
  • 1,988
  • 2
  • 12
  • 20
  • 9
    Nothing wrong with calling CreateThread, but there's no way around the fact that the thread will be suspended until DllMain processing completes in the parent thread. – Ben Voigt Feb 06 '10 at 18:32
  • 1
    From the link provided : "You should never perform the following tasks from within DllMain : Call CreateThread. Creating a thread can work if you do not synchronize with other threads, but it is risky." – KVM May 07 '21 at 18:45
0

You're asking for trouble if you do this. You shouldn't make any calls (directly or indirectly) to functions that are outside of your dll's (including C library calls, etc.).

If you can't change the DLL you have (e.g. you don't have source code), you might be able to get away with this if your DLL is dynamically loaded after the rest of your dependent DLL's are initialized. I wouldn't recommend this approach if you can avoid it because figuring out the dependency chain is not always trivial (e.g. if your dll causes a dependent dll to load a third one dynamically through COM or some other means).

Peter Tate
  • 2,178
  • 1
  • 21
  • 32
  • 2
    The first paragraph here is a an over-generalization. It's perfectly fine to make calls into DLLs you know for a fact were already loaded before yours. In general and in most situations, this means KERNEL32.DLL only, which may sound like a crippling limitation, but you can use it to bootstrap your way out of this situation. – Integer Poet Apr 20 '10 at 16:08
  • Thanks Integer Poet. That answers exactly the question I came here to solve. – Steve Rowe May 05 '10 at 23:42
  • 1
    @IntegerPoet: Both *kernel32.dll* and *ntdll.dll* are guaranteed to be mapped into a process' address space before its bootstrapping code runs. – IInspectable May 04 '16 at 20:03