アプリケーション内で、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 サーバーからデバッグ シンボルのロードを正しく開始します。