問題タブ [minidump]

ご挨拶。

最近、XPラップトップでバグチェックを受けています。最後のデータは次のとおりです。

0x40000080 (0x8a43d130、0x858ffd20、0xba4f3e5c、0x00000001)

私はミニダンプのみを有効にしており (それ以来変更しましたが、BSOD はまだ見ていません)、「C:\windows\Minidump」ディレクトリを見ると、過去 6 か月から 11 個のミニダンプが表示されます。毎月のバグチェック

「Windows用デバッグツール」からwindbgとその仲間を実行すると、エラー「0n1392」が発生します。これは、要するに「破損」と読みます。16 進エディタでファイルを調べると、ファイルの上部に ASCII 文字列 "PAGEPAGE" が吹き付けられているため、診断に同意する傾向があります。

私は本当に2つの質問があります:

1) すべてのミニダンプ ファイルが破損する原因は何ですか?

2) このバグ チェックの原因と思われるデータを抽出する方法はありますか?

あなたの助けに感謝します!

付録 I - ミニダンプ ファイルに対する dumpchk の応答

付録 II - 破損したミニダンプ ファイルの 16 進表示:

アプリでミニ ダンプを作成して、未処理の例外をデバッグできるようにしたいと考えています。

必要なミニ ダンプの種類は、ダンプが作成されるまでわからない場合があります。可能な限り完全なダンプを作成するには、 MINIDUMP_TYPEフラグのどの組み合わせを使用すればよいでしょうか?

たとえば、.NET デバッグ用のミニ ダンプについては、いくつかの矛盾する意見があります。

ミニダンプのスナップショットと SOS

対

ミニダンプは .NET ではほとんど役に立たない

それらは私にとっては便利なように思えますが、なぜそれらが役に立たないと考える人がいるのでしょうか?

アプリケーションがクラッシュすると、事後分析デバッグを可能にするミニダンプが生成されます。オプション MiniDumpWithIndirectlyReferencedMemory と MiniDumpWithPrivateReadWriteMemory を使用します。

ダンプファイルのサイズが 500MB を超え始めた最近まで、すべてうまく機能していました。そのサイズのダンプのデバッグを開始しようとすると、Visual Studio から次のエラーがスローされます。

「このコマンドを処理するのに十分なストレージがありません」

私は 32 ビットの WinXP を使用しており、4 GB の RAM を搭載していますが、使用している RAM は 1 GB 未満です。この手順で VS2008 のメモリがどれほど経済的であるかにもよりますが、十分なアドレス可能なスペースが必要です。

やりたくないこと：

• WinXP をハックしてメモリを増やします。アプリは成長し続けるため、これは一時的にしか機能しません。私が見つけた可能なアクションのリストは次のとおりです 。
• 64 ビット OS に切り替える
• MiniDumpWithPrivateReadWriteMemory オプションを省略します

では、これをどのように解決すればよいでしょうか。

• ダンプからいくつかの dll を省略しますか? 含まれているメモリを dll のグループから異なるダンプに分割しますか? これを行う方法について何か考えはありますか？（これが可能であれば）
• ...？

次のようにして未処理の例外フィルターを設定しました: SetUnhandledExceptionFilter(UnhandledException)

UnhandledException 関数では、MiniDumpWriteDump を使用してミニダンプを書き出します。

MiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(), hFile, MiniDumpNormal, excpInfo? &eInfo : NULL, NULL, NULL);

WinDbg のスタック トレースを見ると、あまりわかりません。

MiniDumpWriteDump のドキュメントには、strack トレースが良くない可能性があると記載されていますが、それについて何をすべきかよくわかりません: http://msdn.microsoft.com/en-us/library/ms680360%28v=vs.85 %29.aspx

どんな助けでも大歓迎です！

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

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

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

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

COM Excel アドイン、C#、VS 2008、Excel COM アドイン、テスト VM でテスト、正常に動作 お客様がインストールしてブルー スクリーンが表示されましたが、理由がわかりません。以下は、顧客が得たものです。誰か助けてくれませんか？これが何なのか、何が原因なのか、私にはわかりません。これが私のアドインが原因なのか、顧客の PC に問題があるのか​​はわかりません。

ありがとう

