C# – Fatal Execution Engine Error (79FFEE24) (80131506)

The problem was where the DLLs were located.

• c:\dlls\managed.dll
• c:\dlls\wrapper.dll
• c:\exe\my.exe

I confirmed this by copying managed.dll into c:\exe and it worked without issue. Apparently, the CLR won't look for managed DLLs in the path of the unmanaged DLL and will only look for it where the executable is. (or in the GAC).

For reasons not worth going into, this is the structure I need, which meant that I needed to give the CLR a hand in located the managed dll. See code below:

AssemblyResolver.h:

/// <summary>
/// Summary for AssemblyResolver
/// </summary>
public ref class AssemblyResolver
{
public:

static Assembly^ MyResolveEventHandler( Object^ sender, ResolveEventArgs^ args )
{
    Console::WriteLine( "Resolving..." );

    Assembly^ thisAssembly = Assembly::GetExecutingAssembly();
    String^ thisPath = thisAssembly->Location;
    String^ directory = Path::GetDirectoryName(thisPath);
    String^ pathToManagedAssembly = Path::Combine(directory, "managed.dll");

    Assembly^ newAssembly = Assembly::LoadFile(pathToManagedAssembly);
    return newAssembly;
}

};

Wrapper.cpp:

#include "AssemblyResolver.h"

extern "C" __declspec(dllexport) IMyObject* CreateMyObject(void)
{
    try
    {
        AppDomain^ currentDomain = AppDomain::CurrentDomain;
        currentDomain->AssemblyResolve += gcnew ResolveEventHandler( AssemblyResolver::MyResolveEventHandler );

        return new CMyWrapper( );
    }
    catch(System::Exception^ e)
    {
        System::Console::WriteLine(e->Message);

        return NULL;
    }
}

Short answer: read the blog of Tess Ferrandez. This contains lots of invaluable guidance to debugging .NET applications and guides you through how to do it.

Longer answer...

Within Visual Studio

If you have Visual Studio installed you could try breaking on any unhandled .NET exception. To enable this, go to the menu and choose Debug, Exceptions and tick Common Language Runtime Exceptions. Then go to Tools, Options, Debugging and untick Enable Just My Code. Finally, attach to the process of the Configuration Wizard (you obviously need it running first) and the Visual Studio debugger will break at the point the exception occurs.

Assuming the debugger breaks (if it doesn't you have attached to the wrong process) then you should have access to the call stack and can make some educated guesses from the method names about what is going wrong. However there is a possibility this is obfuscated which won't be helpful. You will also be able to see the current MSIL instruction the debugger has stopped on. This is where it starts getting a bit beyond me but there are good references out there to help you understand what's happening in the code.

Without Visual Studio

If you don't have Visual Studio or for some reason can't get the debugger to break, then it is possible to create a dump of the crashing process. There are two methods I know of. One is described by the Windows Server Performance Team using good ol' Dr Watson. The other is a new tool has just been released by Mark Russinovich called ProcInfo that can automatically create a dump of a process that crashes through unhandled exceptions. There are probably other methods.

Once you have the dump you can use this KB article to help you get set up to debug it.

Finally

Return to the 'short answer' above: read Tess' blog to progress further! This is a big topic and she has the best resources I've eveer found. Also there is a good post by Vincent Rothwell which might help but it's really targeted towards debugging your own code.

As an aside - you shouldn't be getting the exceptions you are. It indicates a pretty serious problem. I would look at corruption, serious hardware faults, and consider a rebuild.