Gracefully handling corrupted state exceptions

Question

Related to this question, I would like to force CLR to let my .NET 4.5.2 app catch Corrupted State Exceptions, for the sole purpose of logging them and then terminating the application. What's the correct way to do this, if I have catch (Exception ex) at several places around the app?

So, after I specify the <legacyCorruptedStateExceptionsPolicy> attribute, if I understood correctly, all the catch (Exception ex) handlers will catch exceptions like AccessViolationException and happily continue.

Yeah, I know catch (Exception ex) is a Bad Idea™, but if CLR would at least put the correct stack trace into the Event Log, I would be more than happy to explain to the customer that his server app failing fast at 1AM and being offline for the night is a good thing. But unfortunately, CLR logs an unrelated exception into the Event Log and then closes the process so that I cannot find out what actually happened.

The question is, how to make this happen, process wide:

if the exception thrown is a Corrupted State Exception:     - write the message to the log file     - end the process  

(Update)

In other words, this would probably work for most exceptions in a simple app:

[HandleProcessCorruptedStateExceptions]  [SecurityCritical] static void Main() // main entry point {     try      {      }     catch (Exception ex)     {         // this will catch CSEs     } } 

But, it won't work for:

• Unhandled app domain exceptions (i.e. thrown on non-foreground threads)
• Windows Service apps (which don't have an actual Main entry point)

So it seems like <legacyCorruptedStateExceptionsPolicy> is the only way to make this work, in which case I don't know how to fail after logging the CSE?

Answer 1

Instead of using <legacyCorruptedStateExceptionsPolicy> it would be better to use [HandleProcessCorruptedStateExceptions] (and [SecurityCritical]) as stated here:

https://msdn.microsoft.com/en-us/magazine/dd419661.aspx

Following that, your Main method should look something like this:

[HandleProcessCorruptedStateExceptions, SecurityCritical] static void Main(string[] args) {     try     {         ...     }     catch (Exception ex)     {         // Log the CSE.     } } 

But be aware that this doesn't catch the more serious exceptions like StackOverflowException and ExecutionEngineException.

Also finally of involved try blocks will not be executed:

https://csharp.2000things.com/2013/08/30/920-a-finally-block-is-not-executed-when-a-corrupted-state-exception-occurs/

For other unhandled appdomain exceptions you can use :

• AppDomain.CurrentDomain.UnhandledException
• Application.Current.DispatcherUnhandledException
• TaskScheduler.UnobservedTaskException

(Please do a search for the details when a specific handler is appropriate for your situation. TaskScheduler.UnobservedTaskException for example is a bit tricky.)

If you don't have access to the Main method, you can also mark your AppDomain exception handler to catch the CSE:

AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;  ...  [HandleProcessCorruptedStateExceptions, SecurityCritical] private static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e) {     // AccessViolationExceptions will get caught here but you cannot stop     // the termination of the process if e.IsTerminating is true. } 

The last line of defense could be an unmanaged UnhandledExceptionFilter like this:

[DllImport("kernel32"), SuppressUnmanagedCodeSecurity] private static extern int SetUnhandledExceptionFilter(Callback cb); // This has to be an own non generic delegate because generic delegates cannot be marshalled to unmanaged code. private delegate uint Callback(IntPtr ptrToExceptionInfo); 

And then somewhere at the beginning of your process:

SetUnhandledExceptionFilter(ptrToExceptionInfo => {     var errorCode = "0x" + Marshal.GetExceptionCode().ToString("x2");     ...     return 1; }); 

You can find more information about the possible return codes here:

https://msdn.microsoft.com/en-us/library/ms680634(VS.85).aspx

A "specialty" of the UnhandledExceptionFilter is that it isn't called if a debugger is attached. (At least not in my case of having a WPF app.) So be aware of that.

If you set all the appropriate ExceptionHandlers from above, you should be logging all exceptions that can be logged. For the more serious exceptions (like StackOverflowException and ExecutionEngineException) you have to find another way because the whole process is unusable after they happened. A possible way could perhaps be another process that watches the main process and logs any fatal errors.

Additional hints:

• In the AppDomain.CurrentDomain.UnhandledException you can safely cast the e.ExceptionObject to Exception without having to worry - at least if you don't have any IL code that throws other objects than Exception: Why is UnhandledExceptionEventArgs.ExceptionObject an object and not an Exception?
• If you want to suppress the Windows Error Reporting dialog, you can take a look here: How to terminate a program when it crashes? (which should just fail a unit test instead of getting stuck forever)
• If you have a WPF application with multiple dispatchers you can also use a Dispatcher.UnhandledException for the other dispatchers.