Problem with MFC extension DLL, threads, and .Net loader lock

[Al Norman]

We have two separate DLLs that do not interact (directly, at least). One is
an MFC extension DLL that was built back in VC++ 6 days (but has been
recompiled with VS2005). The other is a DLL that contains .Net functions
wrapped in C++ (as described by Paul DiLascia -- see
http://msdn.microsoft.com/msdnmag/issues/06/06/CAtWork/default.aspx). Both
DLLs specify 'Use MFC in a shared DLL'.

Since we have an old VC 6 application (large) that we would like to start
using .Net classes with (e.g. regular expressions), we have been trying to
implement the wrapped approach, which involves creating a DLL with the
wrapped .Net stuff in it. Hope that's clear ...

What we have found is that, when we use the wrapped DLL, we blow up with a
'loader lock' issue. This only occurs, though, when we do the following:

1. Implicitly link to the MFC extension DLL (XMap).
2. Create a thread, using AfxBeginThread, that will use the XMap DLL to do
some time-consuming initialization stuff.
3. When the initialization is done, that secondary worker thread exits -- at
which point we get the following (i.e. the mda:msg -- I have included the
debug output from the point at which the XMap DLL got loaded):

XMAP.DLL Initializing!
'CAD.exe': Loaded
'D:\views\al08333_view_SS_9_3_Dev\xwaveCAD\Workstation\ciids96\debug\Splash.dll',
Symbols loaded.
'CAD.exe': Unloaded
'D:\views\al08333_view_SS_9_3_Dev\xwaveCAD\Workstation\ciids96\debug\Splash.dll'
'CAD.exe': Loaded
'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll', Symbols loaded
(source information stripped).
'CAD.exe': Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.91_x-ww_0de56c07\msvcr80.dll',
Symbols loaded (source information stripped).
CDEQView::OnInitialUpdate() called
Comms IndicationHandler set to CWorkstation::HandleIndications
'CAD.exe': Loaded
'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Culture.dll', Symbols loaded
(source information stripped).
'CAD.exe': Unloaded
'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Culture.dll'
'CAD.exe': Loaded
'C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\mscorlib\467bb10fb591904e8c6509fc55279db2\mscorlib.ni.dll',
No native symbols in symbol file.
'CAD.exe': Loaded
'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Culture.dll', Symbols loaded
(source information stripped).
'CAD.exe': Unloaded
'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Culture.dll'
<mda:msg xmlns:mda="http://schemas.microsoft.com/CLR/2004/10/mda">
<!--
DLL 'c:\tools\RegexWrapD.dll' is 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>
CAD.exe has triggered a breakpoint

If I don't allow the thread to exit (by putting an INFINITE wait on a handle
right before the return statement), everything works!

It appears as though when tearing the thread down, MFC gets confused about
the wrapped DLL (RegexWrapD.dll). Where I get confused is that neither DLL
is explicitly aware of the other (i.e. neither one calls any functions in
the other).

When looking at the stack backtrace, the 'green arrow' in the backtrace
points to the following ATL source:

In module dllmodul.cpp, function:

extern "C"
BOOL WINAPI InternalDllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID
/*lpReserved*/)


error (green arrow) occurs at line 195:

else if (dwReason == DLL_THREAD_DETACH)
{
#ifdef _AFXDLL
AFX_MANAGE_STATE(&afxModuleState); //// LINE 195 -- ERROR
HERE!
#endif

The MFC extension DLL has a DllMain, which is supposed to be supported in
VS2005. Here is what is does:

static AFX_EXTENSION_MODULE NEAR XMapDLL = { NULL, NULL };

extern "C" int APIENTRY
DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
// Remove this if you use lpReserved
UNREFERENCED_PARAMETER(lpReserved);

if (dwReason == DLL_PROCESS_ATTACH)
{
// Extension DLL one-time initialization
if (!AfxInitExtensionModule(XMapDLL, hInstance))
return 0;
new CDynLinkLibrary(XMapDLL);
}
else if (dwReason == DLL_PROCESS_DETACH)
{
//TRACE0("XMAP.DLL Terminating!\n");
// Terminate the library before destructors are called
AfxTermExtensionModule(XMapDLL);
}
return 1; // ok
}

