0

基本的に、VMWare イメージ (Win764) でアプリケーションがフリーズしたため、タスク マネージャーを使用してアプリケーションのクラッシュ ダンプを作成しました。クラッシュダンプがうまく作成されました。次に、WinDbg を使用してクラッシュ ダンプを開き、すべてのスレッド、プロセス、およびコール スタックを確認できるようになったので、完全に機能するシンボルにリンクしました。コール スタック内の項目をクリックすると、WinDbg 内にウィンドウが開き、コール スタックのその部分のソース ファイル内の実際のコード行が表示されます。

今私の質問は、この方法でデバッグ中に WinDbg に表示される情報がどれほど正確/信頼できるかということです。アプリケーションがあったことを示す状態がまったく意味をなさない場合があるようです...不可能なシナリオや、100% 発生したことがないシナリオを示しているようです。たとえば、操作が開始されて完了したことを示していますが、正しく書き込まれたログ ファイルを確認すると、操作が発生していないことが示されています。それは決して起こらなかったことをログに記録し、その後正常に移動しました。また、操作の最終結果は、完了していれば、絶対に起こりませんでした。操作が実際に開始され、実行されたかどうかは明らかです。

何らかの方法で、クラッシュ ダンプが完全に間違っていたり、古い情報を示している可能性はありますか?

4

1 に答える 1

0

これまでに見たダンプはどれも、ダンプを取得した時点でのプロセスを正確に示していたという点で正しいものでした。ただし、覚えておくべきことがいくつかあります。

  • ダンプのバージョンと実際に一致する正しいソース コードを確認してください。私はよくそのような状況にありました: ソース コードの間違ったバージョンを見ているので、このような状況は決して起こらないだろうという印象を受けました。
  • アプリケーションが何か (スタックなど) を破損した場合、ダンプには破損したものだけが表示され、誤解を招く可能性があります。自分が見ているものが信頼できるかどうかは、自分で調べる必要があります。
  • アプリケーションがフリーズしているように見える場合でも、無限ループにあるため、スタックが変化している可能性があります。フリーズしたアプリケーションのダンプをいくつか取得して、変更点を確認します。
  • ログ出力は、(Hans Passant がすでに述べたように) いくつかの理由で最新ではない可能性があります: バッファがフラッシュされなかったか、アプリケーションがファイル名を上書きしてログ ファイルをクラッシュさせたり、ファイル ハンドルを破壊したりしたなどです。
于 2013-12-29T23:44:45.407 に答える