CODEWITHSUNDEEP
c#.netvisual-studio-2012entity-framework-5executionengineexception
Alex Shtoff
Alex Shtoff

Reputation: 2640

ExecutionEngineException only when debugging

I have C# code that throws ExecutionEngineException only when I debug it. When I just run it from Visual Studio without debugging (press the "Start without debugging") button, this piece of code works OK. But when I debug it from Visual Studio it throws ExecutionEngineException.

Due to this problem I cannot debug my application, as the code I am trying to debug is executed AFTER the problematic piece of code.

Here are some details:

Edit

Further investigation shows that the actual problem is an access violation exception that originates in the default constructor of System.Data.DataSet, which also happens if I just write new DataSet().

Edit 2 I created a small application that demonstrates this problem. The source code can be found here.

You are welcome to compile it and try and run the project Application. It should crash in Adder.cs with ExecutionEngineException when creating a new DataSet. Please note that the debugger should be Mixed and not Managed/Native.

Upvotes: 2

Views: 1788

Answers (1)

Hans Passant
Hans Passant

Reputation: 941605

Your C++/CLI code is most likely corrupting the garbage collected heap. A very typical way for unmanaged code to misbehave. This doesn't get discovered until later, like when you new an object or the garbage collector runs. So the code that crashes is completely unrelated to the code that caused the corruption and gives you no hint whatsoever where the bug is located.

There is very little joy in debugging this, it typically takes a thorough code review, lots of unit tests on the unmanaged code and days of debugging to find it. The "crashes only in the debug build" scenario is very common as well, it doesn't mean that there is no heap corruption in the release build. You are a bit lucky that it fails like this, heap corruption is way harder to debug when it occurs in the release build. You'll want to invest in a debug allocator to catch the bug in action, like the one you get out of <crtdbg.h>. This problem in general made garbage collectors a favored way to manage memory.

My condolences and good luck with it.

Upvotes: 4

Related Questions