問題タブ [postmortem-debugging]

Adplus/windbg/sos 以外の .Net メモリ ダンプを分析するための優れた無料ツールを提案できますか?

AppVerifier の下で、アプリの 1 つが爆発します。DMP ファイルを取得しましたが、これはミニダンプです。具体的には、コール スタックを取得する一方で、障害プロセス用のユーザー空間メモリも必要です (多くのグローバルを使用します)。完全なダンプ ファイルを提供するように App Verifier (または Windows) を構成するにはどうすればよいですか?

vsjitdebugger が HKLM...\AeDebug で既定のデバッガーとして構成されている場合、vsjitdebugger によって表示されるデバッガーのリストに WinDbg を含めることは可能ですか?

理想的には、プロセスが未処理の例外に遭遇したときに使用できる vsjitdebugger の選択肢のリストに、さらにいくつかのコマンド ラインを含めることができるようにしたいと考えています。DrWatson を使用するか、WinDbg を使用して、後で検査するためにミニダンプを保存します。

状況は次のとおりです。

バックグラウンド

Visual Studio 2008 で開発された混合モードの .NET/Native アプリケーションがあります。

混合モードとは、ネイティブ C++ ライブラリを呼び出す C++ .NET でフロント エンドが記述されていることを意味します。ネイティブ コードは、必要に応じて新しいスレッドを開始するなど、アプリ内の作業の大部分を行います。.NET コードは、UI のみを目的としています (win フォーム)。

テスターのコンピューターで実行されているアプリケーションのリリース ビルドがあります。

ネイティブ ライブラリは完全に最適化された状態でコンパイルされていますが、デバッグも有効になっています (「デバッグ情報形式」は「プログラム データベース」に設定されています)。

これが意味することは、アプリケーションのデバッグ シンボルが PDB ファイルにあるということです。

問題

とにかく、テスターの 1 人が、XP で時折クラッシュするというアプリの問題を抱えています。ワトソン博士を数回実行して、クラッシュのミニダンプを取得できました。

(ミニダンプを使用して - 実際のアプリを実際にデバッグしているわけではありません) デバッグすると、すべてのデバッグ シンボルが正しく読み込まれます。すべてのネイティブ スレッドの完全なスタック トレースが正しく表示されます。他のスレッド (おそらく .NET スレッド) にはスタック トレースはありませんが、少なくともスレッドが開始された dll (つまり ntdll.dll) をすべて示しています。

失敗したスレッドを正しく報告します (「user(5).dmp の 0x0563d652 で未処理の例外: 0xC0000005: アクセス違反の読み取り場所 0x00000000)。

ただし、スレッドに入ると、有用なものは何も表示されません。スタック トレースには、メモリ アドレス "0563d652()" ("ntldll.dll" でさえない) を持つ単一のエントリがあります。

逆アセンブリに入ると、約 30 命令のランダムなセクションが表示されます。メモリ アドレスの両側は、"???" だけです。ソース コードの一部ではないように見えます (バイナリがメモリに順番にロードされていませんか? アセンブリ ステートメントのランダムなセットがどこにもないのは普通のことですか?)。

私の質問

したがって、基本的に私の質問は3倍です。

1) デバッガーの情報不足について説明できる人はいますか?

2）念頭に置いて、コードでエラーが発生したことを示すことはできません。誰かが失敗の理由を提案できますか

3) 将来、この現在の問題を診断するために何か他にできることはありますか?

ヘルプ！

ジョン

アップデート：

これは、WinDBG からの失敗したスレッドのスタック ダンプです。

変でしょ？DLLすら表示されません。

何らかの理由でスタック/ヒープが破損し、スレッドが破損した可能性はありますか?

とにかく、gdb のコアファイルから PyObject* の python 値を発見する方法はありますか?

クロスプラットフォームのクラッシュハンドラーを探しています。Google Breakpadは有望に見えますが、ドキュメントが非常に不足しており、実際に実行するにはかなりの手間が必要です。

より良い代替案は何ですか？

必要なのは、クラッシュ時のクラッシュダンプ、スタックトレース、およびCPU情報を確実に記録する機能です。または、Google Breakpadを使用した経験は何ですか？それは素晴らしかったですか、それとも恐ろしいですか？

インストール時に .NET マネージド アプリケーションで ngen が実行され、アプリの Windows エラー報告からクラッシュ ダンプが取得された場合、それを使用してスタック トレースや変数などを確認するにはどうすればよいでしょうか?

質問に関連する背景を次に示します。インストール時に生成される .NET アプリがあります。未処理の .NET 例外が原因でクラッシュした場合、クラッシュは Windows エラー報告に分類され、そこから winqual.microsoft.com から minidump.mdmp ファイルをダウンロードできました。

クラッシュしたアプリのビルド用の .dbg ファイルを含むフォルダーに minidump.mdmp を配置し、minidump.mdmp をダブルクリックして、VS2008 SP1 の新しいインスタンスで開きました。私のスタック トレースは次のようになります。

