0

Visual Studio 2005でWindowsクラッシュダンプを開いたときに、このコールスタックを取得しました。

>   myprog.exe!app_crash::CommonUnhandledExceptionFilter(_EXCEPTION_POINTERS * pExceptionInfo=0x0ef4f318)  Line 41  C++
    pdm.dll!513fb8e2()  
    [Frames below may be incorrect and/or missing, no symbols loaded for pdm.dll]   
    kernel32.dll!_UnhandledExceptionFilter@4()  + 0x1c7 bytes   
    ...

モジュールのロード情報を確認します。

...
'DumpFM-V235_76_1_0-20110412-153403-3612-484.dmp': Loaded '*C:\Program Files\Common Files\Microsoft Shared\VS7Debug\pdm.dll', No matching binary found.
...

ダンプの分析に使用されたマシンは、ダンプを生成したマシンとは異なるマシンであるため、このバイナリはロードされていません。

現在、この他のマシンにアクセスできません。どういうわけかこのスタックを修正できますか、それともこの正確なパスの場所に正確なバイナリが常に必要ですか？

4

2 に答える 2

1

Visual Studioでこのダンプをデバッグする必要がある場合は、ダンプを生成したマシンから.dmpファイルと同じフォルダーにシステムDLLをコピーする必要があります。そうすれば、元のシステム（おそらく同じモジュールの異なるバージョンが含まれる）と同じパスでデバッグシステム上でそれらを見つけようとするのではなく、それらのバイナリをロードします。

ただし、Naveenが指摘しているように、WinDBGにダンプをロードするときにこの問題は発生しません（理由はまだわかりません）。そのため、クライアントからダンプを取得するときは、常にWinDBGで分析します。

クラッシュダンプ分析にWinDBGを使用する際のヘルプが必要な場合は、次のWebサイトにこのテーマに関する情報が満載です：http ：//www.dumpanalysis.org/ 。

于 2011-05-29T21:49:50.417 に答える
1

もう1つのオプションは、 DebugInfo.comの人々が提供するModuleRescueツールを使用することです。これにより、ダンプファイルがスキャンされ、シンボルをロードしていないモジュールを選択できるようになります。次に、デバッガーがシンボルサーバーからシンボルをロードするのに十分な情報を含む偽のモジュールが生成されます。

Visual Studioがこのモジュールのシンボルを読み込めず、シンボルを見つけるように求めるダイアログを開いた場合は、デバッガーをその偽のモジュールに向けるだけで、正しく読み込まれます。

このツールは、ワークフローは異なりますが、基本的にWinDbgと同じことを行います。

于 2015-05-22T13:18:22.730 に答える