RegSvr32.exe calls the following Win32 functions in this order:

• OleInitialize
• LoadLibrary to load the DLL
• DllRegisterServer or DllUnregisterServer
• FreeLibrary
• OleUninitialize

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!