469,306 Members | 2,121 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,306 developers. It's quick & easy.

LoaderLock problem

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?

May 29 '07 #1
3 8548
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?

May 30 '07 #2
On May 29, 10:40 pm, "G Himangi" <i...@ssware.comwrote:
>
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.

May 30 '07 #3
Try unchecking the LoaderLock under Debug -Exceptions

It should work.

-VR
"aa*************@gmail.com" wrote:
On May 29, 10:40 pm, "G Himangi" <i...@ssware.comwrote:

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.

May 30 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

117 posts views Thread by Peter Olcott | last post: by
28 posts views Thread by Jon Davis | last post: by
6 posts views Thread by Ammar | last post: by
reply views Thread by jnospamster | last post: by
3 posts views Thread by Light | last post: by
1 post views Thread by ropo | last post: by
3 posts views Thread by Ron | last post: by
11 posts views Thread by Beorne | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
1 post views Thread by Geralt96 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.