Why this code throws System.ExecutionEngineException

Question

Background: I am using DirectX 9.0 Managed Libraries to transform arrays of 3d points to 2d screen coordinates. For speed I use the UnsafeNativeMethods to do all the transformations.

The Problem: If my custom line clipping function is used my application dies without throwing any exceptions, it took me a while to figure out that it was throwing an uncatchable System.ExecutionEngineException. I have narrowed it down to happening because of the last two lines of my clipping function.

List<Vector3> verticesAfterClipping = new List<Vector3>;
public unsafe void ClipLine(Line lineToClip)
{
    this.verticesAfterClipping.Clear();

    // Clipping algorithm happens here... (this is psuedo-code of what it does)
    foreach(Vertex in lineToClip.Vertices)
    {
        bool thisIsClipped =   // Set to whether this vertex is clipped
        bool lastWasClipped =  // Set to whether last vertex was clipped

        if(thisIsClipped == false && lastWasClipped == true)
        {
            verticesAfterClipping.Add( /* intersection on clipping plane */ );
            verticesAfterClipping.Add( /* thisVertex */ );
        }
        else if (thisIsClipped == false && lastWasClipped == false)
        {
            verticesAfterClipping.Add( /* thisVertex */ );
        }
        else if (thisIsClipped == true && lastWasClipped == false)
        {
            verticesAfterClipping.Add(/* intersection on clipping plane */);
        }
    }

    // THIS IS WHERE BAD THINGS HAPPEN
    lineToClip.Vertices = new Vertex[verticesAfterClipping.Count];
    verticesAfterClipping.CopyTo(lineToClip.Vertices, 0);
}

When the verticesAfterClipping list is copied to the lineToClip vertices the lineToClip object is then passed to an UnsafeNativeMethod which transforms these vertices to 2d vertices. From everything I can see when I step through it in Debug mode it is working completely fine, until it just dies.

I simply cannot figure out what is wrong. Any help would be much appreciated.

score 30 · Accepted Answer · answered Nov 05 '10 at 09:51

The problem may not actually be occurring in the line that throws an exception. This may just be a symptom of something that happened earlier.

The System.ExecutionEngineException exception is thrown when the CLR detects that something has gone horribly wrong. This can happen some considerable time after the problem occurred. This is because the exception is usually a result of corruption of internal data structures - the CLR discovers that something has got into a state that makes no sense. It throws an uncatchable exception because it's not safe to proceed.

So you might have some code in some completely unrelated part of the system that corrupts something, but this only becomes apparent when this particular piece of code runs. The code you've shown might be just fine. (It also might not be...I don't see anything obvious wrong, but then I don't know the DX 9 managed libraries well. I can't see which feature of this method requires the unsafe keyword, for example.)

Unfortunately, this means you need to start casting the net a bit wider. Pretty much anything that uses either unsafe code, or COM interop is potentially suspect. This will be a long and tedious process, sadly. One way you might approach it is to try gradually simplifying the program: what's the smallest piece of code that can illustrate the problem? (E.g., if you put the code you've shown there into an application that contains nothing else except the simplest possible call to that method, does it still fail?)

You're right when you say that the exception doesn't occur ON those two lines, but it does occur as a RESULT OF those two lines. I replaced those lines and used another temporary buffer to copy clipped vertices and everything is working fine now. I supposed there was some kind of memory access violation occurring under the covers when the line was passed to unsafe native directx methods. — tbridge, Nov 08 '10 at 00:10
Don't assume that the absence of an ExecutionEngineException means the problem has gone away. It may merely be that the CLR is no longer detecting it. By replacing those lines, you may now be in a situation where data is being corrupted, but you no longer get an exception. (The CLR doesn't and cannot guarantee to throw ExecutionEngineException any time anything like this goes wrong. It only throws it when it happens to notice.) So I'd be worried - I'd definitely be trying to get to the bottom of *how* the crash occurred, as right now, there's no reason to be confident you've really fixed it. — Ian Griffiths, Nov 08 '10 at 14:29

score 3 · Answer 2 · answered Jan 22 '15 at 15:06

3

I have the same problem with different libraries. In my case all started long before because I had to run a 32 bit .net app in a 64 bit environment. Well this cause me a lot of trouble, the compatibility between architectures, or between the CLR of your .NET framework may be your problem too.

PS: Now I know what my trouble is but have no idea where is it.

answered Jan 22 '15 at 15:06

Yerko Palma

12,041
5
33
57

3

This was the cause of this error for me. I had my project in AnyCPU and it needed to be x64. As soon as I read your comment it prompted me to try that, which immediately worked. – J. Rockwood Oct 12 '21 at 12:48

score 0 · Answer 3 · edited Oct 26 '18 at 03:42

I have two classes that deal with a particular table in my database

StorageManager - a class that has methods that handle the direct interactions with the database

Controller - a class that has methods to handle the api calls

When a new entry in the table is about to be created, I check child tables for certain values that might already exist.

I wrote these methods to check for pre-existing/duplicates in the wrong class, which ended up causing the executingengineexception to get thrown for me.

Moving the methods so that they lived with the correct database context seemed to fix it for me.

Why this code throws System.ExecutionEngineException

3 Answers3

Linked