問題タブ [minidump]

C++ プロジェクトで事後分析デバッグを実行する必要があります。実行する既知の方法は、cdb デバッガーをミニダンプ ジェネレーターとして設定し、その後収集されたダンプを処理することです。ほぼすべての Web を読みましたが、クラッシュしたプロセスの名前でミニダンプを生成する解決策が見つかりませんでした

cdb がプロセスの名前でダンプ ファイルを生成するような方法で AeDebug\Debugger レジストリ変数を設定する方法はありますか? cdb.exe への呼び出しをバッチ ファイルにカプセル化すると、正常に起動しますが、シンボル検索でブロックされたままになります。バッチを停止するために Ctrl+C を実行する必要があります。その後、正しいプロセス名でミニダンプが作成されます...しかし、もちろん、無人の運用環境でそのようなことを設定することはできません...

誰もそれをやったことがありますか？

MiniDumpWriteDump 関数を使用していくつかのカスタム ダンプ ファイルを作成したい (主に、スレッド コールスタックの最小限の情報を含むダンプ ファイルをエクスポートしたい) が、渡す必要がある構造を定義するのが難しいコールバック関数へのパラメーター

呼び出しは次のようになります。

だから私の質問はMINIDUMP_CALLBACK_INPUTを定義する方法です:

問題を引き起こす C の構造体の定義は次のとおりです。

自動化されたクラッシュダンプ分析を構築しようとしていますが、cdbまたはwindbgでクラッシュダンプをロードできません。VS2008では問題なくロードされます。

ファイルに対してdumpchk.exeを実行すると、次のようになります。

ファイルに対してcdbを実行すると、次のようになります。

MiniDumpWriteDump()プロセス クラッシュの場合にミニダンプを書き込むために DbgHelp から使用するインプロセス クラッシュ ハンドラがあります。それが最善の方法ではないことは承知していますが、現時点では他に選択肢がありません。

問題は、特定の実行可能ファイルが常に 0 バイトのダンプを作成することです。しかし、他のプロセスではうまく機能します。この動作の背後にある考えられる理由は何ですか?

インストール時に .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 -> 一致するバイナリが見つかりません。

システム設定を変更して、プロセスからミニダンプを作成できません。だから私の質問は：

• クラッシュしたときに、システムはユーザープロセスのミニダンプを作成しますか

  はいの場合、どの設定を構成する必要がありますか

• または、プログラムでミニダンプを作成する必要がありますか。

• クラッシュの調査中のミニダンプの効果

私はWindowsXP、C ++、VC6を使用しています

私は何年にもわたって多くのゲーム プロジェクトでミニダンプを使用してきましたが、有効なコール スタックを持つ可能性は約 50% のようです。コールスタックを改善するにはどうすればよいですか?

最新の dbghelp.dll を exe ディレクトリに入れてみました。それはいくつかを助けるようです。

Visual Studio 2008 または 2010 はどちらが優れていますか? (私はまだ VS 2005 を使用しています)。

私が使用するコードは、このサンプルのようになります。

ミニダンプに埋め込むことができるユーザーストリームデータ構造に開発者がどのような有用なものを入れるのか興味があります。MSDNは、MiniDumpWriteDumpのパラメーターを次のように説明しています。

PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam

このようにパラメータを記述します：

UserStreamParam[in]MINIDUMP_USER_STREAM_INFORMATION構造体の配列へのポインター。このパラメーターの値がNULLの場合、ユーザー定義情報はミニダンプファイルに含まれません。

テスターは常にすべてのバグを含む適切な形式のログを送信しない傾向があるため、プログラムの最後のnログ行をユーザーストリームに埋め込むことを検討していました。

また、そのセクションにハードウェアの仕様（メモリ、CPU、ビデオなど）を入れることもできます。

他に人々はユーザーストリームセグメントを何のために使用しましたか？

いくつかの C++/CLI DLL を呼び出す C# アプリケーションで構成されるプロジェクトがあります。ネイティブ コードに Visual Studio C ランタイム ライブラリの致命的なエラーがある場合、それをキャッチする方法はないようです。

簡単な例を挙げると、これをネイティブ コードに入れると、次のようになります。

アプリがクラッシュします (リリース ビルドで)。例外はスローされず、__try...__except でキャッチできません。

この種のエラーをキャッチして、理想的にはコールスタックを使用して、適切なエラー ダイアログを表示できるようにしたいと考えています。ミニダンプを作成することにしましたが、C++/CLI DLL の 1 つで ::SetUnhandledExceptionFilter() を呼び出してミニダンプを作成しようとしましたが、どちらも機能していないようです。

.NET アプリケーションで C ランタイム ライブラリの致命的なエラーを適切に処理する方法はありますか?

ここで説明されているようなクラス/メソッドを使用する場合、スタックの一番上にある呼び出しの説明/アドレスを取得するにはどうすればよいですか?

基本的に、バグ追跡システムへの呼び出しで使用できる何らかの値が必要です。例外の原因となった命令のアドレスに基づいて「一意に」識別したい。

(通常、mydll.dll!1234ABDC() のような形式です)

編集：

背景情報:

欠陥追跡システム (fogbugz) に電子メールで送信するためのミニダンプを作成しています。重複を減らすために、クラッシュの妥当な「署名」を見つけようとしています。FB 用の xml PI があることは知っていますが、これにはユーザー ログオンが必要であり、トラフィックを傍受してユーザー情報を取得する余裕があるかどうかはまだわかりません。メール送信も今のところ実装が簡単です。後で、XML API を使用してミニダンプを送信します。