除访问违规异常之外的损坏状态异常类型

Question

除了AccessViolationException之外，还有哪些损坏的状态异常类型是可能的？

特别是，是否可以安全地假设OutOfMemoryException、ThreadAbortedException、SEHException、RuntimeWrappedException等都不需要使用HandleProcessCorruptedStateExceptionsAttribute来捕获，比如说，通过catch (Exception)条款？

我什至对 CLR 有时或总是将哪些异常类型视为 CSE 的示例、猜测、近似值感兴趣。 现有的网络资源看起来CSE几乎是AccessViolationException的同义词，但我怀疑即使对于我的适度需求来说，这可能也太不准确了。

每当我注意到外围负责的古代代码中出现catch (OutOfMemoryException)(或显式处理其他低级异常的另一个构造)时，我需要知道异常处理代码是否可能因迁移到 .NET 4 而无法访问或面临无法访问的风险。

到目前为止，我最好的选择是扫描异常类型的Microsoft文档以提及HandleProcessCorruptedStateExceptionsAttribute，但我想知道此行为细节是否应该在所有 .NET 4 版本中完全兼容，和/或针对受 CLR 更改影响的每种托管异常类型进行彻底记录。

Answer 1

我不确定是否有一组有限的例外(无论CLR版本如何，但总的来说)。

如果您查看此 CLR 函数，至少本机代码(或 CLR 本身)可以引发任何异常，将其指定为损坏状态。

// Signature simplified for purposes of that answer, check link above for actual signature.
void RealCOMPlusThrow(OBJECTREF throwable, CorruptionSeverity severity = NotCorrupting);

该函数(即包装它的宏COMPlusThrow)在(核心)CLR 中的多个位置调用。

函数IsProcessCorruptedStateException函数似乎最终用于确定异常是否被视为状态损坏。此函数有两个"重载"。

一个相当有用，因为它列出了以下异常代码：

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

至少在实质上，它们映射到 .NET 异常对象。

但是，另一个"简单地"检查异常对象(本机，非托管)是否已标记为状态损坏。

现在，我离成为CLR代码的专家还很远，所以YMMV。

人们肯定可以在 CLR 代码中花费数小时来弄清楚损坏的状态处理是如何工作的，以及这对处理 C# 代码中的状态会产生什么后果。 但是，根据您的问题真正想要实现的目标， 可能会导致一些严重的剃须。;-)