I haven’t seen many “Fatal Execution Engine Error (79FFEE24)” sorts of messages lately – not since .NET 1.0/1.1 days.
But we were wrestling with an issue for multiple weeks in which a WCF service would
crash with exactly this error. Since this service uses the DataContractSerializer, this
post seemed quite relevant. The workarounds suggested there were not going
to be a fit for us, unfortunately.
The really insidious part of this problem was that the initial failure mode
was causing a third party library (that our service invoked) to fail…complete with
a stack trace that pointed deep into the third party code. However, when we removed the
call to this library, we got the “Fatal Execution Engine” exception while WCF was
attempting to serialize the service response. (Really nasty, and it points to
some sort of stack corruption perhaps.) You could see that WCF serialization
was at fault by analyzing a crash dump of the IIS worker process with WinDbg.
After talking with some folks at Microsoft support, they indicated that the DataContractSerializer
issue is fixed in .NET 4.0, but there is not a hotfix available for .NET 3.5sp1
at this time.
The workaround they proposed – and which has resolved our issue – was to place all
assemblies that contain types “T” used in contracts that have IEnumerable<T>
into the GAC. (In other words, if your contract has IEnumerable<T> elements,
then all types T have to be strong-named & in the GAC.)
Why does this work? The bug with DataContractSerializer apparently does not manifest
itself when assemblies are loaded as “domain neutral” (shared across all appdomains.)
You can force strong-named/GAC’d assemblies to be loaded as “domain neutral” by using
the LoaderOptimization attribute.
But if you’re hosting in IIS, you are automatically getting LoaderOptimization(LoaderOptimization.MultiDomainHost)
behavior for your application. If you’re not hosting in IIS, this bug doesn’t
seem to appear at all.
This workaround is a hassle, of course – it ripples across the application in many ways…but
it does resolve the issue.