LoaderLock problem

[aaron.m.johnson]

Help me understand this, please.

I have an older VC++ COM DLL that I'm using in a C# project. One of
the COM objects takes a callback object as a parameter so that it can
spin off a thread and do some long running network stuff without
blocking. When I run the application the callback works as expected,
but I get an error when I try to access the COM object in the
callback.

So the call order is: C# app -VC++ COM DLL thread -C# callback ->
COM accessor *boom*

The error I get is:
LoaderLock was detected
Message: 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.

I think I understand that this is telling me that the unmanaged VC++
code calling the managed C# code is a no-no. Right? How do I get
around this?

[G Himangi]

I think I understand that this is telling me that the unmanaged VC++

code calling the managed C# code is a no-no. Right?

That is not the problem. Unmanaged code can call managed code without any
problems.

The problem is that a DLL is executing managed code inside its DLLMain
function and that can *potentially* cause a deadlock situation.

---------
- G Himangi, Sky Software http://www.ssware.com
Shell MegaPack : GUI Controls For Drop-In Windows Explorer like Shell
Browsing Functionality For Your App (.Net & ActiveX Editions).
EZNamespaceExtensions.Net : Develop namespace extensions rapidly in .Net
EZShellExtensions.Net : Develop all shell extensions,explorer bars and BHOs
rapidly in .Net
---------


<aa*************@gmail.comwrote in message
news:11********************@u30g2000hsc.googlegrou ps.com...

Help me understand this, please.

I have an older VC++ COM DLL that I'm using in a C# project. One of
the COM objects takes a callback object as a parameter so that it can
spin off a thread and do some long running network stuff without
blocking. When I run the application the callback works as expected,
but I get an error when I try to access the COM object in the
callback.

So the call order is: C# app -VC++ COM DLL thread -C# callback ->
COM accessor *boom*

The error I get is:
LoaderLock was detected
Message: 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.

I think I understand that this is telling me that the unmanaged VC++
code calling the managed C# code is a no-no. Right? How do I get
around this?

[aaron.m.johnson]

On May 29, 10:40 pm, "G Himangi" <[e-mail]:

>
That is not the problem. Unmanaged code can call managed code without any
problems.

The problem is that a DLL is executing managed code inside its DLLMain
function and that can *potentially* cause a deadlock situation.

Hmm... I think the debugger must be getting confused then because
that's definitely not what's going on. This is happening well after
DLLMain is called, and there's no managed code in the DLL or visible
to DLLMain.

I've been suspecting something else is to blame for a bit now since
the blocking version of the method (no callback used) is returning an
object that C# says is invalid. I can't figure out what makes this
call different from all the others that do work just fine.

[=?Utf-8?B?VlIgUmF2aW51dGhhbGE=?=]

Try unchecking the LoaderLock under Debug -Exceptions

It should work.

-VR
"aa*************@gmail.com" wrote:

On May 29, 10:40 pm, "G Himangi" <[e-mail]:

That is not the problem. Unmanaged code can call managed code without any
problems.

The problem is that a DLL is executing managed code inside its DLLMain
function and that can *potentially* cause a deadlock situation.

Hmm... I think the debugger must be getting confused then because
that's definitely not what's going on. This is happening well after
DLLMain is called, and there's no managed code in the DLL or visible
to DLLMain.

I've been suspecting something else is to blame for a bit now since
the blocking version of the method (no callback used) is returning an
object that C# says is invalid. I can't figure out what makes this
call different from all the others that do work just fine.