debugging - コール スタックが null である Visual Studio でのミニダンプのデバッグ

Question

Visual Studio 2005 でコンパイルしたプログラムでは再現できない、100% 再現可能なクラッシュが発生している顧客がいます。プログラムのデバッグ ビルドを送り、すべての PDB ファイルと DLL ファイルを手元に置いておきました。ミニダンプ ファイルが送られてきましたが、開くと次のようになります。

「MiniDump.dmp の 0x00000000 で未処理の例外: 0xC0000005: アクセス違反の読み取り場所 0x00000000」。

次に、コール スタックに「0x00000000()」のみが表示され、逆アセンブリによって 0x0 のメモリのダンプが表示されます。シンボル サーバーをセットアップし、PDB シンボルをロードしました。しかし、多くの DLL のどれが実際に null へのジャンプを引き起こしたのかを知る方法がわかりません。これは多くの依存関係を持つ大規模なプロジェクトであり、サードパーティとして API を使用しているため、それらの一部はソースまたは PDB を持っていないバイナリです。

では、このミニダンプは一体どのように役立つのでしょうか? クラッシュの原因となった DLL を確認するにはどうすればよいですか? これまでデバッグにミニダンプを実際に使用したことはありませんが、私が読んだすべてのチュートリアルには、少なくとも関数名またはコール スタックの手がかりを与える何かが表示されているようです。nullを指す1行だけを取得します。

また、「依存」を使用して、未解決の DLL 依存関係があるかどうかを確認してみました。ただし、さまざまな Windows OS を搭載した 3 台のテスト マシンでは、OS DLL 依存関係の 3 つの異なるセットを取得しているようです (それでもクラッシュを再現できません)。したがって、これは問題を診断するための特に信頼できる方法ではないようです。

この問題の原因を特定するには、他にどのような方法がありますか? どの DLL が null にジャンプしたかを確認するために 1 つの命令を戻す方法はありますか?

Answer 1

この場合の答えは、「ミニダンプのデバッグには Visual Studio の代わりに WinDbg を使用する」だったようです。VS から有用な情報を得ることができませんでしたが、WinDbg は、クラッシュの原因となった一連の関数呼び出しに関する豊富な情報を提供してくれました。

この例では、すべての機能が私が使用しているサードパーティのライブラリにあったため、問題の解決にはまだ役立ちませんでした。そのため、特定の問題に対する唯一の決定的な答えは、ログファイルを使用して状態を追跡することです。クラッシュにつながる私のアプリケーション。

ミニダンプをデバッグするときに役に立たないコール スタックで同様の問題が発生した場合は、Visual Studio ではなく WinDgb で開くことをお勧めします。この仕事に最適なツールが、市販の製品ではなく無料の Microsoft 製品であるというのは奇妙に思えます。

ここでのもう 1 つの教訓は、おそらく「サード パーティのライブラリを使用するプログラムは、ログ ファイルを書き込む必要がある」ということです。

Answer 2

事後分析デバッグのすべての「単純な」方法の背後にある全体的な考え方は、スタック トレースのキャプチャです。アプリケーションがスタックを上書きする場合、そのような分析を行う方法はありません。専用ハードウェアでプログラムの実行全体を記録する非常に洗練された方法のみが役立ちます。

そのような場合の方法は、ログ ファイルです。いくつかのログ ステートメントを、障害が発生したエリア全体に広げて、そのバージョンを顧客に送信します。クラッシュの後、ログ ファイルに最後のログ ステートメントが表示されます。その時点と、ログ ファイルに記録されていない次のログ ステートメントの間にさらにログ ステートメントを追加し、そのバージョンを再度出荷します。問題の原因となっている行が見つかるまで繰り返します。

これについては、ddj.com で 2 部構成の記事を書きました。

ログファイルについてパート1

ログファイルについてパート2

Answer 3

単なる観察ですが、スタックが切り捨てられたり上書きされたりしています。これは、初期化されていないフィールドを使用する単純なケースでしょうか、それともバッファオーバーランでしょうか。

それを見つけるのはかなり簡単かもしれません。

Answer 4

既にご存じかもしれませんが、ミニダンプのデバッグに関するいくつかのポイントを次に示します。 1. ミニダンプが作成されたクライアント コンピューターとまったく同じ実行可能ファイルと PDB ファイルが必要であり、それらはまったく同じディレクトリに配置する必要があります。同じバージョンを再構築するだけでは役に立ちません。2. デバッガーが MS Symbols サーバーに接続されている必要があります。3. デバッガーが起動すると、出力ウィンドウにプロセス読み込みログが出力されます。通常、すべてのライブラリはデバッグ情報とともに正常にロードされます。デバッグ情報のないライブラリもロードされますが、「no debug info」が出力されます。このログを学んでください - それはあなたにいくつかの情報を与えることができます.

実行可能スタックにデバッグ情報のないライブラリからのフレームが含まれている場合、表示されないことがあります。これは、たとえば、コードがサードパーティ ライブラリのコールバックとして実行されている場合に発生します。

未処理の例外を作成するコードを追加して、自分のコンピューターにミニダンプを作成し、すぐにデバッグしてみてください。これは機能しますか？成功したデバッグ セッションと失敗したデバッグ セッションの読み込みログを比較します。

Answer 5

顧客のコンピューターに WinDbg を設定し、それをクラッシュの原因となるアプリケーションの既定のデバッガーとして使用しようとしましたか? アプリケーションが存在するフォルダーに pdb ファイルを追加するだけです。クラッシュが発生すると WinDbg が起動し、コール スタックの取得を試みることができます。