🔒 Locked

[.net] .NET 2.0 "OS Loader Lock" exception

Started by BeanDog Dec 7, 2005 at 7:19 PM 11 replies 27.6k views

Original Post

Dec 7, 2005 at 7:19 PM

I have a class library that I use in my main application. Under .NET 1.1, it worked great. Under 2.0, I get a new exception: LoaderLock was detected Message: DLL 'D:\My Documents\Visual Studio 2005\Projects\SVS_Client\bin\Debug\SQLiteNET.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. Ooookay. What is this? How do I know when is an appropriate time to begin executing code from the assembly? SQLiteNET.dll does call non-managed code, maybe that has something to do with it. So much for breakless upgrading :-p ~BenDilts( void );

rfterdarc

Dec 7, 2005 at 7:24 PM

in the menu try: Debug -> Exceptions..., and disable something in there

BeanDog

Dec 7, 2005 at 9:37 PM

They weren't kidding with that message, though--the program hangs.

Shinkage

Dec 10, 2005 at 4:58 PM

Essentially, the current version of DirectX doesn't play well with the current version of Visual Studio. It's a known issue and should be resolved in the next update to the DirectX library (not sure where I read this, but it was somewhere on Microsoft's site).

Right now you're just going to have to disable that exception from being thrown. Hit the Debug->Exceptions... menu item, open up the open up the "Managed Debugging Assistant" item, and uncheck the box next to the "LoaderLock" item. IIRC you should be fine in most situations as long as you avoid calling stuff from your DllMain function.

Arild Fines

Dec 10, 2005 at 5:33 PM

It's not an "exception" per se. The Managed Debugging Assistants are a set of probes looking for common errors in .NET applications. Running code inside the OS loader lock is one of them. All DLLs created in Managed C++ with the VC2002 compiler would have this problem. VC2003 gave you a way to avoid it, but it was pretty tricky and few bothered, especially since the problem very rarely manifests itself.

Mrs Kensington

Dec 13, 2005 at 10:52 AM

This should be fixed now as the December 2005 DirectX SDK has been released with non-beta 2.0 versions of Managed DirectX.

See here for more info.

Arild Fines

Dec 13, 2005 at 11:14 AM

Quote:
Original post by Mrs Kensington
This should be fixed now as the December 2005 DirectX SDK has been released with non-beta 2.0 versions of Managed DirectX.

I'm not sure what Managed DirectX has to do with this:

Message: DLL 'D:\My Documents\Visual Studio 2005\Projects\SVS_Client\bin\Debug\SQLiteNET.dll' is attempting managed execution inside OS Loader lock

Shinkage

Dec 13, 2005 at 1:09 PM

Woops. I've gotten so accustomed to seeing this message in this context coming from the managed directx runtime my brain just kinda skipped over the DLL file it was coming from. Looks like SQLiteNet needs to be updated for .NET 2.0 as well.

Krisc

Dec 14, 2005 at 3:42 AM

I got the error when trying to create an instance and initialize a Device inside a constructor. Perhaps that is your problem, even though it has nothing to do with DirectX?

Arild Fines

Dec 14, 2005 at 10:53 AM

Quote:
Original post by Krisc
I got the error when trying to create an instance and initialize a Device inside a constructor. Perhaps that is your problem, even though it has nothing to do with DirectX?

No. The issue here is that SQLiteNet.dll is a mixed-mode (contains both managed and unmanaged code) DLL compiled with either Visual Studio 2002 or 2003. All 2002-compiled DLLs will have this problem as well as most 2003 DLLs. The only way to deal with it is to turn off the warning.

vidalsasoon

Dec 17, 2005 at 6:26 PM

I also had this problem today. I fixed it with help from this article:

http://msdn2.microsoft.com/en-us/library/ms173267.aspx

...but I had the source file to recompile.

DmGoober

Aug 20, 2006 at 11:15 PM

This worked for me:
1) Remove the references to the assemblies that are LoaderLocking. (I recommend writing down the path to the assembly so you don't forget it.)
2) Rebuild. The build will fail.
3) Add back the references to the assemblies you just removed.
4) Rebuild and re-run.

Alexander

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.