問題描述

在 winforms 應(yīng)用中，在表單的 Load 事件中，添加以下行:

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

throw new Exception();

并運行應(yīng)用程序.它運行沒有問題.這稱為靜默失敗，您可以嘗試在前后添加消息框，您很快就會發(fā)現(xiàn) throw 語句并沒有讓應(yīng)用程序崩潰，而是從 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.

我仍然想知道這種可怕行為背后的(可能是歷史)原因.我確信這不是設(shè)計決定，可能是沒有選擇，或者是懶惰.有人知道嗎?

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?

如果有人能指出可能導(dǎo)致 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);
        }

    }
}

編輯似乎它并沒有發(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 系統(tǒng)上的已知問題:

這是 64 位操作系統(tǒng)上的已知問題平臺.原因是64位操作系統(tǒng)內(nèi)核不允許用戶模式通過內(nèi)核模式堆棧的異常.異常被操作系統(tǒng)吞噬悄悄地.這發(fā)生在 FormLoad處理程序，因為它是在操作系統(tǒng)中調(diào)用的打回來.32位操作系統(tǒng)不這樣做，所以它不會在那里重現(xiàn).

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.

操作系統(tǒng)團(tuán)隊正在調(diào)查相關(guān)的問題.與此同時，你確實有解決這個問題.開啟停止第一次機會例外"將使調(diào)試器在此停止設(shè)想.但它確實使調(diào)試器經(jīng)常停止，所以你可能只想在您這樣做時發(fā)現(xiàn)問題.

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 月，并沒有說明從那以后發(fā)生了什么.

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

我可以在這里重現(xiàn)大多數(shù)海報在我的 32 位系統(tǒng)上的行為，并且我可以在我的 64 位(Vista SP2、3.5SP1 框架)工作 PC 上重現(xiàn) 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.

這篇關(guān)于C# 中的靜默失敗，看似未處理的異常，不會使程序崩潰的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網(wǎng)！