OS Loader Lock and mda:loaderLockMsg / CanRunManagedCode?

I have an annoying problem with Outlook 2003 crashing on me sometimes when I shut it down. Usually, if I'm closing Outlook, I'm leaving for the day. That means that I don't necessarily have the time nor the desire to try to figure out what's going on. I just clear the box that wants to restart Outlook, choose not to send the report to Microsoft (sorry!), and go on my merry way.

One day, I finally looked into things a bit. I chose to debug the problem, which kicked off VSJITDebugger.exe (Visual Studio Just-In-Time Debugger), and let me pick a new Visual Studio 2005 instance.

In the Output window of VS2005, I saw the following and tossed it into a "New Text Document":
<mda:msg xmlns:mda= "http://schemas.microsoft.com/CLR/2004/10/mda">
<!--
Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.
-->
<mda:loaderLockMsg break="true"/>
</mda:msg>
> mscorwks.dll!MdaXmlMessage::SendDebugEvent() + 0x1c8 bytes
mscorwks.dll!MdaXmlMessage::SendMessage() + 0xf3 bytes
mscorwks.dll!MdaXmlMessage::SendMessagef() + 0xa9 bytes
mscorwks.dll!MdaLoaderLock::ReportViolation() + 0x13d bytes
mscorwks.dll!CanRunManagedCode() + 0xa64de bytes
mscorwks.dll!Unknown_Release() + 0x18 bytes
LookoutAddinShim.dll!DllGetClassObject() + 0x1a02 bytes
[Frames below may be incorrect and/or missing, no symbols loaded for LookoutAddinShim.dll]
LookoutAddinShim.dll!DllGetClassObject() + 0x1974 bytes
LookoutAddinShim.dll!DllGetClassObject() + 0x2650 bytes
LookoutAddinShim.dll!DllGetClassObject() + 0x3dbb1 bytes
LookoutAddinShim.dll!DllGetClassObject() + 0x22033 bytes
LookoutAddinShim.dll!DllGetClassObject() + 0x21f67 bytes
LookoutAddinShim.dll!DllGetClassObject() + 0x1dd01 bytes
LookoutAddinShim.dll!DllGetClassObject() + 0x1df5f bytes
ntdll.dll!_LdrpCallInitRoutine@16() + 0x14 bytes
ntdll.dll!_LdrUnloadDll@4() + 0x7569 bytes
kernel32.dll!_FreeLibrary@4() + 0x19 bytes
ole32.dll!CClassCache::CDllPathEntry::CFinishObject::Finish() + 0x25 bytes
ole32.dll!CClassCache::CFinishComposite::Finish() + 0x1599e bytes
ole32.dll!CClassCache::CleanUpDllsForApartment() + 0x63 bytes
ole32.dll!FinishShutdown() + 0x64 bytes
ole32.dll!ApartmentUninitialize() + 0x51 bytes
ole32.dll!wCoUninitialize() + 0x3f bytes
ole32.dll!_CoUninitialize@0() + 0x52 bytes
OUTLLIB.DLL!DllCanUnloadNow() + 0x13062 bytes
OUTLLIB.DLL!RenExitInstance@0() + 0x204 bytes
kernel32.dll!_BaseProcessStart@4() + 0x23 bytes

And of course I had to get going by the time all of the symbols were loaded, etc, so I closed the debugger and left for the day. But the output above seems to point to Lookout doing something naughty inside of the OS loader lock. (A list of naughty things can be found in the documentation for DllMain and "DllMain Restrictions" in "Mixed DLL Loading Problem".) I assume the message above is the implementation of the "Proposed Long-Term Solution" described in "Mixed DLL Loading Problem":

In addition to providing the managed module initializer mechanism to fix the loader lock problem in newly compiled images, this solution also provides checks to prevent the common language runtime from executing unsafe images that may have been built with old tools.

This would make sense, since LookoutAddinShim.dll is a mixed image - it is a COM component with dependencies on MSCOREE.DLL. In my case, it is using the .NET Framework 2.0, which presumably has incorporated the "Proposed Long-Term Solution" described in "Mixed DLL Loading Problem" as it certainly is "the next version of the common language runtime (after version 1.1)".

Generally, the "OS loader lock" issue is best dealt with by following the instructions specified in the Managed Extensions for C++ Reference at "Converting Managed Extensions for C++ Projects from Pure Intermediate Language to Mixed Mode".

I should note that I'm not sure what specifically caused Outlook to crash - the above is just a message that was in the Output window in Visual Studio 2005. It may or may not be the culprit.