mgrier's WebLog

My guess would be that the loader deduces a list of dependencies to load for "SomeOther.DLL" which aren't already imported in the process and aren't already scheduled to be loaded in the loaders list.

Interestingly if the loader encounters an import in "SomeOther.DLL" that is already in the list to be loaded but has yet to be visited by the loader you could have all sorts of fun 'n' games when calling (*pfn)() (or even before if "SomeOther.DLL"'s initialization section assumes it to be present).

Am I right in thinking that there will be no deadlock induced by the attempted reacquisition of the loader lock? Simply because it is the same thread acquiring the critical section. (That’s not to say that a deadlock would not happen by some shenanigans in the initialization of "SomeOther.DLL" or one of its dependents)

Presumably failing to free the library means "SomeOther.DLL" and all it's dependents will never be unloaded from the process until process termination as the loader will always maintain the references.

I hope I’m not way off the mark :(

The thing there is that SomeOther.DLL's DllMain may not have already been executed depending on whether it was already loaded or not before our DllMain was called, and depending on the initialization list order.

So, if SomeFunction depends on something that was initialized from SomeOther.DLL's DllMain then it may break.

Additionally, if SomeFunction tries to load another DLL, the same problem may occur.

The leak will cause the SomeOther.DLL to remain pinned in memory (unless something else has tries to unload it too many times).

The lack of error checking may cause a crash if pfn is null. I believe LDR wraps all DllMain calls in an SEH frame though, so it should recover and fail the DLL load if I remember correctly.

(Incidentally, LDR has some hacks to support broken DllMains that do stupid things like mess up the stack pointer or change some of the nonvolatile registers...).

Sorry for going off on a tangent, but I'm trying to figure out this:

> GetProcAddress(LoadLibraryW(L"SomeOther.DLL"), "SomeFunction")

Regardless of whether the compilation environment is ANSI (multibyte) or Unicode (wide), you're calling the Unicode version of LoadLibrary with a wide string, fine. Then you're calling either the ANSI or Unicode version of GetProcAddress but with a multibyte string "SomeFunction" instead of wrapping it in _T(), so it looks rather unsafe. And you're doing these right next to each other in the same line of code, so I wonder why.

Wondering if you had some reason to specify the Unicode version of LoadLibraryW instead of just LoadLibrary and wrapping its argument in _T(), I looked in MSDN. The MSDN page is oddly worded. It says to take care in the pathname to use yen symbols instead of slashes, but then the clarification of a yen symbol in parentheses has a backslash instead of a yen symbol. The MSDN page was coded carefully to change fonts and character encoding just to put in that inappropriate backslash, since Japanese character sets don't have a single-byte backslash, they have a yen symbol which could have been put there most simply and appropriately. Very odd. Anyway, while reading the page I didn't find any difference in functionality between the Unicode version and the ANSI version, so again I wonder why you specified which version just for that call.

> New code should be Unicode only

That sounds like a religious argument on which I'm more or less agnostic[*], but in this particular case there's no need to decide whether or not to argue it. Look again at the code you posted:

> GetProcAddress(LoadLibraryW(L"SomeOther.DLL"), "SomeFunction")

If you're compiling in a Unicode environment then that calls GetProcAddressW and the pointer to the multibyte string "SomeFunction" will kill you.

[* The marketplace and the mountains of existing databases and existing installations aren't so agnostic, and there's no such thing as telling them to convert to Unicode only. That doesn't make me less agnostic, it just makes me pragmatic.]

Norman, there is no unicode version of GetProcAddress.

Thursday, June 23, 2005 4:49 AM by Jeroen Frijters
> Norman, there is no unicode version of
> GetProcAddress.

Ouch. When an API takes a string as a parameter, I think it would be necessary to look it up to see if there are two versions. Oh boy was I wrong. Sorry.

Thursday, June 23, 2005 1:43 PM by mgrier
> Exports pretty much have to be 7-bit clean.

Yup. No other ___W functions take UTF8 format. Furthermore, since the calling thread's ANSI code page can't be assumed to match the ANSI code page that was used on the development machine where the DLL was compiled, we can't convert it to UTF8 for the same reason we can't convert it to UTF16.

Now wondering why the filename of the DLL doesn't have to be 7-bit clean...

PingBack from http://cellulitecreamsite.info/story.php?id=6659

PingBack from http://workfromhomecareer.info/story.php?id=15909