finally 块没有在 .NET 4.0 上运行，为什么？

Question

好吧，这是一个奇怪的问题，我希望有人能提供一些线索。我有以下代码：

static void Main(string[] args)
{
    try
    {
        Console.WriteLine("in try");
        throw new EncoderFallbackException();
    }
    catch (Exception)
    {
        Console.WriteLine("in Catch");
        throw new AbandonedMutexException();
    }
    finally
    {
        Console.WriteLine("in Finally");
        Console.ReadLine();
    }
}

现在，当我将其编译到目标 3.5 (2.0 CLR) 时，它将弹出一个窗口，显示“XXX 已停止工作”。如果我现在单击取消按钮，它将运行最后，如果我等到它完成查找并单击关闭程序按钮它也会运行finally。

现在有趣且令人困惑的是，如果我对 4.0 进行同样的编译，单击“取消”按钮将运行“最后”块，然后单击“关闭程序” 按钮不会。

我的问题是：为什么点击关闭程序按钮时finally在2.0上运行而不是在4.0上运行？这会造成什么后果？

编辑：我在 Windows 7 32 位上的发布模式（内置发布模式）下从命令提示符运行此命令。错误消息：下面的第一个结果是在 Windows 查找问题后在 3.5 上运行，点击关闭，第二个结果是当我在 4.0 上运行它并执行相同的操作时。

Answer 1

我现在能够重现该行为（当我第一次阅读您的问题时，我没有从您的问题中得到确切的步骤）。

我观察到的一个区别在于 .NET 运行时处理未处理异常的方式。 CLR 2.0 运行一个名为 Microsoft .NET Error Reporting Shim (dw20.exe) 的帮助程序，而 CLR 4.0 则启动 Windows 错误报告 (dw20.exe) >WerFault.exe）。

我认为两者在终止崩溃进程方面有不同的行为。 WerFault.exe 显然会立即终止 .NET 进程，而 .NET 错误报告 Shim 会以某种方式关闭应用程序，以便finally 块仍然被执行。

另请查看事件查看器：WerFault 记录了一个应用程序错误，通知崩溃的进程已终止：

Application: ConsoleApplication1.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Threading.AbandonedMutexException
Stack:
   at Program.Main(System.String[])

dw20.exe 但是仅将事件 ID 为 1001 的信息项记录到事件日志中，而不会终止该进程。

Answer 2

想想那种情况是多么糟糕：发生了一些意想不到的事情，却没有人编写代码来处理。在这种情况下，运行更多代码是否正确，这些代码可能也不是为处理这种情况而构建的？可能不是。通常，正确的做法是不尝试运行finally 块，因为这样做会使情况变得更糟。你已经知道进程正在下降；立即让它脱离痛苦。

在未处理的异常将导致进程崩溃的情况下，任何事情都可能发生。在这种情况下会发生什么是实现定义的：是否将错误报告给 Windows 错误报告、调试器是否启动等等。 CLR 完全有权利尝试运行finally 块，也完全有权利快速失败。在这种情况下，所有的赌注都将落空。不同的实现可以选择做不同的事情。

Answer 3

我关于这个主题的所有知识都来自这篇文章：CLR 全面深入 - CLR 中未处理的异常处理。请注意，它是为 .NET 2.0 编写的，但我有一种感觉，它对于我们在本例中所经历的情况是有意义的（无论如何，不​​仅仅是“因为它决定这样做”）。

快速回答“我没有时间读那篇文章”（尽管你应该这样做，这是一篇非常好的文章）：

问题的解决方案（如果你绝对必须运行finally块）将是a）放入全局错误处理程序或 b) 强制 .NET 始终运行 finally 块并按照 .NET 1.1 中的方式（可以说是错误的方式）执行操作 - 将以下内容放入您的 app.config 中：

<legacyUnhandledExceptionPolicy enabled="1">

这样做的原因：
当 .NET 中抛出异常时，它开始回溯堆栈寻找异常处理程序，当找到异常处理程序时，它会在运行内容之前运行finally块第二次回溯堆栈。抓住。如果它没有找到catch，那么第二次遍历永远不会发生，因此finally块永远不会在这里运行，这就是为什么全局异常处理程序将始终运行finally子句，因为CLR将在找到catch时运行它们，而不是在运行它时运行它们（我相信这意味着即使你执行 catch/ throw 你的finally 块仍然会运行）。

app.config 修复起作用的原因是，对于 .NET 1.0 和 1.1，CLR 中有一个全局捕获，它会在异常变为非托管之前吞掉异常，这当然会触发 finally 块运行。当然，框架无法充分了解所述异常来处理它，例如堆栈溢出，因此这可能是错误的方法。

接下来是有点棘手的地方，我根据本文所说的内容做出假设。

如果您使用的是 .NET 2.0+，而没有启用旧版异常处理，那么您的异常将落入 Windows 异常处理系统 (SEH)，这看起来与 CLR 非常相似，因为它会遍历帧，直到无法处理为止。找到一个 catch，然后调用一系列称为未处理异常过滤器 (UEF) 的事件。这是一个您可以订阅的事件，但一次只能订阅一个事件，因此当有事件订阅时，Windows 会将之前存在的回调地址传递给它，从而允许您设置 UEF 链处理程序 - 但他们不必尊重该地址，他们应该自己调用该地址，但如果有人破坏了链条，咩，你就不会再得到错误处理。我假设这就是当您取消 Windows 错误报告时发生的情况，它破坏了 UEF 链，这意味着应用程序将立即关闭并且finally块不会运行，但是如果您让它运行到最后并关闭它，它将调用链中的下一个 UEF。 .NET 将注册一个 AppDomain.UnhandledException 被调用的地方（因此即使这个事件也不能保证），我认为这也是你调用finally块的地方 - 正如我所能的那样'如果您从不转换回 CLR，托管的finally 块将如何运行（本文不讨论这一点。）

Answer 4

我相信这与调试器连接方式的更改有关。

来自。 NET Framework 4 迁移问题文档：

当调试器无法启动或没有应启动的已注册调试器时，您将不再收到通知。

发生的情况是您选择启动调试器，但您取消了它。我相信这属于这一类别，并且应用程序因此而停止。

Answer 5

在发布和调试中运行这个，在框架 3.5 和 4.0 中，我在所有实例中都看到“最后”，是的，从命令行运行它，甚至关闭了我的 vs 会话，也许它是你的机器上的东西或作为 Kobi指出，可能与平台相关（我使用的是 Win7 x64）