views:

817

answers:

4

Summary:

I periodically get a .NET Fatal Execution Engine Error on an application which I cannot seem to debug. The dialog that comes up only offers to close the program or send information about the error to Microsoft. I've tried looking at the more detailed information but I don't know how to make use of it.

Error:

The error is visible in Event Viewer under Applications and is as follows:

.NET Runtime version 2.0.50727.3607 - Fatal Execution Engine Error (7A09795E) (80131506)

The computer running it is Windows XP Professional SP 3. (Intel Core2Quad Q6600 2.4GHz w/ 2.0 GB of RAM) Other .NET-based projects that lack multi-threaded downloading (see below) seem to run just fine.

Application:

The application is written in C#/.NET 3.5 using VS2008, and installed via a setup project.

The app is multi-threaded and downloads data from multiple web servers using System.Net.HttpWebRequest and its methods. I've determined that the .NET error has something to do with either threading or HttpWebRequest but I haven't been able to get any closer as this particular error seems impossible to debug.

I've tried handling errors on many levels, including the following in Program.cs:

// handle UI thread exceptions
Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException);

// handle non-UI thread exceptions
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);

// force all windows forms errors to go through our handler
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);

More Notes and What I've Tried...

  • Installed Visual Studio 2008 on the target machine and tried running in debug mode, but the error still occurs, with no hint as to where in source code it occurred.
  • When running the program from its installed version (Release) the error occurs more frequently, usually within minutes of launching the application. When running the program in debug mode inside of VS2008, it can run for hours or days before generating the error.
  • Reinstalled .NET 3.5 and made sure all updates are applied.
  • Broke random cubicle objects in frustration.
  • Rewritten parts of code that deal with threading and downloading in attempts to catch and log exceptions, though logging seemed to aggravate the problem (and never provided any data).

Question:

What steps can I take to troubleshoot or debug this kind of error? Memory dumps and the like seem to be the next step, but I'm not experienced at interpreting them. Perhaps there's something more I can do in the code to try and catch errors... It would be nice if the "Fatal Execution Engine Error" was more informative, but internet searches have only told me that it's a common error for a lot of .NET-related items.

A: 

try this http://blog-mstechnology.blogspot.com/2010/04/fatal-execution-engine-error-7a036050.html

mark
Slightly different error code (mine is 7A09795E not 7A036050), also apparently completely unrelated as mine deals with HttpWebRequest and this with Visual Studio itself. I'm not sure if it would make any difference, but I might resort to trying it.
JYelton
+6  A: 

Well, you've got a Big Problem. That exception is raised by the CLR when it detects that the garbage collected heap integrity is compromised. Heap corruption, the bane of any programmer that ever wrote code in an unmanaged language like C or C++.

Those languages make it very easy to corrupt the heap, all it takes is to write past the end of an array that's allocated on the heap. Or using memory after it has been released. Or having a bad value for a pointer. The kind of bugz that managed code was invented to solve.

But you are using managed code, judging from your question. Well, mostly, your code is managed. But you are executing lots of unmanaged code. All the low-level code that actually makes a HttpWebRequest work is unmanaged. And so is the CLR, it was written in C++ so is technically just as likely to corrupt the heap. But after over four thousand revisions of it, and millions of programs using it, the odds that it still suffers from heap cooties are very small.

The same isn't true for all the other unmanaged code that wants a piece of HttpWebRequest. The code you don't know about because you didn't write it and isn't documented by Microsoft. Your firewall. Your virus scanner. Your company's Internet usage monitor. Lord knows whose "download accelerator".

Isolate the problem, assume it is neither your code nor Microsoft's code that causes the problem. Assume it is environmental first and get rid of the crapware.

For an epic environmental FEEE story, read this thread.

Hans Passant
A great analysis of the "big picture" and provides insight to the *reasons* that this error may be occurring. Still, it would be nice to have some guidelines or methods as to how to replicate the error, work around it, or avoid it altogether.
JYelton
Sorry, there aren't any. The exception is raised long after the damage was done. Work from the assumption that the cause is environmental, change the environment.
Hans Passant
For example I am thinking of using a third-party library such as /n software's IPWorks, but I don't know if it uses the same unmanaged code blocks or effectively avoids it. (http://www.nsoftware.com/ipworks/v8/default.aspx)
JYelton
Given its age, it is highly likely to contain unmanaged code with a managed wrapper. I seriously doubt it solves the root cause of your problem. If you can get a reliable repro for the crash, you'd be better off spending money on Microsoft Support.
Hans Passant
+1  A: 

A presentation that might be a nice tutorial on where to start with this kind of issue is this: Hardcore production debugging in .NET by Ingo Rammer.

I do a bit a of C++/CLI coding, and heap corruption doesn't usually result in this error; usually heap corruption either causes a data corruption and a subsequent normal exception or a memory protection error - which probably doesn't mean anything.

In addition to trying .net 4.0 (which loads unmanaged code differently) you should compare x86 and x64 editions of the CLR - if possible - the x64 version has a larger address space and thus completely different malloc (+fragmentation) behavior and so you just might get lucky and have a different (more debuggable) error there (if it occurs at all).

Also, have you turned on unmanaged code debugging in the debugger (a project option), when you run with visual studio on? And do you have Managed Debug Assistants on?

Eamon Nerbonne
I haven't turned on unmanaged code debugging yet, that is something I will try thanks to your suggestion. Regarding Managed Debug Assistants, I have not known about them until now, so this is something I will immediately look into. At the moment there are some MDA's checked and others which are cleared (on thrown exceptions). I'll have to research which ones to enable and how to discern information from them.
JYelton
I wanted to award you the question bounty because you provided a number of good options to try. Thanks for jumping in.
JYelton
A: 

I'm wondering if the original poster was ever able to resolve this issue. I have a vested interest since my app is suffering from a very similar problem. It's also a multi-threaded app doing database and web service queries that occasionally throws the above exception (usually after running for a few hours). In my case, I've only so far been able to reproduce it on one machine - it seems to work fine on other machines. However, I've completely rebuilt the machine, reinstalled everything, run hardware diagnostics, etc., and the exception keeps happening. It's very frustrating, to say the least.

o. nate
Since changing the project to .NET 4, I am getting different, but somewhat more helpful errors (this time with stack traces). See http://stackoverflow.com/questions/3569816/unhandled-exception-while-downloading-web-page-using-httpwebrequest-and-streamrea for more info.
JYelton