by Michael S. Kaplan, published on 2012/07/05 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/07/05/10327146.aspx
The recent question reminded me of something:
Hi,
We recently switched over to using LOAD_LIBRARY_AS_DATAFILE for our INTL dlls, which excludes the DLL from the list of loaded modules.
We tend to get a lot of Watson crashes of mismatched intl dll testing. Without having the intl DLLs in the list of modules, we can't tell the version anymore.
Is there a workaround other than manually loading the version and sticking it in some global?
It reminded me of how when you linked to unicows.lib to load/use the Microsoft Layer for Unicode, you'd suddenly "lose" all of your Unicode exports in the binary's official export table!
Kind of a required feature of the MSLU loader, that -- to redirect all those Unicode calls! :-)
In this case, LOAD_LIBRARY_AS_DATAFILE really is working as designed.
One of the features of it is lower overhead, which includes both not running init code, and not showing up in the loaded dependent modules.
If you need that info, you either have to back out the change, or load all of the information yourself.
Other solutions such as loading them the okld way under debug won't help if you want to look at Watson crashes, since customers will seldomly be using a debug build of your product!
Since you are loading the DLL as a datafile to get it's string resources, you can definitely load up the version info.
You can even write code to detect problems or even fix them -- and even find bugs earlier! :-)