System.ExecutionEngineException Failure

Question

This should not be taken too seriously, but I managed to get this exception while having some fun with reflection:

typeof(IntPtr).GetField("Zero").SetValue(null, new IntPtr(666));

Had the same problem - my bug turned out to be an argument mismatch between my C# code and my C++ native dll. I had added an argument to the C++ function and failed to add it to the C# side.

There is a known bug when a WCF service tries to return an IList or IEnumerable.

http://connect.microsoft.com/wcf/feedback/details/433569/wcf-throws-an-executionengineexception-when-returning-an-array-as-ilist-t

I encountered it when calling a function in an unmanaged library when my managed code was compiled for release. The error goes away when compiled for debugging.

Quoted from the MSDN reference page for System.ExecutionEngineException:

The exception that is thrown when there is an internal error in the execution engine of the common language runtime. This class cannot be inherited.

There is no non-obsolete alternative to ExecutionEngineException. If further execution of your application cannot be sustained, use the FailFast method.

Tip

In some cases, an application that targets the .NET Framework may throw an ExecutionEngineException exception during garbage collection when an application or the system on which it is running is under a heavy load. In this case, To work around this issue, you can disable concurrent garbage collection by modifying the application's configuration file. For more information, see How to: Disable Concurrent Garbage Collection.

Honestly, the only time I've ever seen this exception is when I was using the Compuware DevPartner tools to do some profiling and code analysis. DevPartner hooks deep into the core of the CLR to do it's work, but it's full of bugs, so screws the CLR up. I had to reboot my machine (and remember to never click the DevPartner toolbar buttons ever again) to get things to go back to normal.

If you're not using devpartner, then you most likely have some unmanaged code which is trashing some memory used by the CLR. I'd advise first doing a reboot, and then trying to track down whichever bug you have which is trashing the memory. Look for buffer overruns, writing to uninitialised pointers, and all the other usual suspects.