.NET 例外が try/catch ブロックでキャッチされないのはなぜですか?

https://stackoverflow.com/questions/36014

09-06-2019
|

質問

を使用してプロジェクトに取り組んでいますアントラー C# 用のパーサーライブラリ。テキストを解析するための文法を構築しましたが、うまく機能します。ただし、パーサーは不正なトークンまたは予期しないトークンを検出すると、多くの例外のうちの 1 つをスローします。問題は、場合によっては (すべてではありません)、try/catch ブロックがそれをキャッチせず、ハンドルされない例外として実行を停止することです。

私にとっての問題は、この問題を完全なコード以外の場所で再現できないことです。コールスタックは、例外が try/catch(Exception) ブロック内で確実に発生していることを示しています。唯一考えられるのは、私のコードと例外をスローするコードとの間でいくつかの ANTLR アセンブリ呼び出しが発生しており、このライブラリではデバッグが有効になっていないため、ステップ実行できないということです。デバッグ不可能なアセンブリは例外のバブリングを抑制するのでしょうか?コールスタックは次のようになります。外部アセンブリ呼び出しは Antlr.Runtime にあります。

    Expl.Itinerary.dll!TimeDefLexer.mTokens() Line 1213 C#
    Antlr3.Runtime.dll!Antlr.Runtime.Lexer.NextToken() + 0xfc bytes 
    Antlr3.Runtime.dll!Antlr.Runtime.CommonTokenStream.FillBuffer() + 0x22c bytes   
    Antlr3.Runtime.dll!Antlr.Runtime.CommonTokenStream.LT(int k = 1) + 0x68 bytes
    Expl.Itinerary.dll!TimeDefParser.prog() Line 109 + 0x17 bytes   C#
    Expl.Itinerary.dll!Expl.Itinerary.TDLParser.Parse(string Text = "", Expl.Itinerary.IItinerary Itinerary = {Expl.Itinerary.MemoryItinerary}) Line 17 + 0xa bytes C#

Parse() の一番下の呼び出しのコードスニペットは次のようになります。

     try {
        // Execution stopped at parser.prog()
        TimeDefParser.prog_return prog_ret = parser.prog();
        return prog_ret == null ? null : prog_ret.value;
     }
     catch (Exception ex) {
        throw new ParserException(ex.Message, ex);
     }

私にとって、catch (Exception) 句はあらゆる例外を捕捉するべきでした。そうならない理由はありますか？

アップデート： リフレクターを使用して外部アセンブリを追跡しましたが、ネジが切られている形跡はまったく見つかりませんでした。このアセンブリは、ANTLR が生成したコードのランタイムユーティリティクラスにすぎないようです。スローされる例外は TimeDefLexer.mTokens() メソッドからのもので、その型は NoViableAltException であり、RecognitionException -> Exception から派生します。この例外は、レクサーがストリーム内の次のトークンを理解できない場合にスローされます。つまり、無効な入力です。この例外は発生することが想定されていますが、try/catch ブロックによってキャッチされるはずです。

また、ParserException の再スローは、この状況とはまったく無関係です。これは、解析中に例外を受け取り、独自の ParserException に変換する抽象化レイヤーです。私が経験している例外処理の問題は、そのコード行に到達することがありません。実際、「throw new ParserException」部分をコメントアウトしましたが、同じ結果が得られました。

もう 1 つ、問題の元の try/catch ブロックを変更して、代わりに NoViableAltException をキャッチし、継承の混乱を排除しました。それでも同じ結果が得られました。

ある人は、デバッグモードでは、VS が処理された例外をキャッチする際に過剰に動作することがあると示唆しましたが、この問題はリリースモードでも発生します。

やあ、私はまだ困惑しています！これまで言及していませんでしたが、私は VS 2008 を実行しており、コードはすべて 3.5 です。外部アセンブリは 2.0 です。また、コードの一部は 2.0 アセンブリのクラスをサブクラス化しています。バージョンの不一致がこの問題の原因となる可能性がありますか?

更新 2: .NET 3.5 コードの関連部分を .NET 2.0 プロジェクトに移植し、同じシナリオを複製することで、.NET バージョンの競合を排除することができました。.NET 2.0 で一貫して実行している場合、同じ未処理の例外を複製することができました。

ANTLR が最近 3.1 をリリースしたことを知りました。そこで、3.0.1からアップグレードして再試行しました。生成されたコードは少しリファクタリングされていることがわかりましたが、同じ未処理の例外が私のテストケースでも発生しました。

