1

例外が発生したときに、パラメーターを使用して .NET アプリケーションのミニ ダンプを作成しました。

MiniDumpNormal | MiniDumpWithProcessThreadData | MiniDumpWithThreadInfo | MiniDumpWithUnloadedModules

これは、マネージ コールスタックを抽出するために必要です (最小の MIDUMP_TYPE から、.net コンポーネントをホストするネイティブ C++ プロセスをダンプして、 windbg で !clrstack を使用できるように設定されています)。ここで説明されているように、ミニ ダンプの生成は例外フィルターで実行されます。

!dumpstackWinDBG でクラッシュ ダンプを実行すると、次のようなものが表示されます。

ChildEBP RetAddr  Caller,Callee
...
001dccc0 09b301a3 (MethodDesc 0x274268c +0x133 MyNameSpace.ErrorObject.FaultyMethod(Int32))
...

私が間違っていなければ、これはメソッド FaultyMethod のオフセット 0x133 でエラーが生成されたことを意味します。ここで、0x133 は JIT コンパイル済みマシン コードのオフセットです。

このオフセットをソース コードまたは IL 行番号に変換して、例外の原因となった命令を特定するにはどうすればよいですか?

4

2 に答える 2

1

windbg でSOS.dllを使用してデバッグを試みましたか? コマンドを使用しCLRStackて、マネージ コードのスタック トレースを取得できます。SOS をロードする手順については、「 WinDbg で SOS をロードできない」を参照してください。しかし、あなたが言うようにdumpstack、命令オフセットを与えます。

命令オフセットを変換するには、不格好ですが実行可能な方法は、疑わしいアセンブリを ILDASM にロードし、クラスとメソッド/プロパティにドリルダウンして、IL を確認することです。命令の前には IL_XXXX が付きます。ここで、XXXX はメソッドの開始点からの 16 進オフセットです。正確なコードは提供されませんが、特にメソッド呼び出しに関する詳細情報が提供されます。

于 2012-09-24T11:00:29.747 に答える
0

誰かが興味を持っている場合は、ここに問題への私のアプローチがあります。MiniDumpWithIndirectlyReferencedMemory通話に追加することから始まりMiniDumpWriteDumpます。これにより、スタック上のポインターによって参照されるメモリ ページが含まれます。私のテストでは、MSDN には「このオプションを使用すると、ミニダンプ ファイルのサイズが大幅に増加する可能性があります」と記載されていますが、ミニ ダンプ ファイルのサイズは数 100 KB しか増加しませんでした。

これで、例外をスローしたメソッドのコンパイル済みマシン コードがダンプで利用できるようになりました。この手段!uは、WinDBG/SOS でコードを逆アセンブルするために使用できます。これは正確には IL またはソース コードではありませんが、マシン コードの命令を IL/ソース コードと一致させるのはそれほど難しいことではありません。このブログ投稿では、その方法の例を紹介しています。

于 2012-09-28T07:15:20.547 に答える