Please help me on LoaderLock ...

[Beorne]

I'm trying to call a third party dll routine from C# using pinvoke.
Unfortunately I obtain a LoaderLock exception and my application
stops. I've seen that it must be some uncorrect behaviour of the
called routine, but I can't modify it.

Note that calling this routine from a C++ project does not give off
any error.

How can I do?
Thank you!

[Nicholas Paldino [.NET/C# MVP]]

Beorne,

Without seeing the declaration of the method to call through P/Invoke,
as well as the original declaration in C++, as well as the call site in C#,
and any needed structures/typedefs, it's impossible to say.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Beorne" <ma*******@gmail.comwrote in message
news:11**********************@y2g2000prf.googlegro ups.com...

I'm trying to call a third party dll routine from C# using pinvoke.
Unfortunately I obtain a LoaderLock exception and my application
stops. I've seen that it must be some uncorrect behaviour of the
called routine, but I can't modify it.

Note that calling this routine from a C++ project does not give off
any error.

How can I do?
Thank you!

[Willy Denoyette [MVP]]

"Beorne" <ma*******@gmail.comwrote in message
news:11**********************@y2g2000prf.googlegro ups.com...

I'm trying to call a third party dll routine from C# using pinvoke.
Unfortunately I obtain a LoaderLock exception and my application
stops. I've seen that it must be some uncorrect behaviour of the
called routine, but I can't modify it.

Note that calling this routine from a C++ project does not give off
any error.

How can I do?
Thank you!

The problem is with the DLL, for one or another reason it calls (directly or
indirectly) into managed code while under the loader lock. If this happens
at the first call into this DLL, it means that call is done from within DLL
main. Anyway, there is very little you can do about this, I would suggest
you to ping that back to the third party and ask for a fix the DLL. Note
that the exception is thrown when running in the debugger only, what happens
with your application when run in release mode?

Willy.

[not_a_commie]

The loader-lock warning shows up with numerous 3rd-party GUI DLLs as
well as MS's own managed DirectX9 stuff. It's mostly harmless. Shut it
off in the exceptions list under Managed Debugging Assistants.

[Peter Duniho]

On Mon, 21 May 2007 08:37:02 -0700, Willy Denoyette [MVP]
<wi*************@telenet.bewrote:

The problem is with the DLL, for one or another reason it calls
(directly or indirectly) into managed code while under the loader lock.
If this happens at the first call into this DLL, it means that call is
done from within DLL main. Anyway, there is very little you can do about
this, I would suggest you to ping that back to the third party and ask
for a fix the DLL.

For what it's worth, the only time I've seen this MDA is when using the
DirectX.AudioVideoPlayback component. It does seem to work properly, and
I just wind up disabling that MDA exception when using the
AudioVideoPlayback component.

Just who should I "ping that back to" at Microsoft, since it's their
component?

Pete

[Willy Denoyette [MVP]]

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

On Mon, 21 May 2007 08:37:02 -0700, Willy Denoyette [MVP]
<wi*************@telenet.bewrote:

>The problem is with the DLL, for one or another reason it calls
(directly or indirectly) into managed code while under the loader lock.
If this happens at the first call into this DLL, it means that call is
done from within DLL main. Anyway, there is very little you can do about
this, I would suggest you to ping that back to the third party and ask
for a fix the DLL.

For what it's worth, the only time I've seen this MDA is when using the
DirectX.AudioVideoPlayback component. It does seem to work properly, and
I just wind up disabling that MDA exception when using the
AudioVideoPlayback component.

Just who should I "ping that back to" at Microsoft, since it's their
component?

Pete

[Willy Denoyette [MVP]]

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

On Mon, 21 May 2007 08:37:02 -0700, Willy Denoyette [MVP]
<wi*************@telenet.bewrote:

>The problem is with the DLL, for one or another reason it calls
(directly or indirectly) into managed code while under the loader lock.
If this happens at the first call into this DLL, it means that call is
done from within DLL main. Anyway, there is very little you can do about
this, I would suggest you to ping that back to the third party and ask
for a fix the DLL.

For what it's worth, the only time I've seen this MDA is when using the
DirectX.AudioVideoPlayback component. It does seem to work properly, and
I just wind up disabling that MDA exception when using the
AudioVideoPlayback component.

Just who should I "ping that back to" at Microsoft, since it's their
component?

Pete

True , the MDX dll's are "broken" in this sense, note that the MDA is a
warning that you are actually operating under the loaderlock, if you take
another loader lock while under this lock, you will deadlock. MS apparently
assumes that there is no real danger for this to happen ;-).
MDX components are at v1.1, aren't we supposed to move from MDX to XNA?

Willy.

[Peter Duniho]

On Mon, 21 May 2007 12:34:11 -0700, Willy Denoyette [MVP]
<wi*************@telenet.bewrote:

True , the MDX dll's are "broken" in this sense, note that the MDA is a
warning that you are actually operating under the loaderlock, if you
take another loader lock while under this lock, you will deadlock. MS
apparently assumes that there is no real danger for this to happen ;-).

