none
What are the best steps for debugging a System.EngineExecutionException? RRS feed

  • Question

  • I am working on a project that is a little less straightforward than most.  I am not looking to know what the problem is just the best way to move forward from where I am now, which is lost.  What I know is:

     

    -         Application consists of a WinForms executable hosting WPF based components in a DLL

    -         WPF based components are managed by Unity

    -         One particular component throws a System.EngineExecutionException when it is constructed a second time by another Unity instance after the first one was destroyed.

    -         This means that the new component is not the same object that was originally created.  Verified with ObjectId in Visual Studio.

    -         Attaching windbg to the system returns “Missing image name, possible paged-out or corrupt data.” 

    -         Windbg’s “Analysis –v” identifies the module name that is causing the issue to be I.DLL even though no ModLoad occurred for it.

    -         I.DLL does show in the Unloaded modules portion of “lmvm *” with the data:

    00000001 4802a103   I.DLL  

        Timestamp: Wed Mar 04 15:59:28 1970 (00530050)

        Checksum:  00500041

    -         It is a Visual Studio 2008 project

    -         We are using .Net Framework 3.5 SP1

    -         The OS is Windows XP SP3

    -         Visual Studio gets, um, unstable when viewing the xaml for the component in the designer.  More often than not it causes the IDE to crash with various errors.

     

    Any of the above can be a red herring.  Due to the strange behavior exhibited by System.EngineExecutionExceptions I’m not even sure that the component where the problem is even the problem component.

     

    Does anyone have any thoughts on the best way to diagnosis this error?  I’ve been reduced to a less than quantitative tweak and check approach.

     

    Thank you,

     

    Michael

    Thursday, January 28, 2010 10:49 PM

Answers

  • Hi Michael,

    Now we can think that the exception should be raised by the following code line:
     Invariant.Assert(resContainer != null
    
    
    , "ResourceContainer should not be null"
    
    
    );
    We can take the following steps to investigate this issue:

    1. You can type MS.Internal.IO.Packaging.PreloadedPackages._packagePairs in Watch window to check the _packagePairs field. From the following code for GetPackage, we want to confirm whether the required URL doesn't exist in this field.  
    private static HybridDictionary _packagePairs ;

    internal static Package GetPackage(Uri uri, out bool threadSafe)
    {
        ValidateUriKey(uri);
        lock (_globalLock)
        {
            Package package = null;
            threadSafe = false;
            if (_packagePairs != null)
            {
                PackageThreadSafePair pair = _packagePairs[uri] as PackageThreadSafePair;
                if (pair != null)
                {
                    package = pair.Package;
                    threadSafe = pair.ThreadSafe;
                }
            }
            return package;
        }
    }
    2. You can add the breakpoints to the following methods to investigate whether other method calls the following methods to remove the _packagePairs field here between the first call and following call. We want to know which method modifies this field to raise the error.


    internal static void Clear();
    internal static void RemovePackage(Uri uri);


    Best regards,
    Riquel
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, February 1, 2010 6:51 AM
    Moderator

