What Corrupted State Exception types, other than AccessViolationException are possible?
In particular, is it safe to assume that none of OutOfMemoryException, ThreadAbortedException, SEHException, RuntimeWrappedException, etc. require the use of HandleProcessCorruptedStateExceptionsAttribute to be caught, say, by a catch (Exception) clause?
I'm interested even in examples, guesses, approximations, of what exception types are sometimes or always treated by the CLR as a CSE. Existing web resources give the appearance that CSE is a near-synonym for AccessViolationException, but I suspect that this might be too inaccurate even for my modest needs.
I need to know, whenever I notice a catch (OutOfMemoryException) (or another construct explicitly dealing with other low level exceptions) in ancient code I'm peripherally responsible for, whether the exception handling code could have been made unreachable, or is at risk of becoming unreachable, by migration to .NET 4.
So far my best bet was to scan Microsoft documentation of the exception type for a mention of HandleProcessCorruptedStateExceptionsAttribute, but I wonder whether this detail of behavior is even supposed to be fully compatible across all .NET 4 versions, and/or thoroughly documented for every managed exception type affected by the CLR change.
I'm not sure if there even is a finite set of exceptions (regardless of CLR versions, but in general).
At least native code (or the CLR itself) could raise any exception, designating it as corrupting state, if you look at this CLR function.
// Signature simplified for purposes of that answer, check link above for actual signature.
void RealCOMPlusThrow(OBJECTREF throwable, CorruptionSeverity severity = NotCorrupting);
That function (i.e. the macro COMPlusThrow that wraps it) is called in multiple places in the (Core) CLR.
The function IsProcessCorruptedStateException function seems to be ultimately used to determine if an exception is considered state corrupting. This function has two "overloads".
One is rather helpful, because it lists the following exception codes:
STATUS_ACCESS_VIOLATION
STATUS_STACK_OVERFLOW
EXCEPTION_ILLEGAL_INSTRUCTION
EXCEPTION_IN_PAGE_ERROR
EXCEPTION_INVALID_DISPOSITION
EXCEPTION_NONCONTINUABLE_EXCEPTION
EXCEPTION_PRIV_INSTRUCTION
STATUS_UNWIND_CONSOLIDATE
At least paritially they map to .NET exception objects.
However, the other one "simply" checks if the exception object (native, not managed) has been marked was state corrupting.
Now, I'm far far far away from being an expert with the CLR's code, so YMMV.
One can surely spend hours in the CLR code to figure out how corrupted state handling works and what consequences that has for handling those in C# code. But depending on what you are really trying to achieve by your question that might lead to some serious yack shaving. ;-)