6

We have a situation where our application sometimes raises an ExecutionEngineException. I thought that when it happens, the application should crash, but it does not crash. And even if the event viewer claims that the application was terminated - it continues running! Only seems that the offending thread is silently killed.

The problem is that we are unable to recreate the conditions when it occurs - the suspected code is executed thousands of times before the exception occurs. There is nothing in the logs. In short - we are puzzled.

I would like to be able to generate this exception at will in order to learn how our application behaves when it happens. Of course, it must be thrown by the framework itself, issuing throw new ExecutionEngineException does not count.

So, my question is - how can I cause it reliably? Please, provide a code sample.

We are on .NET 4, moving soon to .NET 4.5

Tomas Kubes
  • 23,880
  • 18
  • 111
  • 148
mark
  • 59,016
  • 79
  • 296
  • 580

2 Answers2

4

From the MSDN documentation:

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.

In case the workaround suggested by the MSDN documentation doesn't work for you, you will have to test based on what you know about your software.

Now, creating a test application that simulates load, multi-thread behaviour and memory consumption of your real application is one thing - it is probably better to use the actual software as test software (perhaps augmented with some additional debug-logging + test code). That means, unfortunately no code sample here :(

To make the load tests meaningful, you would also need to run these tests on a test system that has a very similar, if not identical hardware/software configuration as your production system. And only then you will be able to find out if your ExecutionEngineException is caused by the GC or by an otherwise corrupted runtime.

  • I am pretty convinced that EEE can occur under less stressful circumstances. Browsing the web creates an impression that dynamically emitted IL code may result in such an exception. – mark Oct 30 '13 at 01:07
  • If buggy 'hand-crafted' IL code is the culprit, as a first guess it would be more likely that your problem would be reproducible in a consistent manner. The problem only happen 'sometimes' as a first guess points at some issue regarding exhausted resources or race conditions. Anyway, all of them are possible causes and you will not have another way than to check each of those possibilities until you found the cause of the problem :( –  Oct 30 '13 at 01:20
1

You cannot cause ExecutionEngineException easily unless you reproduce the issue (even if you have to do that in production environment). Microsoft has utilities such as DebugDiag that can help you capture full memory dumps when such exceptions occur,

http://blogs.msdn.com/b/chaun/archive/2013/09/15/steps-to-trigger-a-user-dump-of-a-process-with-debugdiag-1-2-when-a-specific-net-exception-is-thrown.aspx

and via dump analysis it is easy to locate the culprit. Don't expect your logs can tell, as when this exception occurs the CLR crashes, and your logs never go that deep.

Lex Li
  • 60,503
  • 9
  • 116
  • 147
  • That's the point, the CLR does not crash. I would not have posted this question if we the matter was resolved simply by analyzing the dump. The code that is suspected to raise it is from http://fasterflect.codeplex.com/ - a fairly tested library, plus as I have already mentioned, the same path is exercised thousand times before conditions arise for the EEE. I am still not convinced that this exception cannot be generated at will in the lab. – mark Oct 30 '13 at 10:23
  • 1
    "does not crash" is inappropriate. When this exception occurs CLR cannot reliably recover itself. Process termination is not always the flag we chase. If you only consider termination as crash, then please kindly let me know and I am going to delete my useless answer above. The open source library you use in fact is very dangerous as it might hit regression issues of .NET Framework as it can manipulate IL directly. Since you want to reproduce it in the lab, I wish you good luck. – Lex Li Oct 30 '13 at 12:26