问题描述

在 winforms 应用中，在表单的 Load 事件中，添加以下行:

In a winforms app, in a form's Load event, add the following line:

throw new Exception();

并运行应用程序.它运行没有问题.这称为静默失败，您可以尝试在前后添加消息框，您很快就会发现 throw 语句并没有让应用程序崩溃，而是从 Load 事件中退出.

and run the application. It ran without a problem. This is called a silent failure, you can try to add messageboxes before and after, and you'll soon find out that instead of crashing the application, the throw statement just exits from the Load event.

我确信没有必要解释这是多么丑陋和危险.

I'm sure there is no need to explain how ugly and dangerous this is.

我仍然想知道这种可怕行为背后的(可能是历史)原因.我确信这不是设计决定，可能是没有选择，或者是懒惰.有人知道吗?

I was wondering nonetheless in the (probably history) reasons behind this terrifying behavior. I'm sure it's not a design decision, probably no-choice, or laziness. Does anybody know?

如果有人能指出可能导致 seileent 失败的事件列表，我会很高兴.

Would be glad if anyone can point me to a list of events which may cause seilent failures too.

这是我的代码片段 - 我不知道它有什么帮助 - 但是，这里是:

Here's a snippet of my code - I have no idea how it might help - but, here it is:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;

namespace WindowsFormsApplication1
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Form f = new Form();
            f.Load += new EventHandler((x, y) => { throw new Exception(); });
            Application.Run(f);
        }

    }
}

编辑似乎它并没有发生在每个人身上.我用的是:fw 3.5, winforms, vs 2008, vista x64, new clean project of winforms，上面的代码.

EDIT It seems it does not happend to everyone. I use: fw 3.5, winforms, vs 2008, vista x64, new clean project of winforms, with the code mentioned above.

推荐答案

这是一个 x64 系统上的已知问题:

这是 64 位操作系统上的已知问题平台.原因是64位操作系统内核不允许用户模式通过内核模式堆栈的异常.异常被操作系统吞噬悄悄地.这发生在 FormLoad处理程序，因为它是在操作系统中调用的打回来.32位操作系统不这样做，所以它不会在那里重现.

This is a known issue on 64-bit OS platform. The reason is that the 64bit OS core does not allow user mode exception through kernal mode stacks. The exception is swallowed by OS sliently. That happens in FormLoad handler, because it is called in an OS callback. 32bits OS doesn't do this, so it doesn't repro there.

操作系统团队正在调查相关的问题.与此同时，你确实有解决这个问题.开启停止第一次机会例外"将使调试器在此停止设想.但它确实使调试器经常停止，所以你可能只想在您这样做时发现问题.

The OS team is investigating related issues. In the mean time, you do have to work around this issue. Turning on "Stop on first chance exception" will make the debugger to stop in this scenario. But it does make the debugger to stop very often, so you might want to do this only when you find a problem.

链接的错误报告最后一次更新是 2008 年 2 月，并没有说明从那以后发生了什么.

The linked bug report was last updated February 2008, and doesn't indicate what's happened since then.

我可以在这里重现大多数海报在我的 32 位系统上的行为，并且我可以在我的 64 位(Vista SP2、3.5SP1 框架)工作 PC 上重现 OP 的行为.

I can reproduce most poster's behavior on my 32-bit system here, and I can reproduce the OP's behavior on my 64-bit (Vista SP2, 3.5SP1 Framework) work PC.

这篇关于C# 中的静默失败，看似未处理的异常，不会使程序崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！