none
LoaderLock exception thrown when calling Delete method on CommandBarButton

    Question

  • I've got a very simple add-in (pretty much cadged from the how to article about building managed addins in C#). However, due to security requirements for where it'll be deployed I'm using a VC++ shim (totally cadged from a how to article) to sit in between Word and the managed addin

    In the OnBeginShutDown I'm calling something like

    GetVariablesButton.Delete(temporaryTrue);

    GetVariablesButton is a member CommandBarButton variable (referencing a button on Words 'standard' CommandBar) and temporaryTrue is a local object variable cast to True (I've also tried the call to Delete with a literal boolean True, a bool variable set to True and a Missing.Value variable).

    When the Delete method is called while debugging the following exception is thrown:

    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 have absolutely no idea what this means and following the help trail doesn't illuminate my confusion any further. 

    Thanks in advance and apologies if I've posted this in the wrong place (If I have, a pointer to the right place would be very much appreciated

    Tuesday, January 31, 2006 5:29 PM

Answers

  • Hi,

    The LoaderLock mda fires when you are executing managed code inside the loader lock.  The loader lock is essentially a synchronization object that provides mutual exclusion during Dll loads and unloads.  The idea is to prevent the process state from getting out of whack as well as to prevent Dlls from being re-entered before they have had a chance to completely initialize.  CBrumme provides a pretty detailed explanation of the issues around LoaderLock in his blog: http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx

    Also, the mda help can be found here: http://msdn2.microsoft.com/en-us/library/ms172219.aspx

    Finally, here is some background on the problem as it existed pre VS 2005:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vcconMixedDLLLoadingProblem.asp

    Anyway, to fix this problem, you just need to figure out where the call is coming from.  To do that you'll want to get a complete mixed stack dump.  You may need to use WinDbg for this if Visual Studio doesn't give you the complete picture.  If you don't have it, you can get it here: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

    Once you get the stack dump, you need to identify where the loader lock violation has occured.  The most common case would be a call out of DllMain, but there are other cases where the operating system implicitly takes the lock (as described in Chris's blog).  Once you find out where the call is coming from, you can ideally prevent it from occuring while inside the loader lock. 

    You might also decide that there is no risk that the operating system will attempt to re-enter the loader lock from your code (which would result in deadlock).  As Chris states in his blog, there are cases where it is valid to break this rule.  So while you should certainly investigate, you may choose not to fix it.

    If you decide not to fix this, you may want to disable the mda.  Go to Debug.Exceptions and uncheck the MDA under "Managed Debug Exceptions" if you want it out of your face. 

    Hope that helps,

    Geoff Darst

    Microsoft VSTO Team

     

     

    Wednesday, February 01, 2006 1:08 AM

All replies

  • Hi,

    The LoaderLock mda fires when you are executing managed code inside the loader lock.  The loader lock is essentially a synchronization object that provides mutual exclusion during Dll loads and unloads.  The idea is to prevent the process state from getting out of whack as well as to prevent Dlls from being re-entered before they have had a chance to completely initialize.  CBrumme provides a pretty detailed explanation of the issues around LoaderLock in his blog: http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx

    Also, the mda help can be found here: http://msdn2.microsoft.com/en-us/library/ms172219.aspx

    Finally, here is some background on the problem as it existed pre VS 2005:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vcconMixedDLLLoadingProblem.asp

    Anyway, to fix this problem, you just need to figure out where the call is coming from.  To do that you'll want to get a complete mixed stack dump.  You may need to use WinDbg for this if Visual Studio doesn't give you the complete picture.  If you don't have it, you can get it here: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

    Once you get the stack dump, you need to identify where the loader lock violation has occured.  The most common case would be a call out of DllMain, but there are other cases where the operating system implicitly takes the lock (as described in Chris's blog).  Once you find out where the call is coming from, you can ideally prevent it from occuring while inside the loader lock. 

    You might also decide that there is no risk that the operating system will attempt to re-enter the loader lock from your code (which would result in deadlock).  As Chris states in his blog, there are cases where it is valid to break this rule.  So while you should certainly investigate, you may choose not to fix it.

    If you decide not to fix this, you may want to disable the mda.  Go to Debug.Exceptions and uncheck the MDA under "Managed Debug Exceptions" if you want it out of your face. 

    Hope that helps,

    Geoff Darst

    Microsoft VSTO Team

     

     

    Wednesday, February 01, 2006 1:08 AM
  • Hmmm...some reading to be done here I see.

    I'll mark this thread answered and if I still can't work things out I'll post with something more specific

     

    Many thanks

    Wednesday, February 01, 2006 9:09 AM
  • This does happen a lot in VSTO based development, i have found an option you can do to turn of the MDA that may stop the frustrations, but have not found out why this "Sometimes" happens but in my scenario always on a VSTO solution.

    Disable the loader lock MDA. Debug/Exceptions (ctrl-D, E), Open the Managed Debugging Assistants tree node and uncheck Loader Lock. This is a Visual Studio wide setting so we must remember to turn this back on when and or if you have other scenarios that maybe needing this to be fired.

    Regards

    Wednesday, March 22, 2006 12:24 AM
  • I've had the problem working with SharePoint's 2007 SPFile objects that represented images in image libraries. Thanks Mike

    Cheers, David

    Tuesday, March 20, 2007 10:48 PM
  • @Mike Walker's Mar 22/06 post - According to this post the MDA setting is per solution not for the entire IDE.
    Wednesday, March 21, 2007 4:29 AM