是否可以捕获 .NET 中的访问冲突异常？

Question

我可以采取什么措施来捕获 AccessViolationException 吗？它是由我无法控制的非托管 DLL 引发的。

Answer 1

正如其他人指出的那样，您不应该“处理”这种情况，但在开发过程中，为了排除故障可以很方便地捕获这种情况。

您可以使用 System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptions 属性标记托管方法：

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

Answer 2

是的。

在您的 App.confg 中，将以下代码放入 标记中：

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

现在您应该能够像捕获其他异常一样捕获损坏的状态异常 (CSE)。

注意：如果您已经有运行时标记，则只需向其添加

以上适用于 .Net 4.5

Answer 3

首先我完全确认 0xA3。但如果没有办法，你可以将脏的非托管 dll 包装在自己的进程中，并通过 IPC（TCP/IP、namedpipes 等）传输数据。捕获所有异常并通知主机进程。因此，您的主机进程基本上不会受到内存损坏的影响。

Answer 4

您可以使用 try-catch 块包装对非托管 DLL 的调用。 AccessViolationExceptions 可以正常捕获。执行以下代码会显示两条消息：

try
{
    throw new AccessViolationException();
}
catch (Exception e)
{
    MessageBox.Show(e.Message + e.StackTrace, e.Message, MessageBoxButtons.OK, MessageBoxIcons.Error);
}
MessageBox.Show("Still running..");

编辑： .NET 4 引入了 行为发生变化，除非您特别"询问" 运行时执行此操作。

Answer 5

你不应该。访问冲突是一个严重的问题：它是对无效内存地址进行写入（或读取）的意外尝试。正如 John 已经澄清的那样，在引发访问冲突之前，非托管 DLL 可能已经损坏了进程内存。这可能会对当前流程的任何部分产生不可预测的影响。

最安全的做法是通知用户，然后立即退出。

更多详细信息：访问冲突是操作系统异常（所谓的 SEH 或结构化异常处理异常）。这是与 System.Exception 中的托管 CLR 异常不同的异常类型。您很少会在纯托管代码中看到 SEH 异常，但如果发生，例如在非托管代码中，CLR 会将其传递到托管代码，您也可以在托管代码中捕获它¹。

然而，捕获 SEH 异常大多不是一个好主意。更多详细信息请参阅文章处理损坏的状态异常 在 MSDN 杂志中，以下文本摘自：

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

¹_{在 .NET 3.5 之前都是如此。在 .NET 4 中，行为已更改。如果您仍然希望能够捕获此类异常，则必须将 legacyCorruptedStateExceptionsPolicy=true 添加到 app.config。更多详细信息请参阅上面链接的文章。}