アップデート 3:このシナリオを次の方法で再現しました。簡素化された VS 2008 プロジェクト. 。自由にプロジェクトをダウンロードしてご自身で確認してください。私はすべての素晴らしい提案を適用しましたが、まだこの障害を克服できていません。

回避策を見つけた場合は、その結果をぜひ共有してください。再度、感謝します！

ありがとうございます。ただし、VS 2008 は未処理の例外が発生すると自動的に中断します。また、[デバッグ] -> [例外] ダイアログもありません。スローされる NoViableAltException は完全に意図されており、ユーザーコードによってキャッチされるように設計されています。期待どおりにキャッチされないため、プログラムの実行は未処理の例外として予期せず停止します。

スローされる例外は Exception から派生したものであり、ANTLR ではマルチスレッドは行われません。

解決

問題は理解できたと思います。例外はキャッチされますが、問題は、デバッガの動作に関する混乱と、デバッガを再現しようとする各人のデバッガ設定の違いです。

再現者からの 3 番目のケースでは、次のメッセージが表示されていると思います。「NoViableAltException はユーザーコードによって処理されませんでした」と次のようなコールスタックが表示されます。

         [External Code]    
    >   TestAntlr-3.1.exe!TimeDefLexer.mTokens() Line 852 + 0xe bytes   C#
        [External Code] 
        TestAntlr-3.1.exe!TimeDefParser.prog() Line 141 + 0x14 bytes    C#
        TestAntlr-3.1.exe!TestAntlr_3._1.Program.ParseTest(string Text = "foobar;") Line 49 + 0x9 bytes C#
        TestAntlr-3.1.exe!TestAntlr_3._1.Program.Main(string[] args = {string[0x00000000]}) Line 30 + 0xb bytes C#
        [External Code]

コールスタックウィンドウを右クリックして、外部コードの表示をオンにすると、次のように表示されます。

        Antlr3.Runtime.dll!Antlr.Runtime.DFA.NoViableAlt(int s = 0x00000000, Antlr.Runtime.IIntStream input = {Antlr.Runtime.ANTLRStringStream}) + 0x80 bytes   
        Antlr3.Runtime.dll!Antlr.Runtime.DFA.Predict(Antlr.Runtime.IIntStream input = {Antlr.Runtime.ANTLRStringStream}) + 0x21e bytes  
    >   TestAntlr-3.1.exe!TimeDefLexer.mTokens() Line 852 + 0xe bytes   C#
        Antlr3.Runtime.dll!Antlr.Runtime.Lexer.NextToken() + 0xc4 bytes 
        Antlr3.Runtime.dll!Antlr.Runtime.CommonTokenStream.FillBuffer() + 0x147 bytes   
        Antlr3.Runtime.dll!Antlr.Runtime.CommonTokenStream.LT(int k = 0x00000001) + 0x2d bytes  
        TestAntlr-3.1.exe!TimeDefParser.prog() Line 141 + 0x14 bytes    C#
        TestAntlr-3.1.exe!TestAntlr_3._1.Program.ParseTest(string Text = "foobar;") Line 49 + 0x9 bytes C#
        TestAntlr-3.1.exe!TestAntlr_3._1.Program.Main(string[] args = {string[0x00000000]}) Line 30 + 0xb bytes C#
        [Native to Managed Transition]  
        [Managed to Native Transition]  
        mscorlib.dll!System.AppDomain.ExecuteAssembly(string assemblyFile, System.Security.Policy.Evidence assemblySecurity, string[] args) + 0x39 bytes    
        Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() + 0x2b bytes  
        mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x3b bytes   
        mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x81 bytes    
        mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x40 bytes

デバッガーのメッセージは、コードの外部 (NoViableAlt から) で発生した例外が、処理されずに TestAntlr-3.1.exe!TimeDefLexer.mTokens() 内のコードを通過していることを示しています。

表現が紛らわしいですが、例外がキャッチされないという意味ではありません。デバッガは、所有するコード mTokens()" が、この例外がスローされることに対して堅牢である必要があることを知らせています。

問題を再現しなかった人にとって、これがどのように見えるかを確認するには、次のことを試してください。

ツール/オプション/デバッグに移動し、「コードのみを有効にする（管理のみ）」をオフにします。またはオプション。
デバッガー/例外に移動し、一般的なランタイムの例外のために「ユーザーのハンドル」をオフにします。

