CorruptedStateExceptions in .NET, a way to handle

It is already a well known fact that while running the MSIL , the CLR (runtime) can generate an Exception object automatically because of some unknown problem it faced while executing the code. These exceptions could be an User mode Exceptions which could have been rose by some bad application code or can also be a Structured Exception such as Divide by Zero, Invalid Cast exception etc.  Whatever the type of Exception be, you can write a Try/Catch block to handle the exception.  For instance :

try
{
int i=0; j = 10;
int k = j/i;
}
catch (Exception ex)
{
// Exception on DivideByZeroException caught
}

Here in the above code, you can see the line generates DivideByZeroException and which could easily be caught to a more generic type System.Exception rather than defining a catch for each individual types.

The Corrputed State Exceptions are unrecoverable exceptions that has corrupted the entire process. These exceptions are not generally caught by a System.Exception but treated as an Unhandled Exception even though the code that generates the exception is wrapped around a Try/Catch with generic Exception handler in place. The Corrupted State exception can be caused by some bug in CLR itself or in some native code for which managed developer does not have any control over.  The CLR will not let you to catch these type of exceptions by default.  Let us take an example :

try
{
IntPtr ptr = new IntPtr(1000);
Marshall.StructureToPtr(1000, ptr, true);
}
catch(Exception ex)
{
//Exception caught....
Console.WriteLine(ex.Message);
}

Now if you run the code above, even though the Marshall.StructureToPtr cannot process the pointer to the integer value 1000 and throws an AccessViolationException, the wrapped Catch block cannot process the exception but the process crashes itself.  The AccessViolationException is a special type of exception in addition to StackOverflowException, IllegalInstructionException etc. When the code encounters one of its type, the finally block if exists will not be executed as with CorruptedState the process will not execute a single line of code in managed environment.

The list of native Win32 exceptions which are considered as Corrupted State exceptiosn are :

EXCEPTION_ILLEGAL_INSTRUCTION EXCEPTION_IN_PAGE_ERROR
EXCEPTION_INVALID_DISPOSITION EXCEPTION_NONCONTINUABLE_EXCEPTION
EXCEPTION_ACCESS_VIOLATION EXCEPTION_STACK_OVERFLOW
EXCEPTION_PRIV_INSTRUCTION STATUS_UNWIND_CONSOLIDATE

Well, even though the CorruptedStateExceptions are not caught by the user code anywhere and kill the process immediately, there is a special attribute which indicates that the method can generate CorruptedStateExceptions and you can handle that as well.

[HandleProcessCorruptedStateExceptions]
[SecurityCritical]
public void MyMethod()
{
try
{
IntPtr ptr = new IntPtr(1000);
Marshall.StructureToPtr(1000, ptr, true);
}
catch(Exception ex)
{
//Exception caught....
Console.WriteLine(ex.Message);
}
}

When you annotate a method with HandleProcessCorruptedStateExceptions, the process will not terminate even though it produces a CorruptedStateException but rather it processes the Catch block and let you swiftly resolve the issue that you have created with the code. CLR recommends not to use this attribute, and even if it is used, the catch block will execute with an unknown state and people are requested to log the error and exit the program immediately when these kind of exception is encountered.

We can also use legacyCorruptedStateExceptionPolicy to indicate whether we need to enable this behavior or fall back to previous policy state.

<pre>&lt;configuration&gt;
    &lt;runtime&gt;
        &lt;legacyCorruptedStateExceptionsPolicy enabled="true"/&gt;
    &lt;/runtime&gt;
&lt;/configuration&gt;</pre>

This code will make the legacy .NET previous version code to use this feature as well.

I hope this post comes helpful.

Happy programming.