All replies

  • Hi Michael,

    From MSDN document, we can know:

    http://msdn.microsoft.com/en-us/library/system.executionengineexception.aspx

     

    ExecutionEngineException represents fatal errors in the common language runtime (CLR). When it is not possible for the CLR to continue execution, typically because of fatal internal errors, the CLR calls the FailFast(String, Exception) method and supplies ExecutionEngineException as the second parameter. The CLR never throws this exception in such a way that managed code can catch it.

     

    Applications should not throw ExecutionEngineException.

     

    ExecutionEngineException uses the HRESULT COR_E_EXECUTIONENGINE, which has the value 0x80131506.

     

    In this situation typically we need to check the current call stack to try confirming which assembly is related to this exception. Commonly this exception is caused by internal memory corruption which is usually caused by unmanaged code entering the internal data, for example doing a lot of P/Invoke or a heavily multi-threaded app with multiple appdomains. It is best to give us one small code sample so that we can reproduce this situation to investigate this issue.

     

     


    Best regards,
    Riquel
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, January 29, 2010 5:42 AM
    Moderator
  • Riquel,

    Thank you for taking the time to respond.  Unfortunately, I am in the chicken and the egg type scenario right now.  If I knew enough about the problem to create a small reproduction I probably would not have had to resort to posting to the forum!  :)

    The stack trace doesn't touch very much of my code:

    STACK_TEXT: 
    0395ee1d WindowsBase!MS.Internal.Invariant.FailFast+0x25
    03e89811 WindowsBase!MS.Internal.Invariant.Assert+0x11
    03e8987d PresentationFramework!System.Windows.Application.GetResourceOrContentPart+0x55
    03e892ea PresentationFramework!System.Windows.Application.LoadComponent+0xda
    0d8333e1 !Client.Foundation.Components.ActivityBar.DefaultActivityBarView.InitializeComponent+0x79
    0d833300 !Client.Foundation.Components.ActivityBar.DefaultActivityBarView..ctor+0x108
    039453c8 !DynamicClass.BuildUp_Client.Foundation.Components.ActivityBar.DefaultActivityBarView+0x130
    08968c65 !Microsoft.Practices.ObjectBuilder2.DynamicMethodBuildPlan.BuildUp+0xd
    08966308 !Microsoft.Practices.ObjectBuilder2.BuildPlanStrategy.PreBuildUp+0xc0

    The only code in the ctor before InitializeComponent is some code that I added to try to get some more details after the problem was first detected. 

    There are some P/Invokes but I would not say heavy usage.  The app is heavily multithreaded but only one Appdoman.

    Michael Fischer
    Friday, January 29, 2010 3:03 PM
  • I have partially tracked the code that causes the issue to System.Windows.Application.GetResourceOrContentPart.  The call to PreloadedPackages.GetPackage(pacakgeUri) returns null even though it is called with the same parameters that was previously successful.  Haven't been able to find out what happens in GetPackage that would cause the issue.

            private static PackagePart GetResourceOrContentPart(Uri uri)
            { 
                // Caller examines the input parameter. 
                // It should be either a relative or pack application uri here.
                Uri packAppUri = BaseUriHelper.PackAppBaseUri; 
                Uri resolvedUri = BindUriHelper.GetResolvedUri(packAppUri, uri);
    
                // Using PackUriHelper.ValidateAndGetPackUriComponents internal method
                // to get Package and Part Uri in one step 
                Uri packageUri;
                Uri partUri; 
                PackUriHelper.ValidateAndGetPackUriComponents(resolvedUri, out packageUri, out partUri); 
    
                // 
                // ResourceContainer must have been added into the package cache, the code should just
                // take use of that ResourceContainer instance, instead of creating a new instance here.
                //
                ResourceContainer resContainer = PreloadedPackages.GetPackage(packageUri) as ResourceContainer; 
                Invariant.Assert(resContainer != null, "ResourceContainer should not be null");
     
                return resContainer.GetPart(partUri); 
            }
    Thanks

    Michael
    • Edited by _Michael Fischer_ Friday, January 29, 2010 5:37 PM Bolding a line of code did not work... removed it.
    Friday, January 29, 2010 5:36 PM
  • Hi Michael,

    Now we can think that the exception should be raised by the following code line:
     Invariant.Assert(resContainer != null
    
    
    , "ResourceContainer should not be null"
    
    
    );
    We can take the following steps to investigate this issue:

    1. You can type MS.Internal.IO.Packaging.PreloadedPackages._packagePairs in Watch window to check the _packagePairs field. From the following code for GetPackage, we want to confirm whether the required URL doesn't exist in this field.  
    private static HybridDictionary _packagePairs ;

    internal static Package GetPackage(Uri uri, out bool threadSafe)
    {
        ValidateUriKey(uri);
        lock (_globalLock)
        {
            Package package = null;
            threadSafe = false;
            if (_packagePairs != null)
            {
                PackageThreadSafePair pair = _packagePairs[uri] as PackageThreadSafePair;
                if (pair != null)
                {
                    package = pair.Package;
                    threadSafe = pair.ThreadSafe;
                }
            }
            return package;
        }
    }
    2. You can add the breakpoints to the following methods to investigate whether other method calls the following methods to remove the _packagePairs field here between the first call and following call. We want to know which method modifies this field to raise the error.


    internal static void Clear();
    internal static void RemovePackage(Uri uri);


    Best regards,
    Riquel
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, February 1, 2010 6:51 AM
    Moderator
  • Riquel,

    Thank you.  Step 2 was more important than Step 1 in tracking down the root of my issue.  Fortunately, there was only one place that called Clear() so I was able to track down the root cause.  In hindsight, an obvious step in debugging.  I let me self get distracted by the original exception.  Still had some digging to do but  I was able to find the code that was causing the problem and work with the developer that added it to figure out the best way to fix it.

    Michael Fischer
    Monday, February 1, 2010 8:26 PM
  • Hi Michael,

    Glad to hear that you know how to fix this question. If you have any further issues, feel free to discuss them with us in MSDN forums.
    Best regards,
    Riquel
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Tuesday, February 2, 2010 2:12 AM
    Moderator