他のヒント

アセンブリがリリースビルドとしてコンパイルされているかどうかに関係なく、例外は呼び出し元に確実に「バブル」するはずであり、デバッグモードでコンパイルされていないアセンブリがそれに影響を与える理由はありません。

おそらく例外が別のスレッドで発生しているというダニエルの意見に同意します。Application.ThreadException でスレッド例外イベントをフックしてみてください。これは、未処理のスレッド例外が発生したときに発生する必要があります。コードを次のように適応させることができます:-

using System.Threading;

...

void Application_ThreadException(object sender, ThreadExceptionEventArgs e) {
  throw new ParserException(e.Exception.Message, e.Exception);
}    

 ...

 var exceptionHandler = 
    new ThreadExceptionEventHandler(Application_ThreadException);
 Application.ThreadException += exceptionHandler;
 try {
    // Execution stopped at parser.prog()
    TimeDefParser.prog_return prog_ret = parser.prog();
    return prog_ret == null ? null : prog_ret.value;
 }
 catch (Exception ex) {
    throw new ParserException(ex.Message, ex);
 }
 finally {
    Application.ThreadException -= exceptionHandler;
 }

.Net 1.0 または 1.1 を使用していますか?その場合、catch(Exception ex) はアンマネージコードからの例外をキャッチしません。代わりに catch {} を使用する必要があります。詳細については、次の記事を参照してください。

http://www.netfxharmonics.com/2005/10/net-20-trycatch-and-trycatchException/

ここで何が起こっているのか教えてください...

Visual Studio は、例外が処理されていないと判断するため、壊れています。アンハンドリングってどういう意味ですか？Visual Studio では、ツールに設定があります...オプション...デバッグ中...一般的な...「マイコードのみを有効にする (マネージドのみ)」。これがチェックされており、例外がコードから伝播し、「コードではない」アセンブリ (Antlr など) に存在するメソッド呼び出しに関連付けられたスタックフレームに伝播した場合、それは「未処理」とみなされます。このため、私は「マイコードのみを有効にする」機能をオフにしています。でも、私に言わせれば、これはダメなんです…。これを行うとしましょう:

ExternalClassNotMyCode c = new ExternalClassNotMyCode();
try {
    c.doSomething( () => { throw new Exception(); } );
}
catch ( Exception ex ) {}

doSomething がそこで匿名関数を呼び出し、その関数が例外をスローします。

「マイコードのみを有効にする」がオンになっている場合、これは Visual Studio によれば「未処理の例外」であることに注意してください。また、デバッグモードではブレークポイントであるかのように停止しますが、非デバッグ環境または運用環境ではコードは完全に有効で、期待どおりに動作することに注意してください。また、デバッガーで単に「続行」すると、アプリは順調に続行します (スレッドは停止しません)。例外はコード内にないスタックフレームを介して伝播するため、「未処理」とみなされます。外部ライブラリ内)。私に言わせれば、これはひどいことだ。このデフォルトの動作を変更してください。これは、例外を使用してプログラムロジックを制御する完全に有効なケースです。場合によっては、他の方法で動作するようにサードパーティライブラリを変更できないことがあります。これは、多くのタスクを実行するのに非常に便利な方法です。

MyBatis を例に挙げると、この手法を使用して、SqlMapper.QueryWithRowDelegate の呼び出しによって収集されているレコードの処理を停止できます。

別のスレッドで例外がスローされている可能性はありますか?明らかに、呼び出しコードはシングルスレッドですが、使用しているライブラリが内部でマルチスレッド操作を実行している可能性があります。

私は @Shaun Austin と一緒です - try を完全修飾名でラップしてみてください

catch (System.Exception)

ANTLR ドキュメントには、どの例外をスローする必要があるかが記載されていますか?

私にとって、catch (Exception) 句はあらゆる例外を捕捉するべきでした。そうならない理由はありますか？

私が考えることができる唯一の可能性は、他の何かがあなたの前にそれをキャッチし、キャッチされなかった例外のように見える方法でそれを処理していることです（例：プロセスを終了します)。

私の try/catch ブロックはそれをキャッチせず、代わりに未処理の例外として実行を停止します。

終了プロセスの原因を見つける必要があります。未処理の例外以外の何かである可能性があります。「{,,kernel32.dll}ExitProcess」にブレークポイントを設定してネイティブデバッガーを使用してみてください。次に、使用します SOS どのマネージコードが終了プロセスを呼び出しているかを判断します。

