是否有可能在.NET中捕获访问冲突异常？

Question

我有什么可以做的AccessViolationException吗？它是由我无法控制的非托管DLL引发的.

Answer 1

你不应该.访问冲突是一个严重的问题:它是一种意外尝试写入(或读取)无效的内存地址.正如John已经阐明的那样,在提出访问冲突之前,非托管DLL可能已经损坏了进程内存.这可能会对当前进程的任何部分产生不可预测的影响.

最安全的做法是可能通知用户,然后立即退出.

更多细节:访问冲突是操作系统异常(所谓的SEH或结构化异常处理异常).这是一种与托管CLR异常不同的异常System.Exception.您很少会在纯托管代码中看到SEH异常,但如果发生异常,例如在非托管代码中,CLR会将其提供给托管代码,您也可以在托管代码中捕获它¹.

但是,捕获SEH异常通常不是一个好主意.有关详细信息,请参阅MSDN杂志中的处理损坏的状态例外一文,其中包含以下文本:

CLR始终使用与程序本身引发的异常相同的机制向托管代码提供SEH异常.只要代码不尝试处理无法合理处理的异常条件,这就不是问题.在访问冲突后,大多数程序无法安全地继续执行.不幸的是,CLR的异常处理模型总是鼓励用户通过允许程序捕获System.Exception层次结构顶部的任何异常来捕获这些严重错误.但这很少是正确的做法.

¹ _{直到.NET 3.5才这样.在.NET 4中,行为已被更改.如果您仍希望能够捕获此类异常,则必须添加legacyCorruptedState­­ExceptionsPolicy=true到app.config.以上联系方式的进一步细节.}

Answer 2

是.

在App.confg中,在<configuration>标记中添加以下代码:

<runtime>
    <legacyCorruptedStateExceptionsPolicy enabled="true"/>
</runtime>

现在,您应该能够像其他任何事件一样捕获损坏的状态异常(CSE).

注意:如果您已有运行时标记,则只需添加<legacyCorruptedStateExceptionsPolicy enabled="true"/>它即可

以上适用于.Net 4.5

Answer 3

As others pointed out, you shouldn't "handle" this condition, but during development it is handy to catch this for the sake of troubleshooting.

You can mark your managed method with the System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptions attribute:

[HandleProcessCorruptedStateExceptions]
public void MyMethod()
{
    try
    {
        NaughtyCall();
    }
    catch (AccessViolationException e)
    {
        // You should really terminate your application here
    }
}