Environment.Exit（）がプログラムを終了しないのはなぜですか？

これはほんの数日前に発見したもので、この質問から私のマシンに限定されないことが確認されました。

これを再現する最も簡単な方法は、Windowsフォームアプリケーションを起動し、ボタンを追加して、次のコードを記述することです。

    private void button1_Click(object sender, EventArgs e) {
        MessageBox.Show("yada");
        Environment.Exit(1);         // Kaboom!
    }

Exit（）ステートメントの実行後、プログラムは失敗します。Windowsフォームでは、「ウィンドウハンドルの作成エラー」が発生します。

アンマネージデバッグを有効にすると、何が起こっているのかがいくぶん明確になります。COMモーダルループを実行し、WM_PAINTメッセージが配信されることを可能にします。それは処分されたフォームでは致命的です。

これまでに収集した唯一の事実は次のとおりです。

• デバッガでの実行に限定されません。これも1つもなければ失敗します。どちらかと言えば、WERクラッシュダイアログが2回表示されます。
• プロセスのビットネスとは何の関係もありません。wow64レイヤーはかなり悪名高いですが、AnyCPUビルドは同じ方法でクラッシュします。
• .NETバージョンとは何の関係もありません。4.5と3.5は同じようにクラッシュします。
• 終了コードは関係ありません。
• Exit（）を呼び出す前にThread.Sleep（）を呼び出しても修正されません。
• これは64ビットバージョンのWindows 8で発生し、Windows 7は同じ影響を受けないようです。
• これは比較的新しい振る舞いであるはずですが、私はこれを見たことはありません。私のマシンでは更新履歴が正確ではなくなっていますが、Windows Updateを通じて関連する更新が配信されていません。
• これはひどく破壊的な動作です。このようなコードをAppDomain.UnhandledExceptionのイベントハンドラーに記述すると、同じようにクラッシュします。

このクラッシュを回避するためにできることには特に興味があります。特に、AppDomain.UnhandledExceptionシナリオは私を困らせます。.NETプログラムを終了する方法は多くありません。Application.Exit（）またはForm.Close（）の呼び出しはUnhandledExceptionのイベントハンドラーでは無効であるため、回避策ではないことに注意してください。

更新：Mehrdadは、ファイナライザスレッドが問題の一部である可能性があることを指摘しました。私はこれを見ていると思いますし、CLRがファイナライザスレッドに実行を終了させるための2秒のタイムアウトの証拠もいくつか見ています。

ファイナライザはNativeWindow.ForceExitMessageLoop（）内にあります。32ビットモードでマシンコードを見ると、コードの場所にほぼ対応するIsWindow（）Win32関数があります。オフセットは0x3cです。IsWindow（）がデッドロックしているようです。内部の適切なスタックトレースを取得できませんが、デバッガーはP / Invoke呼び出しが返されたと判断します。これは説明するのが難しいです。より良いスタックトレースを取得できる場合は、ぜひご覧ください。私の：

System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.ForceExitMessageLoop() + 0x3c bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Finalize() + 0x16 bytes
[Native to Managed Transition]
kernel32.dll!@BaseThreadInitThunk@12()  + 0xe bytes
ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes
ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

ForceExitMessageLoop呼び出しを超えるものはなく、アンマネージデバッガーが有効になっています。

この問題についてマイクロソフトに問い合わせたところ、効果があったようです。少なくとも私はそれがそうだったと思いたいです:)。彼らから解決策の確認は得られませんでしたが、Windowsグループに直接連絡することは難しく、仲介者を使用する必要がありました。

Windows Updateを通じて配信されたアップデートで問題が解決しました。クラッシュが発生するまでの2秒の顕著な遅延は、IsWindow（）デッドロックが解決されたことを強く示唆しています。そして、プログラムはクリーンかつ確実にシャットダウンします。Windows Defender、wdboot.sys、wdfilter.sys、tcpip.sys、rpcrt4.dll、uxtheme.dll、crypt32.dllおよびwintrust.dll用の更新プログラムがインストールされたパッチ

Uxtheme.dllは奇妙なものです。Visual StylesテーマAPIを実装し、このテストプログラムで使用されます。確かではありませんが、私のお金は問題の原因としてそのお金にあります。C：\ WINDOWS \ system32のコピーのバージョン番号は6.2.9200.16660で、2013年8月14日に私のマシンに作成されました。

ケースは閉じられました。

「これ以上」機能しない理由はわかりませんが、Environment.Exit保留中のファイナライザを実行すると思います。Environment.FailFastしません。

（何らかの奇妙な理由により）後で実行する必要のある保留中のファイナライザが奇妙になり、これが発生する可能性があります。

これはなぜ起こっているのかを説明していませんがEnvironment.Exit、サンプルのようなボタンイベントハンドラーを呼び出すことはしません。代わりに、ルネの回答で提案されているようにメインフォームを閉じます。

AppDomain.UnhandledExceptionハンドラについてEnvironment.ExitCodeは、を呼び出すのではなく、単に設定することもできますEnvironment.Exit。

ここで何を達成しようとしているのかわかりません。Windowsフォームアプリケーションから終了コードを返す必要があるのはなぜですか？通常、終了コードはコンソールアプリケーションで使用されます。

このクラッシュを回避するためにできることには特に興味があります。WERダイアログが表示されないようにするには、Encalling Environment.Exit（）が必要です。

Mainメソッドにtry / catchがありますか？Windowsフォームアプリケーションの場合、メッセージループと未処理の例外ハンドラーを常にtry / catchします。

私たちのアプリでも同じ問題が見つかりました。次の構文で解決しました：

Environment.ExitCode=1;
Application.Exit();