I've had basically the same problem. I have a more useful call stack though
(I hope you'll forgive me for posting it, but I'll hold off until the end for
it.). Although there are lots of DLLs in this call stack, the error
implicates our mixed-mode DLL specifically. However, all the code that is
running under there belongs to MFC. Therefore, I would like an explanation
from MS as to what is going on. I have traced through this code and the only
guess I have is that they should have coded their DllMain to be #pragma
unmanaged, and did not. But I can't be certain. I actually tried to take
their DllMain (several functions thereof) and incorporate it into mine to
replace theirs, but I got some bizarre errors that I was unable to resolve.
I must just not understand it well enough. After messing around the problem
went away for awhile, and then came back. The only thing that seems to hold
this at bay is simply to turn off the MDA for LoaderLock, which is a very
lame solution.
I want to add that I even wrote code that was supposed to prevent the
DllMain notifications for thread detach, but I still seem to get them (in the
call stack you can see that dwReason=3 which I believe is THREAD_DETACH).
Here's the code I added, right in my InitInstance method:
BOOL C[MixedModeDLL]App::InitInstance()
{
// This should help with Loader Lock problems.
// See:
//
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=123858&SiteID=1
//
http://blogs.msdn.com/larryosterman/archive/2004/06/03/147736.aspx
//
http://blogs.msdn.com/mgrier/archive/2005/06/21/431378.aspx
//
http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx
// The use for it is to prevent DllMain from being invoked when
// threads are created or destroyed, because MFC appears to be a little
// unsafe in handling these cases. Moreover, since we don't do anything
// special with threads, we don't need these notifications (we ignore them).
AFX_MANAGE_STATE(AfxGetStaticModuleState());
DisableThreadLibraryCalls(AfxGetResourceHandle());
return CWinApp::InitInstance();
//return (TRUE);
}
But the net effect is zero. I'm still hosed! I wish I knew why.
Here's the call stack (shortened as much as possible):
[Managed Debug Assistant triggered on Unmanaged Thread]
ntdll.dll!7c90eb94()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!7c90e9c0()
....(kernel32.dll, mscorwks.dll, user32.dll, ntdll.dll)
OUR EXE
....(ntdll.dll, mscorwks.dll)
ONE OF OUR DLLs
OUR EXE
....(ntdll.dll, mscorwks.dll, user32.dll, kernel32.dll, advapi32.dll,
msvcrt.dll)
ONE OF OUR DLLs
....(ntdll.dll, mscorwks.dll, mscoree.dll)
mscoree.dll!79013486()
OUR_MIXED_MODE_DLL.dll!InternalDllMain(HINSTANCE__ * hInstance=0x01600000, unsigned long dwReason=3, void * __formal=0x00000000) Line 195 + 0x5 bytes C++
OUR_MIXED_MODE_DLL!DllMain(HINSTANCE__ * hInstance=0x01600000, unsigned
long dwReason=3, void * lpReserved=0x00000000) Line 276 + 0x11 bytes C++
OUR_MIXED_MODE_DLL!__DllMainCRTStartup(void * hDllHandle=0x01600000,
unsigned long dwReason=3, void * lpreserved=0x00000000) Line 495 + 0x11
bytes C
OUR_MIXED_MODE_DLL!_DllMainCRTStartup(void * hDllHandle=0x01600000,
unsigned long dwReason=3, void * lpreserved=0x00000000) Line 459 + 0x11
bytes C
....(mscoree.dll, ntdll.dll, kernel32.dll)
ONE OF OUR DLLs
....(kernel32.dll)