ブルースクリーンになったら。。。。（３） - お馬鹿牛

2017/06/20 (Tue) 18:37:18

すっかりサボっていたので、だぁ～れも覚えていませんが。。。前回からの続き。
(「お尻」の火は完全に鎮火してないけど、ちょっとだけ余裕が出てきたので。)

前回のは↓こっち。

------------------------
ブルースクリーンになったら。。。。（１）
http://ore-sama123.bbs.fc2.com/?act=reply&tid=5645029

ブルースクリーンになったら。。。。（２）
http://ore-sama123.bbs.fc2.com/?act=reply&tid=5646703
------------------------

今回は、ダンプ解析で使用するコマンドについてのお話です。
WinDBG の解析コマンドはいっぱいあります。
詳細な調査を行うためには、使うコマンドも解析対象となるダンプ (あるいはライブ デバッグ) の状態に依存して変化します。
例えば、ダンプが示すクラッシュ時のスレッドの状態がファイル システム関連で落ちているなら、"!fltkd" コマンドでファイル システム フィルタ マネージャ ドライバ (fltmgr.sys) の状態を確認したり、ネットワーク アダプタ関連処理で落ちていたら "!ndiskd" コマンドを使ったりと、ケース バイ ケースで実行すべきコマンドが変わってきます。
ただ詳細な調査を行うためにはその前段階として、ダンプがどのような状態を示しているのか、きちんと把握する必要があります。
つまり初期調査として毎回確実に使うコマンド。。。というのが、いくつかあります。
今回はそんな初歩的なコマンドを、いくつか紹介いたします。

☆ "!analyze -v"
WinDBG のダンプ解析で、もっとも有名なコマンド。
このコマンドは、WinDBG が対象のダンプ ファイルを自動解析した結果を表示してくれます。
「自動解析」してくれるなんて、すごいと思いませんか？
そもそも「自動解析」してくれんなら、他の解析コマンドなんて覚える必要なくね？
つまりは、そんな精度の「自動解析」をしてくれるコマンドです。ｗｗｗ
ダンプ ファイルには、ブルースクリーンの直接的な原因になった STOP コード (Bug Check Code) と、それに付随するパラメータ情報が記録されています。
この Bug Check Code とパラメータ情報は、あくまでも「直接的な原因」を示すもので、それがブルースクリーンの「根本原因」とは限らないのです。
(これがダンプ解析を「難しい」と感じさせる要因なのですが。。。)
"!analyze -v" コマンドは、そんな Bug Check Code とパラメータ情報を教えてくれるのです。
ダンプ ファイル内の Bug Check Code を確認するツールとしては、"BlueScreenView" なんかが有名ですが、あれよりかははるかに有用な情報を教えてくれます。
という訳で、WnDBG でダンプ ファイルを開いたら、とりあえず真っ先に確認すべきが、このコマンドになります。

☆ "!thread"
このコマンドは、現在のカレント スレッドの状態を表示してくれます。
WinDBG でダンプ ファイルを開いた直後では、スレッド コンテキストはブルースクリーン発生の原因となった処理を行っているスレッドになっているので、その詳細情報を確認することができます。
例えば、どのプロセスで落ちたのかとか、どのような処理をしていたのかとか、他のスレッドと通信をしていたのかとか、カーネル スタックは枯渇していなかったのかとか、色んな情報が出てきます。
このコマンドの出力結果に応じて、以降どこを重点的に調査していくのか、決めるわけです。

☆ "kvn"
上記 "!thread" の出力のうち、"コール スタック" と呼ばれる情報について、さらに詳しい情報を表示してくれます。
一般の方に "コール スタック" を説明するのは難しいのですが、自分でプログラムを書いたことのある人、特に自分で書いたプログラムをデバッグしたことがある人なら、なんとなくご理解していただけるのでは。。。と思います。
ダンプ解析ではこの "コール スタック" 情報から、どのような処理を行っていたのかの「雰囲気」をつかむことが、とても重要になります。
一般の方でも、この "コール スタック" が示す「雰囲気」をつかめるようになれば、自力でブルースクリーン問題を解決できるケースが格段に多くなるはずです。

☆ "!process 0 0"
ダンプを生成した PC 上で動作していた、すべてのプロセスを表示してくれます。
(ただし "Idle Process" は除く。)
このコマンドは「完全メモリ ダンプ」の解析以外はほとんど意味を持ちませんが、例えばハング系の問題で「意図的に」システム クラッシュさせて調査を行う場合などには、必ず使用します。
どのプロセスが CPU リソースを消費しているのか。。。なんていうのも、このコマンドで概要がつかめます。

☆ "!process 0 17"
ダンプを生成した PC 上で動作していた、すべてのプロセスのすべてのスレッドを表示してくれます。
(ただし "Idle Process" は除く。)
このコマンドも「完全メモリ ダンプ」の解析以外はほとんど意味を持ちませんが、上記コマンドと同様に、ハング系の問題で活躍します。
ただし、このコマンドはとても時間がかかります。
(1時間、2時間はざら。。。)
なので、お家に帰る前とか、寝る前とか、ダンプ解析を「しない」時に、あらかじめ実行させておきます。
時間はかかるけど、採取しておくと後々役に立つのが、このコマンドです。

。。。。というわけで、今回も非常なダラダラな説明になってしまいましたが、もし読んでくれた方がいらっしゃいましたら御礼申し上げます。
次回は。。。"!analyze -v" コマンドがあまり役に立たない理由につて、説明しようと思っています。