kernel32.dll!RaiseException() + 0x3d バイト
mscorwks.dll!RaiseTheExceptionInternalOnly() + 0x295 バイト
mscorwks.dll!JIT_Throw() + 0x130 バイト
MyApp.ni.exe!000007feee74c84c()
[以下のフレームは正しくないか、欠落している可能性があります。 MyApp.ni.exe のシンボルがロードされていません]
0000000070000d5e()
MyApp.ni.exe!000007feee611000()
000000000300bf78()
000000000300bf60()

[モジュール] ウィンドウには、OS および .NET DLL のシンボルが読み込まれていることが示されますが、アプリケーション モジュールの場合は次のようになります。

MyApp.exe -> シンボル ファイルにネイティブ シンボルがありません。
MyApp.ni.exe -> 一致するバイナリが見つかりません。
MyAppsLibrary.ni.dll -> 一致するバイナリが見つかりません。

VC++ 6 でビルドされた古い DLL ファイルがあります。ダンプ ファイルを調査する必要がありますが、使用可能な PDB がありません。WinDbg によって報告されるスタック トレースも不正確です。

Visual Studio の新しいバージョン、つまり 2003、2005、2008 でプロジェクトを再構築し、PDB を生成して、これを使用して古い DLL のシンボルにアドレスをマップすることはできますか? プロジェクトをビルドするための VC 6.0 互換モードのようなものはありますか?

VC++ 6 を入手することも 1 つのオプションですが、VS6.0 は MSDN サブスクライバーのダウンロード ページから既に消えているようです :(

ありがとう！

アプリケーション内で、MiniDumpWriteDump 関数 (dbghelp.dll を参照) を使用して、アプリケーションがクラッシュするたびにクラッシュ ダンプ ファイルを書き込みます。

また、シンボル サーバーを使用してすべての実行可能ファイルと pdb ファイルを保存しているため、顧客がクラッシュ ダンプ ファイルを送信するたびに、デバッガーが正しいバージョンの実行可能ファイルとデバッグ情報を自動的に取得します。

また、Windows DLL (ntdll.dll、kernel32.dll など) とそのデバッグ情報をシンボル サーバーに保存します (SymChk を使用)。デバッグ情報は、Microsoft のパブリック シンボル サーバーから取得されます。

次の場合を除いて、ほとんどの場合、これは完璧に機能します。

• お客様が Windows DLL の 1 つでクラッシュしました。
• 顧客は、私がシンボル サーバーに入れていない DLL を使用しています。

これは、すべての Windows DLL のすべてのフレーバーをシンボル サーバーに格納するのは非常にやり直しがきかないためです (特に週次パッチを使用する場合)。

そのため、顧客が NTDLL.DLL のバージョン 5.2.123.456 でクラッシュした場合、私はこの正確なバージョンの DLL をシンボル サーバーに配置していませんでした。Microsoft のパブリック シンボル サーバーでさえ、DLL 自体ではなく、デバッグ情報のみを提供するため、役に立ちません。

私の現在の解決策は、顧客に DLL を尋ねることですが、それは必ずしも簡単ではありません。したがって、私はより良い解決策を探しています。

正確なバージョンの DLL がなくても、デバッガーに正しいコール スタックを表示させたり、特定の DLL のデバッグ情報をロードさせたりする方法はありますか?

または、すべての (または重要な) Windows DLL のすべてのバージョンを (Microsoft から) 入手する方法はありますか?

編集：

その間、私はこの問題を解決する本当に簡単な方法を見つけました。ユーティリティ ModuleRescue ( http://www.debuginfo.com/tools/modulerescue.htmlを参照) を使用すると、ミニダンプ ファイルからダミーの DLL を生成できます。これらのダミー DLL を使用すると、デバッガーは満足し、Microsoft サーバーからデバッグ シンボルのロードを正しく開始します。

ミニダンプ ファイルの MiscInfoStream には、プロセスの作成時間が含まれています。クラッシュする前にプロセスが実行されていた時間を知りたいです。ミニダンプ ファイルには、例外のタイムスタンプがどこかに含まれていますか?

このダンプ ファイルの WinDbg は、次のように表示されます。これは、それがどこかにあることを意味します...

(DumpChk は、ストリームのリストの最後に同じ情報を表示します)

今日は 3 月 15 日なので、これがほぼ確実にクラッシュのタイムスタンプであることに注意してください。その値と「プロセス稼働時間」の値をプログラムで取得する方法が必要です。

MINIDUMP_MISC_INFO_3タイムゾーン情報を含む構造体を見つけましたが、例外時間が含まれていないようです。

一部のダンプ ファイルには、プロセス内の各スレッドのタイムスタンプを含む ThreadInfoListStream が含まれているように見えますが、これは私が確認したミニダンプには含まれていません。