Reputation: 55
I am writing a plugin for some system, however there are some misbehaved applications that call my plugin during dll initialization (either from DllMain or InitInstance which is a wrapper for DllMain).
I was wondering if there is a way to find out whether the code is executing within DllMain or not. I wan't to fail gracefully without causing a deadlock (the code my plugin is executing involves dll loading, thread creation and waiting for event, which causes deadlocks if executed within DllMain).
I am aware of the fact the CreateThread will not execute until DllMain exits, however I cannot do initialization from another thread as it involves COM.
Upvotes: 4
Views: 827
Reputation: 1000
Practically you're asking for a way to peek the loader lock state, however Windows API doesn't allow that since it doesn't expose the loader lock in any way. Even if you were able to get the lock state, you couldn't guarantee it stays the same during the execution of your subsequent code--you would have to acquire it, and that beats the whole purpose since that's the thing you want to avoid.
So as far as I can see, the only practical way to deal with this is to document your plugin and forbid the usage from DllMain(). If that means that some component owners will have to do a slight redesign of their DLL initialization, so be it.
Upvotes: 3
Reputation: 612824
There's no mechanism to detect this as it happens. Everyone is expected to play by the rules.
Upvotes: 0
Reputation: 2531
When I've been stuck in situations like this and printf doesnt cut it, I will try to create a file instead. Use your message as the filename along with timestamps. This may help you, good luck.
Upvotes: 0
Reputation: 108975
I don't believe there is any system provided way to do this. However since the loader lock guarantees that only one dllmain
is running at a time it would be easy to set a flag at the start of dllmain
and unset it at the end.
Upvotes: 0