実際、問題はクラッシュ レポートを機能させることではありません。これは、DbgHelp ライブラリ関数を使用する場合は些細なことであり、最も顕著に現れますMiniDumpWriteDump
。ただし、古いシステムで DbgHelp ライブラリを再配布し、呼び出す関数のバージョン要件を確認することを忘れないでください。新しいバージョンの Windows には、少なくともこのライブラリのいくつかのバージョンが付属しています。
MS 以外のコンパイラを使用する際の問題 (問題は Embarcadero、以前の Borland、製品、または Watcom にも存在します) は、作成されたデバッグ シンボルが、デバッグの標準機能である DbgHelp ライブラリに対して意味をなさないことです。 Windows で。PDB 形式は大部分が文書化されておらず (いくつかの手がかりについては、 Sven Schreiber PDBという用語を検索してください)、それらを作成するために使用されるライブラリは、DbgHelp ライブラリと同じ意味で「パブリック」ではありません - 後者は読み取り/解析にのみ使用できます作成されたデバッグ シンボル。これらは Visual Studio 製品の一部であり、通常は mspdbXY.dll (XY は 10 進数) のような名前が付いています。
したがって、バグ レポートを作成する場合は、「コンパイラの問題」に集中するのではなく、デバッガの問題に集中することを強くお勧めします。一般的な方向は次のとおりです。
- 特定のデバッグ形式を理解するデバッガーを使用します (MinGW、IIRC の DWARF 用 GDB)。
- 複数のフォーマットを理解するデバッガーを使用してください (IDA が頭に浮かび、他の利点もあります ;))
- デバッグ シンボル (DWARF) またはより一般的
.map
なファイルを理解するために、WinDbg などに拡張機能を記述します (このような拡張機能は、数年前に Borland.map
ファイル用に作成されたことを認識しています) 。
- アセンブリ言語を学び、利用可能なツール (WinDbg またはより一般的には DbgHelp ライブラリ)をシンボルなしで使用します (おそらく、既に理解していない限り、学習曲線が急すぎるでしょう)。
4 の拡張機能として、.S
コンパイル中に GCC に (アセンブリ) ファイルを作成させて、シンボル サポートなしで作業しているときにソース コードとクラッシュ ダンプを相互参照することもできます。
私は unixoid プラットフォームでは GDB を好みますが、Windows では WinDbg やその他のデバッガーを好むため、MiniDumpWriteDump
Windows の GDB で実際のクラッシュ ダンプ形式 (で作成)がサポートされているかどうかはわかりません。この場合、GDB によって期待されます。
ところで: Windows XP 以降を使用していて、その事実を信頼できる場合は、AddVectoredExceptionHandler
代わりに使用SetUnhandledExceptionFilter
して、クラッシュ ダンプの書き込みを準備してください。