The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 1 - LoadLibrary()

re: The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 1 - LoadLibrary()

Wound — Thu, 23 Jun 2005 16:09:14 GMT

The question then is: what does LoadLibrary return if the library hasn't actually been loaded, and what are you calling GetProcAddress on? In your example I would expect GetProcAddress to fail, but DllMain to return TRUE, even though "SomeFunction" was not called.

re: The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 1 - LoadLibrary()

Graham Harper — Thu, 23 Jun 2005 16:49:17 GMT

I would expect the library has been mapped into the virtual address space of the process and you do get a valid base address back as indicated by the HMODULE. That doesn't mean the module has been initialized however.

It’s funny because GetProcAddress's contract with the caller is only that of providing an address into the module from a symbolic name. It can't (and won't) guarantee the module is in a suitable state to run the method pointed to.

But i could be wrong.........

re: The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 1 - LoadLibrary()

mgrier — Fri, 24 Jun 2005 01:58:51 GMT

Sorry, Graham, you were in fact wrong. I do say "implied" because that's what it happens to do and also because if it didn't run the initializers in the "simple" cases, using the pointer you got back from GetProcAddress() wouldn't be useful anyways.

Eventually I'm going to get to recommendations of what to do in your DLL_PROCESS_ATTACH (basically nothing!) and how to live with the consequences.

re: The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 1 - LoadLibrary()

Graham Harper — Fri, 24 Jun 2005 10:13:04 GMT

Sorry I was being really thick!

What your saying makes an awful lot of sense now.

It effectivley becomes Just-In-Time initialization of the module as LoadLibrary cannot always guarentee intialization of the target and it's dependencies?

If A.DLL calls the LoadLibrary\GetProcAddress pair on B.DLL, which in turn has a static dependency on A.DLL (unbeknown to it) the loader isn't going reinitialize A.DLL again because it's already in the tables and is currently being initialized. B.DLL will be initialized (because that’s what GetProcAddress implicitly guarantees?) and any subsequent call on the returned pointer into B.DLL could "end in tears" as we're still sitting in the initialization section of one of the modules on which B.DLL depends. Is this correct?

re: The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 1 - LoadLibrary()

mgrier — Fri, 24 Jun 2005 18:16:53 GMT

Graham, the loader is smart enough to not try to run A's initializer again but as you point out that doesn't mean that B's initializer will actually work. Now you might think B was smart enough about this, but also all of B's static imports have to be smart about how they call into A.

Now you need dynamic global analysis in order to predict whether you have any bugs. Sounds like a recipe for failure to me...

re: The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 1 - LoadLibrary()

Richard — Tue, 28 Jun 2005 14:54:40 GMT

I note that the DllMain documentation on MSDN (July 05 edition) explicitly says that DllMain must not call LoadLibrary or LoadLibraryEx.

Laden einer DLL innerhalb einer anderen DLL | hilpers

Laden einer DLL innerhalb einer anderen DLL | hilpers — Tue, 20 Jan 2009 17:21:50 GMT

PingBack from http://www.hilpers.com/954660-laden-einer-dll-innerhalb-einer