C# – .NET Runtime Error causes process to crash! But there’s no unhandled exception – Why? CLR bug

As you are not getting any useful information at the time of the crash, an alternative approach is to attach a debugger to the crashing EXE. There are two ways I suggest:

Using Visual Studio

If you have Visual Studio installed on the same PC/server as the crashing app, attach Visual Studio to the EXE whilst it's running. Here's an intro on how to do this:

http://msdn.microsoft.com/en-us/library/c6wf8e4z.aspx

Using WinDbg

This is a very low-level, and powerful, debugger for Windows. This could certainly help you with your problem. However, there is a steep learning curve in how to get started in using it. The .NET framework comes with a DLL named SOS.DLL (found in the C:\Windows\...... system folder) which contains many commands that you can use in WinDbg to analyse a .NET application. These include listing thread stack and displaying exception information.

A very good source of information on how to debug .NET issues with WinDbg is

http://blogs.msdn.com/b/tess/

There are many great examples of how to debug issues, such as

http://blogs.msdn.com/b/tess/archive/2008/02/11/net-debugging-demos-lab-2-crash-review.aspx

You can download WinDbg from:

• 32bit version http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx#E3
• 64bit version http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx-

I would highly recommend the Visual Studio approach, due to its simplicity. However, by far the most powerful way to debug your app is to use WinDbg, but it can be intimidating for first time users.

EDIT: Here's another link that might be of use:

http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/ebd10d1f-902b-4a95-ba42-e87c4f817097

with exit code 80131506

That's a nasty one, ExecutionEngineException. Starting with .NET 4.0, this exception immediately terminates the program. The generic cause is corruption of the state of the garbage collected heap. Which in turn is invariably caused by unmanaged code. The exact location in code at which this exception is raised isn't helpful, the corruption usually occurred well before the damage is detected.

Finding the exact cause for this is going to be difficult. Review any unmanaged code your service might be using. Suspect environmental problems if there is no obvious candidate, misbehaving malware scanners are notorious. If it repeats very poorly then suspect hardware problems like soft RAM errors.