problems turning off LoaderLock MDA

  • Thread starter Thread starter casey chesnut
  • Start date Start date
C

casey chesnut

i've got a test WinForm executable that instantiates a DirectSound object in
the Forms constructor,
so it gives me the LoaderLock MDA exception.

following the instructions here :
http://msdn2.microsoft.com/en-us/library/d21c150d(en-US,VS.80).aspx
i've run the registry script to disable all MDAs and also created the
AppName.exe.mda.config file with loaderLock enable="false"
.... but i'm still getting the MDA warning when in VS 2005 and doing
debug-start debugging.

the only thing that works for me is if i have run the disable script and
turn on the 'enable unmanaged code debugging' checkbox.
first question, why do i have to run the registry script and 'enable
unmanaged code debugging' to get it to go away.
second question, why is the AppName.exe.mda.config not working?

i tried doing this logic in another thread that was created in the
constructor, but i get the same error.
third question, what is the proper way to get around this problem in code,
without having to change the environment?

Thanks,
casey
http://www.brains-N-brawn.com
 
I too have encountered a great deal of frustration with the LoaderLock MDA.
I had a splash window that would use SHGetFileInfo to retrieve some file
information, on a second thread before an ApplicationContext was run using
Application.Run. Bombed everytime.

Keep in mind this was code that worked perfectly (or at least without
crashing or generating warnings in .NET 1.0 and 1.1). I would definitely
enjoy a clear explanation of just exactly what the deal with that is.

I seem to recall that all of my research indicated this was only a problem
for mixed mode assemblies. I'm dealing with pure C# and some Interop calls
for the Windows API functions, and I still get the LoaderLock.

I'm also loading Assemblies on the fly using Assembly.LoadFrom in secondary
AppDomains, again all of this is occurring before the main message loop is
created via Application.Run.

I've not explored this in any great detail at the moment, but I would
greatly appreciate any thoughts and ideas on this as well.
 
Without a lot of explaning (I did this some time ago, and the references I
found are lost to me), the easiest solution to this issue is:

Use the "Debug" menu, and go to "Exceptions..."

Expand the "Managed Debugging Assistants" and uncheck the "Thrown" and
possibly "User-unhandled" boxes (if using the "Just My Code" option).

All I can remember about it right now is that there is an issue with the
Managed Debugging Assistant for "Loader Lock". I have never had any problems
as a result of turning this off.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.
 
A third side effect not addressed in this thread is the extremely large
delay (that is quite unmanageable) when stepping into/over breakpoints
before the main application message loop is created using Application.Run.

I never receieved any exceptions (i.e., the LoaderLock exception) unless i
was trying to debug code before the message loop was created. Has anyone
else run into behavior like this?

Even when I disabled the MDAs for said problems, I still experienced the
same step into/over delays (i.e., upwards of 30-60 seconds to step into a
line of my own code, with "Just My Code" enabled.).
 
Thanks Kevin, but i'm really hoping for a better solution.

This code i'm writing is developed by a team,
and i really do not want to have every group member go and make that tools
change.
So i'm hoping to get .mda.config to work correctly.

Else, i want to know how to get around this in code.
I've tried the Invoke model as well ... still get the exception.

From all the searching i've done on the internet,
most everybody is manually turning it off one way or another.
I don't really consider that acceptable at the moment.

Thanks,
casey
http://www.brains-N-brawn.com
 
From all the searching i've done on the internet,
most everybody is manually turning it off one way or another.
I don't really consider that acceptable at the moment.
Click to expand...

It's not acceptable overall, but it *is* acceptable "at the moment." I fully
expect it to be fixed with the next Service Pack. At least I certainly
*hope* so!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.
 
| Thanks Kevin, but i'm really hoping for a better solution.
|
| This code i'm writing is developed by a team,
| and i really do not want to have every group member go and make that tools
| change.
| So i'm hoping to get .mda.config to work correctly.
|
| Else, i want to know how to get around this in code.
| I've tried the Invoke model as well ... still get the exception.
|
| From all the searching i've done on the internet,
| most everybody is manually turning it off one way or another.
| I don't really consider that acceptable at the moment.
|
| Thanks,
| casey
| http://www.brains-N-brawn.com
|
|
The MDA is a debugging aid, and all MDA's should be taken seriously.
The only way to ged rid of the MDA is by fixing the code, in your case you
could try to build against the December drop of the DirectX sdk, this
version supports v2 of the framework.

Willy.
 
thought you had it ... because i was using October SDK; but just installed
December and still get it.

i've tried creating another thread to do the initalization, as well as
following the invoke pattern ... any other ideas?

Thanks,
casey
 
Do you have some code handy that gives me an idea what you are doing, that
way I can try to repro the case and file a bug. All I've done (not that much
though) seems to work with the latest build.

Willy.

| thought you had it ... because i was using October SDK; but just installed
| December and still get it.
|
| i've tried creating another thread to do the initalization, as well as
| following the invoke pattern ... any other ideas?
|
| Thanks,
| casey
|
| > The MDA is a debugging aid, and all MDA's should be taken seriously.
| > The only way to ged rid of the MDA is by fixing the code, in your case
you
| > could try to build against the December drop of the DirectX sdk, this
| > version supports v2 of the framework.
| >
| > Willy.
| >
| >
|
|
 
Back
Top