Why does concurrent GC sometimes cause ExecutionEngineException (per MSDN)?

According to MSDN, there is a "tip" stating that a .NET applicatio开发者_如何学编程n 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.

---

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.