I just finished spending a couple days troubleshooting a problem with a Win32 non-mfc DLL failing a LoadLibrary(). Actually, the post build step for my DLL ran regsvr32 to register it and it started failing with the following message:
RegSvr32.exe calls the following Win32 functions in this order:
- LoadLibrary to load the DLL
- DllRegisterServer or DllUnregisterServer
A common reason for failure is that there are dependent DLL's missing. Dependency Walker is good for checking this. Unfortunately, this lead me down a rat hole when I saw that there was a complaint about MSVCR90D.dll. It also led me to erroneously try various things to modify the manifest used and the Code Generation…Library Used settings.
I was unable to break in the DLLMain of the library so I assumed there was a problem in the way I was building it. I even installed the latest Vista SP1 and Visual Studio SP1 to try to make the "build" problem go away.
Ultimately, what worked was for me to create a simple program that called LoadLibrary() on my dll. I then set the Debug…Exceptions options to catch all exceptions. As soon as the test program called LoadLibrary() (on my debug build) it went right to the line of code that was causing an "Invalid access to memory", just like the message said! I guess that's the danger of giving too much information in a message, users will erroneously choose the wrong symptom.
This worked because the problem was in some code that was called during the construction of a C++ object, which was instantiated prior to calling the main entry point of the DLL.
Lesson learned: When a module fails on startup, check your global objects' construction code, and don't forget to turn on catching all exceptions in the debugger!