個人的には、スレッド理論にはまったく納得できません。

以前にこれを見たことがあったのは、Exception も定義されているライブラリを使用していて、実際の Catch が別の "Exception" 型を参照していることを意味していました (完全修飾されている場合は Company でした)。 Lib.Exception を使用していましたが、使用のせいでそうではありませんでした）、スローされていた通常の例外（私の記憶が正しければ、ある種の引数例外）をキャッチすることになると、型が一致しないため、それをキャッチできませんでした。

要約すると、そのクラスで使用されている別の名前空間に別の例外タイプはありますか?

編集：これを簡単に確認する方法は、catch 句で例外の種類を「System.Exception」として完全に修飾して、試してみることです。

編集2:OK、コードを試してみたので、今のところ敗北を認めます。誰も解決策を思い浮かばない場合は、朝もう一度検討する必要があります。

うーん、問題がわかりません。サンプルソリューションファイルをダウンロードして試しました。

TimeDefLexer.cs の 852 行目で例外がスローされ、その後、Program.cs の catch ブロックによって処理されます。 処理された例外.

その上の catch ブロックのコメントを解除すると、代わりにそのブロックに入ります。

ここで何が問題になっているように見えますか？

Kibbee 氏が述べたように、Visual Studio は例外が発生すると停止しますが、続行するように要求すると、例外はコードによってキャッチされます。

サンプルの VS2008 プロジェクトをダウンロードしましたが、ここでも少し戸惑っています。ただし、おそらくあなたにとってうまくいく方法ではないかもしれませんが、私は例外を乗り越えることができました。しかし、ここで私が見つけたものは次のとおりです。

これメーリングリストの投稿あなたが経験しているのと同じ問題について話し合いました。

そこから、メインのprogram.csファイルにいくつかのダミークラスを追加しました。

class MyNoViableAltException : Exception
{
    public MyNoViableAltException()
    {
    }
    public MyNoViableAltException(string grammarDecisionDescription, int decisionNumber, int stateNumber, Antlr.Runtime.IIntStream input)
    {
    }
}
class MyEarlyExitException : Exception
{
    public MyEarlyExitException()
    {
    }

    public MyEarlyExitException(int decisionNumber, Antlr.Runtime.IIntStream input)
    {
    }
}

次に、 using 行を TimeDefParser.cs と TimeDefLexer.cs に追加しました。

using NoViableAltException = MyNoViableAltException;
using EarlyExitException = NoViableAltException;

これにより、例外が偽の例外クラスにバブルされ、そこで処理できるようになりますが、依然として TimeDefLexer.cs の mTokens メソッドで例外がスローされていました。それをそのクラスの try catch でラップすると例外がキャッチされました。

            try
            {
                alt4 = dfa4.Predict(input);
            }
            catch
            {
            }

スレッドが機能していない場合に、エラーを処理するために呼び出される場所ではなく、内部メソッドでラップする理由が本当にわかりませんが、とにかく、これで私よりも賢い誰かが正しい方向に向かうことを願っています。

コードをダウンロードしましたが、すべて期待どおりに動作します。

Visual Studio デバッガーはすべての例外を正しくインターセプトします。Catch ブロックは期待どおりに機能します。

Windows 2003 サーバー SP2、VS2008 Team Suite (9.0.30729.1 SP) を実行しています。

プロジェクトを .NET 2.0、3.0、および 3.5 用にコンパイルしようとしました

@Steve Steiner、あなたが言及したデバッガーオプションはこの動作とは何の関係もありません。

これらのオプションを試してみましたが、目に見える効果はありませんでした。catch ブロックはすべての例外をインターセプトしました。

Steve Steiner は、例外が antlr ライブラリで発生し、mTokens() メソッドを通過して antlr ライブラリで捕捉されたという指摘は正しいです。問題は、このメソッドが antlr によって自動生成されることです。したがって、mTokens() で例外を処理するための変更は、パーサー/レクサークラスを生成するときに上書きされます。

デフォルトでは、antlr はエラーをログに記録し、解析の回復を試みます。これをオーバーライドして、エラーが発生するたびに parser.prog() が例外をスローするようにすることができます。あなたのコード例から、これはあなたが期待していた動作であると思います。

このコードをグラマー (.g) ファイルに追加します。デバッグメニューで [マイコードのみを有効にする] をオフにする必要もあります。

