non-persistent DllMain

Dave Korn
Fri Oct 3 12:35:00 GMT 2008

Sam Liddicott wrote on 03 October 2008 13:12:

> [Forgot to copy this to the list, + new question]
> * Aurimas Černius wrote, On 03/10/08 12:12:
>> If I'm not wrong, GetModuleHandle(NULL) returns the handle of the
>> current module (should be DLL handle, when called from DLL). So saving
>> handle to a global variable is not needed.
> thanks!

  GetModuleHandle will return the main .exe's handle, won't it?  MSDN says:
"If this parameter is NULL, GetModuleHandle returns a handle to the file used
to create the calling process (.exe file)."

... and I have a memory that this issue cropped up recently in the context of
the cygwin dll's DllMain call.

>> I think that DllMain is called when DLL is not yet completely loaded,
>> so it is impossible to set values of global variables. Isn't it?
> Makes sense, 

  No it doesn't.  The DLL is completely loaded and all relocations applied.
Anything else would be insanity.

> Sadly it then crashes explorer.exe, but thats another problem for me to
> look into.

  No, it's because you haven't solved the underlying problem yet.

> It crashes when I do the first sendmessage after hooking.

... with presumably a null pointer dereference?

  DllMain is special.  There's a lot you cannot do in there, in particular
file i/o, printf etc, because you're running inside a lock and it's a sort of
critical section-y sort of situation, and indeed the MSVC CRT probably isn't
inited yet, so you definitely won't have stdio.

  If I were you, I'd put loads of OutputDebugMessage calls in your DllMain,
and watch what's happening and look at the value of hModule, and the addressof
g_hDLL (etc) using Sysinternals DebugView.

Can't think of a witty .sigline today....

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list