Microsoft (R) Windows Debugger バージョン 6.12.0002.633 X86 Copyright (c) Microsoft Corporation. 全著作権所有。

Loading Dump File [c:\windows\minidump\Mini050911-01.dmp] Mini Kernel Dump File: レジスタとスタック トレースのみ利用可能

警告: アクセスできないパス: 'c:\windows\i386' シンボル検索パス: srv*c:\symbols*http://msdl.microsoft.com/download/symbols 実行可能検索パス: c:\windows\i386 Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) 無料 x86 互換 製品: WinNt、スイート: TerminalServer SingleUserTS ビルド: 2600.xpsp_sp3_gdr.101209-1647 マシン名: カーネル ベース = 0x804d7000 PsLoadedModuleList = 0x8055d720 デバッグ セッション時間: 月2011 年 5 月 9 日 09:47:22.099 (UTC - 5:00) システム稼働時間: 2 日間 15:09:35.096 カーネル シンボルの読み込み ................................. …………………………………… ................................................................... ... Loading User Symbols Loading unloaded module list ...................................

• *
• バグチェック分析 *
• *

  ---

詳細なデバッグ情報を取得するには、!analyze -v を使用します。

バグチェック 1000007F、{8、80042000、0、0}

* 警告: igxpmp32.sys のタイムスタンプを確認できません エラー: モジュールのロードは完了しましたが、igxpmp32.sys のシンボルをロードできませんでした イメージ igxpdx32.DLL をロードできません、Win32 エラー 0n2 警告: igxpdx32.DLL のタイムスタンプを検証できません *エラー: モジュールのロードは完了しましたが、igxpdx32.DLL のシンボルをロードできませんでしたおそらく原因: igxpmp32.sys ( igxpmp32+44184 )

フォローアップ: MachineOwner

0: kd> !analyze -v

• *
• バグチェック分析 *
• *

  ---

UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f) これは、カーネル モードでトラップが発生したことを意味します。これは、カーネルが保持/キャッチすることを許可されていない種類のトラップ (バインド トラップ) または常に即死 (二重障害) である種類のトラップです。バグチェック パラメータの最初の数字はトラップの番号です (8 = 二重障害など)。これらのトラップの詳細については、Intel x86 ファミリのマニュアルを参照してください。ここに一部がありますこれらのコードの: kv が taskGate を示している場合は、コロンの前の部分で .tss を使用し、次に kv. それ以外の場合、kv がトラップフレームを示している場合は、その値に .trap を使用します。そうでない場合、適切なフレームの .trap は、トラップが取得された場所を示します (x86 では、これは手順 KiTrap に対応する ebp になります)。Endif kb は、修正されたスタックを表示します。 . 引数: Arg1: 00000008、EXCEPTION_DOUBLE_FAULT Arg2: 80042000 Arg3: 00000000 Arg4: 00000000

デバッグの詳細:

BUGCHECK_STR: 0x7f_8

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: EXCEL.EXE

LAST_CONTROL_TRANSFER: 805362cb から 80535dc8 へ

STACK_TEXT:
KiFastCallEntry+0xfc 97d0d574 805e701e 97d0d810 82000000 97d0d594 nt!ZwOpenKey+0x11 97d0d7e4 805e712a 00000002 805e70a0 00000000 nt!RtlpGetRegistryHandleAndPath+0x27a 97d0d82c 805e73e3 97d0d84c 00000014 97d0dba0 nt!RtlpQueryRegistryGetBlockPolicy+0x2e 97d0d854 805e79eb 00000003 e3fba72c 00000014 nt!RtlpQueryRegistryDirect+0x4b 97d0d8a4 805e7f10 e3fba72c 00000003 97d0d930 nt! RtlpCallQueryRegistryRoutine+0x369 97d0db40 b92f8184 00000005 e5eb4a28 97d0dba0 nt!RtlQueryRegistryValues+0x482 警告: スタック アンワインド情報が利用できません。次のフレームは間違っている可能性があります。97d0dbe8 b92bd85b 00000005 877fe5f4 877fe6f4 igxpmp32+0x44184 97d0e260 b92b9a7b 8938b358 97d0e290 00000000 igxpmp32+0x985b 97d0e274 b9496729 8938b358 97d0e290 00000a0c igxpmp32+0x5a7b 97d0e338 804ef19f 8938b040 8781d6b8 0000080c VIDEOPRT!

