ExecutionEngineException explained

 
Last week several of our developers, myself included, experienced repeatable crashes of our Windows Forms application with an ExecutionEngineException.  MSDN describes it as "The exception that is thrown when there is an internal error in the execution engine of the common language runtime.", which didn't help us to track it down.  The debugger was useless, as ExecutionEngineException cannot be caught and the callstack was pointing into a Application Block that hadn't changed. 
 
Our problem turned out to be old versions of some of our assemblies in a folder that was in the DEVPATH environment variable.  Our nAnt build uses the resgen tool, which requires setting the DEVPATH variable.  Unfortunately, DEVPATH breaks the normal .NET loading rules.  DEVPATH assemblies are bound to at runtime, ignoring the assembly version, and overriding the GAC.  (http://blogs.msdn.com/suzcook/archive/2003/08/15/57238.aspx)
 
Lessons learned:
  1. Don't use DEVPATH - See Suzanne Cook's linked blog above for all the reasons why
  2. One cause of ExecutionEngineException is mixing assemblies at runtime that weren't compiled together on the last compile.
  3. If only some developers or users are experiencing a problem, don't write it off as unreproducible.  Finding the difference that causes the problem will lead you to the solution.

 

No Comments