a trace of thought on...BizTalk Server, Team Foundation Server, Windows Mobile, etc. RSS 2.0
 Tuesday, March 24, 2009
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.


Tuesday, March 24, 2009 1:36:07 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
WCF
Archive
<February 2010>
SunMonTueWedThuFriSat
31123456
78910111213
14151617181920
21222324252627
28123456
78910111213
About the author:

Scott Colestock lives, writes, and works as an independent consultant in the Twin Cities (Minneapolis, Minnesota) area.

© Copyright 2010
Scott Colestock
Sign In
All Content © 2010, Scott Colestock
DasBlog theme 'Business' created by Christoph De Baene (delarou)