12

According to MSDN, there is a "tip" stating that a .NET application running under heavy load with concurrent garbage collection (either <gcConcurrent enabled="true"/> or unspecified, since it's the default behavior) may throw an ExecutionEngineException. Is anyone aware of a Microsoft KB article or other source that provides additional background on this?

We have experienced this directly with an NHibernate 3.2-based Windows Service application, which will invariably crash after at most a few hours of operation. We were able to track down the exception to the ISession.Flush() call.

There's a thread on nhusers reporting what appears to be the same problem. His suggested workaround, which was to disable concurrent GC, has worked for us so far, although switching to server-mode GC (<gcServer enable="true"/>), which implicitly disables concurrent GC, also did the trick.

Before submitting this to MS as a bug, I'd like to find out if anyone out there has additional information on the concurrent GC instablity that the tip mentions.

Nick Jones
  • 4,395
  • 6
  • 33
  • 44
  • 2
    Given the fact that it is documented, your bug is likely to be closed as "By Design". That aside, interesting question. – vcsjones Sep 23 '11 at 16:11
  • 2
    @Nick Jones: The .NET 4.0 documentation also lists it as obsolete and states that the runtime no longer throws this exception. – casperOne Sep 23 '11 at 16:21
  • @casperOne: noted, but NH 3.2 is compiled against .NET 3.5. – Nick Jones Sep 23 '11 at 16:26
  • @Nick: You could recompile NHibernate for .NET 4.0. See http://stackoverflow.com/questions/1631617/did-somebody-tried-to-recompile-nhibernate-for-net-4-0-beta-2 – TrueWill Sep 23 '11 at 17:56

1 Answers1

5

I suspect this occurs when the application is under heavy load because when concurrent GC is enabled, the GC tries to do it's work without pausing your application. If the GC encounters a situation where it tries to move memory around during the compaction phase of a GC cycle and isn't able to move the memory or isn't able to correctly update the application pointers, that could cause the runtime to throw this exception since it would end up putting your application into a potentially invalid state.

As @casperOne pointed out in his comment, this exception is marked as obsolete in .NET 4.0 although that doesn't necessarily mean the GC still can't get itself into the same state that caused it to throw the exception in .NET 3.5. If the GC did get itself into that same state, the runtime will issue a FailFast command and terminate rather than throwing an exception.

Scott Dorman
  • 42,236
  • 12
  • 79
  • 110
  • 1
    Note that, while the "API" is marked obsolete, the bug indeed happens in **.NET 4.0** (e.g. this SO thread: [Application Crashes With "Internal Error In The .NET Runtime"](http://stackoverflow.com/q/4367664/69809)). The [MSDN KB entry](http://support.microsoft.com/kb/2679415) describes it as a x64 .NET 4 issue, but I wouldn't bet it's limited to x64. We had the same problem, and it also had NHibernate involved, and switching off concurrent GC fixed it. It sucks to come to work in the morning and see our main server app brought down by an internal .NET exception. :) – vgru Oct 19 '14 at 19:58