2

私のwindbgスキルは少し錆びているので、これが明らかな場合はご容赦ください。

3 つのスレッドには例外があります。これは、それらが各スレッドのスタックの一番上にあるということですか? それがどのように発生するのかわかりません。最初の例外によって、ハンドルされていない例外ハンドラーが起動し、アプリがクラッシュする可能性があるからです。以下の出力を簡略化します。

!threads

   0    1 1e5c 0015c008   2006020 Enabled  00000000:00000000 0015a4a8     6 STA
   2    2 2734 00176740      b220 Enabled  00000000:00000000 0015a4a8     0 MTA (Finalizer)
   4    3 1f64 001b22d0   880b220 Enabled  00000000:00000000 0015a4a8     0 MTA 
  25   14 2714 0897ef78   180b220 Enabled  39e4bf38:39e4cbec 0015a4a8     0 MTA (Threadpool Worker)
  29   19 1884 0898a3b8  1000b221 Disabled 39f36d50:39f38bec 0015a4a8     0 MTA System.Threading.ThreadAbortException (39f36bf8)
  71   57 164c 274b41f0      b220 Enabled  39ef4098:39ef4bec 0015a4a8     4 MTA System.NullReferenceException (39ef3028)
  72   58 223c 274b1110   200b220 Enabled  00000000:00000000 0015a4a8     0 MTA
 107   83 1e60 275fe008      b020 Enabled  00000000:00000000 0015a4a8     0 MTA System.ObjectDisposedException (1e66684c)
4

4 に答える 4

2

Debug->Event Filters の下で、WinDbg がブレークする例外を設定できます。WinDbg を使用して .net デバッグを行ったことはありませんが、以前にこれらのイベント フィルターを使用して、特定の処理された例外をトラップし、問題のあるコードのコール スタックを取得しました。

もちろん、多くの処理された例外が発生するのはごく普通のことなので、アプリの状態が実際に何を意味するのかはわかりませんが、スレッドを切り替えてコールスタックをダンプし、例外コンテキストレコードを検査するか、必要かどうかを設定できるはずですWinDbg はこれらの例外の発生を中断し、それらが発生した場合はコール スタックを比較し、go を押して削除のプロセスとしてそれらを有効/無効にすることでクラッシュするかどうかを確認します。

于 2012-05-10T22:06:17.820 に答える
1

通常、windbg でクラッシュ ダンプを開くと、クラッシュ ダンプが読み込まれるとすぐに、クラッシュの原因となった例外が表示されます。これと同様のメッセージが windbg に表示されます。

「このダンプ ファイルには、対象となる例外が格納されています。格納された例外情報は、.ecxr 経由でアクセスできます。(1890.da0): スタック オーバーフロー - コード c00000fd (最初/2 番目のチャンスは利用できません)」

また、例外の原因となったスレッドは、クラッシュ ダンプをロードすると、windbg の左下隅に表示されるスレッド番号と同じである必要があります。

于 2012-05-11T09:37:26.250 に答える
0

OK、それで、どのスレッドがデバッガーを呼び出したのかを確実に知る方法はないようです。

于 2012-05-14T07:14:39.057 に答える