Well, so far so good. :) I don't know if they're right, but I haven't
deadlocked yet. :)

MDX components are at v1.1, aren't we supposed to move from MDX to XNA?

Are we? I don't even know anything about XNA yet. If it's as easy to get
as the MDX, that's fine with me. If not, I can't imagine why I'd switch.
:)

Pete

[Willy Denoyette [MVP]]

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

On Mon, 21 May 2007 12:34:11 -0700, Willy Denoyette [MVP]
<wi*************@telenet.bewrote:

>True , the MDX dll's are "broken" in this sense, note that the MDA is a
warning that you are actually operating under the loaderlock, if you
take another loader lock while under this lock, you will deadlock. MS
apparently assumes that there is no real danger for this to happen ;-).

Well, so far so good. :) I don't know if they're right, but I haven't
deadlocked yet. :)

>MDX components are at v1.1, aren't we supposed to move from MDX to XNA?

Are we? I don't even know anything about XNA yet. If it's as easy to get
as the MDX, that's fine with me. If not, I can't imagine why I'd switch.
:)

Could be wrong, but as far as I know XNA was announced to be the successor
of MDX, the latest MDX was built for v1.1 of the framework while the XNA
framework uses .NET v2, note also that MDX 2.0 (since years in beta) is no
longer included in the DX SDK.
This http://msdn2.microsoft.com/en-us/library/bb197956.aspx maybe you will
find some answers about MDX vs. XNA.

Willy.

[Peter Duniho]

On Mon, 21 May 2007 14:34:50 -0700, Willy Denoyette [MVP]
<wi*************@telenet.bewrote:

Could be wrong, but as far as I know XNA was announced to be the
successor of MDX, the latest MDX was built for v1.1 of the framework
while the XNA framework uses .NET v2, note also that MDX 2.0 (since
years in beta) is no longer included in the DX SDK.
This http://msdn2.microsoft.com/en-us/library/bb197956.aspx maybe you
will find some answers about MDX vs. XNA.

Well, as near as I can tell from that page and some nearby ones, XNA
doesn't provide any video support at all. Presumably this is a
consequence of DirectShow being moved out of the DirectX SDK and into the
Platform SDK, or maybe they moved it because they didn't want it in XNA.

Either way, the "Video" part of the AudioVideoPlayback component in MDX
doesn't appear to be supported in XNA. So, at least for that component,
XNA is definitely not a new a better way to access the functionality minus
the Loader Lock MDA exception.

Pete

[Willy Denoyette [MVP]]

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

On Mon, 21 May 2007 14:34:50 -0700, Willy Denoyette [MVP]
<wi*************@telenet.bewrote:

>Could be wrong, but as far as I know XNA was announced to be the
successor of MDX, the latest MDX was built for v1.1 of the framework
while the XNA framework uses .NET v2, note also that MDX 2.0 (since
years in beta) is no longer included in the DX SDK.
This http://msdn2.microsoft.com/en-us/library/bb197956.aspx maybe you
will find some answers about MDX vs. XNA.

Well, as near as I can tell from that page and some nearby ones, XNA
doesn't provide any video support at all. Presumably this is a
consequence of DirectShow being moved out of the DirectX SDK and into the
Platform SDK, or maybe they moved it because they didn't want it in XNA.

Either way, the "Video" part of the AudioVideoPlayback component in MDX
doesn't appear to be supported in XNA. So, at least for that component,
XNA is definitely not a new a better way to access the functionality minus
the Loader Lock MDA exception.

Pete

I see, well I guess you could contact Michael Klucher (XNA PM) and ask about
the status of MDX vs. XNA, see if they plan to add this feature to XNA, or
they'll offer an alternative.. All I know is that MDX, which was built
around V1.1 using ME C++ ( hence the Loader Lock issue on V2), is a "dead"
product.

Willy.

[Ben Voigt]

"Beorne" <ma*******@gmail.comwrote in message
news:11**********************@y2g2000prf.googlegro ups.com...

I'm trying to call a third party dll routine from C# using pinvoke.
Unfortunately I obtain a LoaderLock exception and my application
stops. I've seen that it must be some uncorrect behaviour of the
called routine, but I can't modify it.

Note that calling this routine from a C++ project does not give off
any error.

You may be able to get somewhere by forcing the needed DLLs to load, outside
LoaderLock, before calling the buggy component. That is probably what is
happening with C++. Dependency Walker could show you what DLLs are being
used.

>
How can I do?
Thank you!