We have tried creating a separate initialization function that get's called
explicitly by the thread(s), and putting the 'new CDynLinkLibrary' call in
it, but that does not work either (i.e. calling it once from the main thread
only, or calling it twice (once from the main thread, once from the worker
thread). I have also created a dummy MFC extension DLL using the VS2005
wizard and I can access a function within it fine from 2 different threads.
The only thing about this dummy MFC extension DLL is that I don't allocate
any MFC objects, whereas the XMap DLL does (both global, static objects like
CPtrArray and other objects created by existing initialization calls from
the application).

Any thoughts on the problem?

Thanks

Al

 

[Gary Chang[MSFT]]

Hi Norman,

Based on my understanding, the problem is your application implicitly links
to a MFC extension DLL(XMap), and use that DLL's function in a worker
thread. When that worker thread exits, yo receive an error message about
the OS Load Locker issue which invoked from another mixed DLL
(RegexWrapD.dll). Please correct me if I misunderstood anything.

Before we dig into this problem, would you please tell us whether this
problem occurs outside the VS2005 debugger? If your application could work
well without VS2005' s debugger, then this problem may occur because of the
way in which the debugger in Visual Studio 2005 runs managed applications
that use Microsoft Foundation Classes version 8.0 in one or more DLL files.
We have an MSDN KB article which targets on this issue:

FIX: Error message when you use the debugger in Visual Studio 2005 to debug
an MFC class library application: "Managed Debugging Assistant 'LoaderLock'
has detected a problem in '<filename.exe>'"
http://support.microsoft.com/default.aspx/kb/913996

If the above KB article cannot resolve your problem, we may need more info
to isolate the issue:

1. How about that mixed DLL, how do you use it in your application? It
seems that worker thread also load that DLL.

2. Each thread's call stack info while the application breaks on that
error. You can get a specific thread's call stack by select the target
thread ID in the Debug | Windows | Threads window, then invoke its
corresponding Call Stack window.

Before doing this, you may need to setup the debugging symbols for your
VS2005. For example to set the Symbol Server path you need to input
"srv*c:\LocalSymbols*http://msdl.microsoft.com/download/symbols;" in the
Tools | Options | Debugging | Symbols as the directory. This will tell the
VS2005 debugger to lookup symbol from the Microsoft symbol server
"http://msdl.microsoft.com/download/symbols" and cache the downloaded
symbol in "c:\LocalSymbols" folder.

By the way, there would be many reasons to cause the loader locker problem
in the case of the mixed DLL, I suggest you refer to the following MSDN
articles for the details:

Converting Managed Extensions for C++ Projects from Pure Intermediate
Language to Mixed Mode
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmex/html/
vcconconvertingmanagedextensionsforcprojectsfrompureintermediatelanguagetomi
xedmode.asp

Mixed DLL Loading Problem
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechar
t/html/vcconMixedDLLLoadingProblem.asp


Thanks!

Best regards,

Gary Chang
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Al Norman]

Actually, my first name is 'Al' -- Norman is my last name ... but I'll
respond to anything!

My comments are interspersed with your text below ...

Based on my understanding, the problem is your application implicitly
links
to a MFC extension DLL(XMap), and use that DLL's function in a worker
thread. When that worker thread exits, yo receive an error message about
the OS Load Locker issue which invoked from another mixed DLL
(RegexWrapD.dll). Please correct me if I misunderstood anything.

That is correct.

Before we dig into this problem, would you please tell us whether this
problem occurs outside the VS2005 debugger? If your application could work
well without VS2005' s debugger, then this problem may occur because of
the
way in which the debugger in Visual Studio 2005 runs managed applications
that use Microsoft Foundation Classes version 8.0 in one or more DLL
files.
We have an MSDN KB article which targets on this issue:

FIX: Error message when you use the debugger in Visual Studio 2005 to
debug
an MFC class library application: "Managed Debugging Assistant
'LoaderLock'
has detected a problem in '<filename.exe>'"
http://support.microsoft.com/default.aspx/kb/913996

Yep. That fixed the problem -- I see the KB article requires a hot fix from
Microsoft. Should I get that or wait for the SP1 for VS2005? How soon is
that coming?

<rest of reply snipped>

I had already read/done the rest of your suggestions. I like the fact that
VS2005 and Debuggging Tools for Windows seem to be sharing a common debugger
......

Al Norman

 

[Gary Chang[MSFT]]

Hi Al,

Yep. That fixed the problem -- I see the KB article requires a hot fix
from Microsoft. Should I get that or wait for the SP1 for VS2005?

I am glad to know that KB helps! The VS2005 SP1 is still in beta test
stage, so I suggest you contact our CSS(Microsoft Customer Support Service)
for the hotfix directly. You need to tell them the corresponding KB number
for it.

Since this problem is a product issue, CSS won't charge money. Every MSDN
subscriber has two free support incidents. You could use one of them to
contact Microsoft CSS. So you don't need to pay money yet, you still have
two free support incidents.

For your reference, I have attached steps to contact Microsoft CSS here:
You can contact Microsoft Customer Support Service directly to discuss
additional support options you may have available, by contacting us at
1-(800)936-5800 or by choosing one of the options listed at:

http://support.microsoft.com/common/international.aspx?rdpath=gp;en-us;offer
prophone

I hope the above information helps, if you have any questions or concerns,
please do not hesitate to let me know. I am standing by to help you.

Thanks!

Best regards,

Gary Chang
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Al Norman]

No problems. Thanks for the help.

Al

Hi Al,

Yep. That fixed the problem -- I see the KB article requires a hot fix
from Microsoft. Should I get that or wait for the SP1 for VS2005?

I am glad to know that KB helps! The VS2005 SP1 is still in beta test
stage, so I suggest you contact our CSS(Microsoft Customer Support
Service)
for the hotfix directly. You need to tell them the corresponding KB number
for it.

Since this problem is a product issue, CSS won't charge money. Every MSDN
subscriber has two free support incidents. You could use one of them to
contact Microsoft CSS. So you don't need to pay money yet, you still have
two free support incidents.

For your reference, I have attached steps to contact Microsoft CSS here:
You can contact Microsoft Customer Support Service directly to discuss
additional support options you may have available, by contacting us at
1-(800)936-5800 or by choosing one of the options listed at:

http://support.microsoft.com/common/international.aspx?rdpath=gp;en-us;offer
prophone

I hope the above information helps, if you have any questions or concerns,
please do not hesitate to let me know. I am standing by to help you.

Thanks!

Best regards,

Gary Chang
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.