共通言語ランタイムを使用すると、スレッド内のほとんどのハンドルされない例外を自然に続行できます。 ほとんどの場合、これは、ハンドルされない例外によってアプリケーションが終了することを意味します。 ただし、共通言語ランタイムは、プログラム フローの制御に使用される特定のハンドルされない例外のバックストップを提供します。
ThreadAbortException が呼び出されたため、スレッドで Abort がスローされる。 これは.NET Framework アプリにのみ適用されます。
スレッドが実行中のアプリケーション ドメインがアンロードされると、スレッドで AppDomainUnloadedException がスローされる。
共通言語ランタイムまたはホスト プロセスが内部例外をスローし、それによってスレッドを終了します。
共通言語ランタイムによって作成されたスレッドでこれらの例外のいずれかが処理されない場合、例外はスレッドを終了しますが、共通言語ランタイムでは例外を続行できません。
これらの例外がメイン スレッド、またはアンマネージ コードからランタイムに入ったスレッドで処理されない場合は、通常どおりに続行され、アプリケーションが終了します。
注
マネージド コードで例外ハンドラーをインストールする機会が発生する前に、ランタイムが未処理の例外をスローする可能性があります。 マネージド コードではこのような例外を処理する機会がありませんでしたが、例外は自然に続行できます。
開発時におけるスレッド処理の問題の露呈
スレッドがサイレントモードで失敗することが許可されている場合、アプリケーションを終了せずに、重大なプログラミングの問題が検出されない可能性があります。 これは、長期間実行されるサービスやその他のアプリケーションに関する特定の問題です。 スレッドが失敗すると、プログラムの状態が徐々に破損します。 アプリケーションのパフォーマンスが低下したり、アプリケーションが応答しなくなる可能性があります。
スレッド内のハンドルされない例外を、オペレーティング システムがプログラムを終了するまで自然に続行できるようにすることで、開発とテスト中にこのような問題が発生します。 プログラムの終了に関するエラー レポートでは、デバッグがサポートされます。
ホストのオーバーライド
アンマネージ ホストは、ホスティング API の ICLRPolicyManager インターフェイスを使用して、共通言語ランタイムの既定のハンドルされない例外ポリシーをオーバーライドできます。 ICLRPolicyManager::SetUnhandledExceptionPolicy 関数は、ハンドルされない例外のポリシーを設定するために使用されます。
こちらも参照ください
.NET