On 09/06/2010 02:41 PM, Johan Lindvall wrote:
On 6 sep 2010, at 19.27, Ion Gaztañaga wrote:
The problem is that I don't have any clue on how to solve this. I've googled around and there seems to be similar cases, but no explanation solution, maybe there are some restrictions when loading a dll?. Just to have a bit more infomration, which Win32 OS are you using, XP, Vista, 7?
I believe this is due to the DLL loader lock mechanism.
Basically, you are not supposed to call anything that might (implicitly) load another DLL from the DllMain function.
Google for "dll loader lock". The first link, "Best practices for creating DLLs" is a Word document describing the problem in detail.
While there are very few things you can safely do while under the loader lock on Windows, one of the things you can do is (believe it or not) create a new thread. But you can't wait on it to finish, of course. So a workaround I've used in the past for DLLs that really needed nontrivial startup code was to create a separate thread to run it. Before starting the thread, acquire a reference on the DLL via LoadLibrary. This prevents the DLL from being unloaded while the thread is running code in it. Somehow arrange for that reference to be released after the startup thread terminates, or it may be acceptable in specific cases to just never unload (e.g. the DLL is known to be a link-time dependency of the EXE). - Marsh