STACK_COMMAND: kb

FOLLOWUP_IP: igxpmp32+44184 b92f8184 ?? ???

シンボル_スタック_インデックス: 12

SYMBOL_NAME: igxpmp32+44184

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: igxpmp32

IMAGE_NAME: igxpmp32.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4b47be93

FAILURE_BUCKET_ID: 0x7f_8_igxpmp32+44184

バケット_ID: 0x7f_8_igxpmp32+44184

フォローアップ: MachineOwner

以前は、アプリケーションのクラッシュ（未処理の例外）によってXPマシンの％TEMP％フォルダーにミニダンプが作成されていましたが、Microsoftがこのロジックを変更したようです（おそらく更新により）。

ユーザーレベルのアプリケーションまたはサービスがクラッシュした場合でも、ミニダンプが作成されますか？どこに保存されますか？

PS：BSOD、システム、またはカーネルダンプには興味がありません。これは、Windowsをダウンさせないユーザーレベルのアプリケーションクラッシュに関係します。

MiniDumpWriteDump を介してアプリケーションの実行中に記録されたミニダンプがたくさんあります。ミニダンプは、開発マシンとは異なる OS バージョンのマシンで作成されました。

現在、dbghelp.dll を使用して、ミニダンプからスタック トレースを抽出するプログラムを作成しようとしています。MINIDUMP_MODULE_LIST を調べて SymLoadModule64 を呼び出していますが、パブリック シンボル サーバーから pdb (kernel32 など) をダウンロードできません。「C:\Windows\System32」をシンボル パスに追加すると、dll が検出され、シンボルがダウンロードされますが、もちろんミニダンプの dll と一致しないため、結果は役に立ちません。

では、適切な pdb をダウンロードして使用するように dbghelp.dll に指示するにはどうすればよいでしょうか。

[編集]

SymLoadModule64 はファイル名のみを取得し、バージョン/チェックサム情報を取得しないことを忘れていたため、明らかに SymLoadModule64 だけでは、dbghelp がどの pdb をダウンロードするかを判断できません。

この情報は、MINIDUMP_MODULE_LIST で実際に入手できますが、dbghelp API に戻す方法がわかりません。

追加のパラメーターを取る SymLoadModuleEx がありますが、それが必要なのか、追加のパラメーターに何を渡す必要があるのか​​ わかりません。

[編集]

デバッグ用 SDK には dbghelp.dll と一緒に dbgeng.dll が配布されていることに気付きましたが、今のところうまくいきません。MSDN は十分に文書化されているようで、windbg が使用するエンジンと同じであると述べています。たぶん、それを使用してスタック トレースを抽出できます。

MSDN には個々のコンポーネントのみが記載されており、それらがどのように連携するかは記載されていないため、dbgeng.dll を使用してミニダンプを処理するための紹介を誰かに教えてもらえれば、おそらく役立つでしょう。

運用 Win2003 Web サーバーの場合、w3wp.exe プロセスがクラッシュするたびに常にミニダンプをログに記録できるようにしたいと考えています...ADPLUS のドキュメントを読み、それを運用 Web サーバーに xcopy 展開しました。次のようにコマンド ラインから adplus.exe を起動しました。

adplus.exe -crash -MiniOnSecond -NoDumpOnFirst -pmn w3wp.exe -o C:\Dumps

これは「MiniOnSecond」をログに記録しますが、最初に完全なダンプもログに記録します-そして、私はそれらを望んでいません（それらは大きなファットファイルであり、必要なものがありません）。「-NoDumpOnFirst」フラグを実際に機能させる方法を見つけた人はいますか? さらに、ボックスを再起動するたびにこの動作が必要です。再起動時にバッチ ファイルを実行せずに、どのように実現できますか? Windows エラー報告 (WER) について読んだことがありますが、Win2008R2 サーバーでこの動作を実装するのは簡単です。2003 サーバーで動作させるにはどうすればよいですか?

ADPLUS と WER の両方のドキュメントを読みましたが、Win 2003 Server でミニダンプを簡単にキャプチャできるようにするには、実際のコマンド ラインやレジストリ設定について助けが必要です。ご協力いただきありがとうございます！