@members {

    public override Object RecoverFromMismatchedSet(IIntStream input,RecognitionException e,    BitSet follow)  
    {
        throw e;
    }
}

@rulecatch {
    catch (RecognitionException e) 
    {
        throw e;
    }
}

これは、『Definitive ANTLR Reference』の「最初のエラーで認識機能を終了する」の章に記載されている例の C# バージョンでの私の試みです。

これがあなたが探していたものであることを願っています。

例外が発生するとすぐに中断するように VS.Net を設定できます。プロジェクトをデバッグモードで実行するだけで、例外がスローされるとすぐに停止します。そうすれば、なぜ捕まらないのかがよくわかるはずです。

また、いくつかのコードを追加することもできますすべての未処理の例外をキャッチする. 。詳細についてはリンクを参照してください。基本は次の 2 行です。

Application.ThreadException += new ThreadExceptionEventHandler(ThreadExceptionHandler);

 // Catch all unhandled exceptions in all threads.
 AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(UnhandledExceptionHandler);

ああ、Kibbee が言ったことに関して言えば、VS で [デバッグ] | [例外] を選択し、「スローされた」列のすべてのボックスをクリックするだけで、選択されるはずです すべて 私の知る限りでは、「最初のチャンスの例外」として、つまりVS は、例外が発生したときにそれを示します。 について 他のすべてのものによって処理され、関連するコードが中断されます。これはデバッグに役立つはずです。

最良のオプションは、すべての未処理例外でブレークするように Visual Studio を設定することのようです ([デバッグ] -> [例外] ダイアログで、[共通言語ランタイム例外] のボックスをオンにし、場合によっては他の例外もチェックします)。次に、プログラムをデバッグモードで実行します。ANTLR パーサーコードが例外をスローすると、Visual Studio によって例外がキャッチされ、例外が発生している場所、例外の種類などを確認できるようになります。

説明に基づくと、catch ブロックは正しいようです。そのため、次のいずれかのことが起こっている可能性があります。

パーサーは実際には例外をスローしていません
パーサーは最終的に System.Exception から派生していないものをスローします。
別のスレッドで例外がスローされ、処理されていません

問題 #3 を除外する可能性があるようですね。

リフレクターを使用して外部アセンブリを追跡しましたが、ネジが切られている形跡はまったく見つかりませんでした。

スレッドが見つからないということは、スレッドが存在しないという意味ではありません

.NET には、ほとんどアイドル状態にある「予備」スレッドのセットである「スレッドプール」があります。特定のメソッドはスレッドプールスレッドの 1 つで実行されるため、メインアプリがブロックされません。

露骨な例は次のようなものです ThreadPool.QueueUserWorkItem, 、しかし、それほど明白ではないものをスレッドプール内で実行できるものは他にもたくさんあります。 Delegate.BeginInvoke

本当に、そうする必要がありますキビーの提案に従ってください.

Visual Studio を使用せず、コンソールでアプリケーションを実行せずに、catch 句内で例外を出力 (Console.WriteLine()) しようとしたことがありますか?

私はスティーブ・スタイナーが正しいと信じています。スティーブの提案を調べていると、次のことに気づきました。このスレッドツール | オプション | デバッガー | 一般の [マイコードのみを有効にする] オプションについて説明します。非ユーザーコードが例外をスローまたは処理する場合、特定の状況でデバッガーが中断することが推奨されています。なぜこれが重要なのか、実際には例外が処理されなかったのになぜデバッガが例外が処理されなかったと具体的に示すのか、正確にはわかりません。

「Enable Just My Code」オプションを無効にすることで、誤った中断を排除することができました。これにより、「ユーザー処理」列が削除され、適用されなくなるため、[デバッグ|例外] ダイアログも変更されます。または、CLR の「ユーザー処理」ボックスのチェックを外すだけでも、同じ結果が得られます。

みんな助けてくれて本当にありがとう！

「また、ハンドルされていないすべての例外をキャッチするために、コードを入れることができます。詳細についてはリンクを読んでくださいが、基本はこれらの2つの行です。」

これは誤りです。これは、.NET 1.0/1.1 ではすべての未処理の例外をキャッチしていましたが、これはバグであり、キャッチされるべきではなかったので、.NET 2.0 で修正されました。

AppDomain.CurrentDomain.UnhandledException

プログラムが終了する前に例外をログに記録できるように、最後のチャンスのログサルーンとして使用することのみを目的としています。2.0 以降では例外をキャッチしません (ただし、少なくとも .NET 2.0 では、1.1 のように動作するように変更できる設定値がありますが、これを使用することはお勧めできません)。

いくつかの例外があることに注意してください。 できない StackOverflowException や OutOfMemoryException などのキャッチ。それ以外の場合は、他の人が示唆しているように、どこかのバックグラウンドスレッドで例外が発生している可能性があります。また、一部/すべてのアンマネージ/ネイティブ例外もキャッチできないと確信しています。

理解できません...catch ブロックは新しい例外を (同じメッセージとともに) スローするだけです。つまり、あなたの発言は次のとおりです。

問題は、場合によっては (すべてではありません)、try/catch ブロックがそれをキャッチせず、ハンドルされない例外として実行を停止することです。

まさにそれは何ですか 期待される 発生する。

同意するダニエル・オージェそしてクロノスこれはスレッドに関係する例外のような気がします。それ以外に、私のその他の質問は次のとおりです。

完全なエラーメッセージには何と書かれていますか?それはどのような例外ですか?
ここで提供したスタックトレースに基づくと、例外は TimeDefLexer.mTokens() のコードによってスローされませんか?

私が不明確であるかどうかはわかりませんが、もしそうであれば、NoViableAltException タイプの「未処理例外」でデバッガーが実行を停止していることがわかります。当初、私はこの [デバッグ] -> [例外] メニュー項目について何も知りませんでした。MS は、VS のインストール時に、プロファイルの違いがわからない場合にプロファイルにコミットすることを期待しているからです。どうやら、 C# 開発プロファイルに参加していなかったので、このオプションがありませんでした. 。最終的にスローされたすべての CLR 例外をデバッグしましたが、残念ながら、このハンドルされない例外の問題の原因となる新しい動作を発見できませんでした。スローされた例外はすべて予期されたものであり、try/catch ブロックで処理されると考えられていました。

外部アセンブリを確認しましたが、マルチスレッドの証拠はありません。これは、System.Threading への参照が存在せず、デリゲートがまったく使用されていないことを意味します。私はそれがスレッドのインスタンス化を構成することをよく知っています。これを確認するには、未処理の例外が発生した時点で [スレッド] ツールボックスを観察し、実行中のスレッドが 1 つだけであることを確認します。

私は ANTLR の人々と未解決の問題を抱えているので、おそらく彼らは以前にこの問題に取り組むことができたでしょう。VS 2008 および VS 2005 で .NET 2.0 および 3.5 を使用して、単純なコンソールアプリプロジェクトでそれを複製することができました。

コードが既知の有効なパーサー入力でのみ動作するように強制されるため、これは単なる問題点です。を使用して IsValid() ユーザー入力に基づいてハンドルされない例外をスローした場合、メソッドは危険です。この問題についてさらに詳しいことがわかり次第、この質問を最新の状態に保ちます。

@スポールソン

再現していただけるのであれば、どこかに載せていただけないでしょうか？試してみる方法の 1 つは、SOS 拡張機能を備えた WinDBG を使用してアプリを実行し、ハンドルされない例外をキャッチすることです。最初の例外 (ランタイムがハンドラーを見つけようとする前) で中断され、その時点で、その例外がどこから来たのか、どのスレッドから来たのかがわかります。

これまでに WinDBG を使用したことがない場合は、少し圧倒されるかもしれませんが、ここに優れたチュートリアルがあります。

http://blogs.msdn.com/johan/archive/2007/11/13/getting-started-with-windbg-part-i.aspx

WinDBG を起動したら、[デバッグ]、[イベントフィルター] の順に選択して、未処理例外の中断を切り替えることができます。

うわー、これまでのレポートのうち、2 つは正しく動作し、1 つは私が報告した問題が発生しました。Windows、使用されている Visual Studio、および .NET Framework のバージョンとビルド番号は何ですか?

XP SP2、VS 2008 Team Suite (9.0.30729.1 SP)、C# 2008 (91899-270-92311015-60837)、および .NET 3.5 SP1 を実行しています。

プロジェクトで com オブジェクトを使用しており、catch ブロックで例外をキャッチしようとしている場合は、[ツール/デバッグ/例外が AppDomain またはマネージド/ネイティブの境界を越えたときに中断する(マネージドのみ)] オプションを無効にする必要があります。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow