ブルー スクリーンの問題: クラッシュ ダンプや Web から手掛かりを見つける

前回のブログ記事では、ブルー スクリーンの色をカスタマイズする方法を紹介し、ブルー スクリーンの良い面に焦点を当てました。Windows のカーネル モード コードの信頼性は、リリースを重ねるたびに高くなり、悪名高い "死のブルー スクリーン" (BSOD) が表示されるという状況を経験したことがないユーザーは多数存在します。ですが、ブルー スクリーンが表示されてしまった方は (Notmyfault で意図的に引き起こした場合を除きます)、"Case of the Unexplained" (原因不明の...の問題) プレゼンテーションで説明しているように、調査に数分を費やせば、今後同じクラッシュが発生するのを防ぐことができ、不便さから解放され、データを失わずに済みます。この記事では、まず、クラッシュ ダンプの分析の基礎を確認します。多くの場合、この簡単な分析によって、Web で最新版が公開されている、問題のあるドライバーを特定できますが、この分析結果はあいまいなことが往々にしてあります。ここでは、複数の管理者から教えてもらった、適切なキーワードで Web 検索を行って解決策にたどり着くことができた 2 つの例を紹介します。

クラッシュをデバッグするときには、まず、Windows 用のデバッグ ツール (このツールは、Windows SDKに収録されていますが、SDK 全体をダウンロードしてインストールしなくても、デバッグ ツールだけ Web インストールすることが可能です) をダウンロードしてインストールし、Microsoft シンボル サーバーをポイントするように構成する必要があります。このように構成すると、デバッガーがダンプ情報を解釈するために必要な、カーネルのシンボルをデバッガーがダウンロードできるようになります。これには、[File] (ファイル) メニューの [Symbol File Path] (シンボル ファイルのパス) をクリックして [Symbol Search Path] (シンボルの検索パス) ダイアログ ボックスを開き、ダウンロードしたシンボル ファイルをデバッガーでキャッシュするシステム上のディレクトリ名と共に、シンボル サーバーの URL を入力します (下図参照)。

次は、[File] (ファイル) メニューの [Open Crash Dump] (クラッシュ ダンプを開く) をクリックして、クラッシュ ダンプをデバッガーに読み込みます。ダンプ ファイルが保存される場所は、実行している Windows のバージョンと、Windows がクライアントかサーバーかによって異なります。ですが、それとは関係なく、ダンプ ファイルの場所を知ることができる単純な経験則があります。まず、%SystemRoot% ディレクトリ (通常は C:\Windows) の Memory.dmp というファイルを確認します。ファイルが見つからない場合、%SystemRoot%\Minidumps ディレクトリを確認して、最新のミニダンプ ファイルを読み込みます (一番新しいクラッシュをデバッグすることを想定しています)。

デバッガーでは、ファイルを読み込むと、ヒューリスティックを使用してクラッシュの原因を突き止めようとします。デバッガーでは、ドライバー名、Windows コンポーネント、またはハードウェアの問題の種類が併記された "Probably caused by:" (問題の原因と思われるもの:) という文字列を出力して、原因として想定されるものを指摘します。クラッシュの原因となっている、問題のあるドライバーを適切に特定している例を次に示します。この場合は、myfault.sys が原因です。

プレゼンテーションでは、!analyze -v というハイパーリンクをクリックすると、クラッシュが発生したときに実行されていたスレッドのカーネル スタックなどの、詳細情報をダンプできることも紹介しました。この操作は、クラッシュの周辺でアクティブになっていることによって悪さをしている可能性がある、サードパーティ製のドライバーへの参照も確認できるので、ヒューリスティックで原因を見つけられなかった場合に便利なことがよくあります。多くの場合、この基本的な分析で特定したサードパーティ製のドライバーの新しいバージョンを確認すると、問題を解決できます。以前のブログ記事「The Case of the Crashed Phone Call (通話がクラッシュする問題、英語)」で、このパターンに当てはまるトラブルシューティングの事例を紹介しています。

手掛かりが何も見つからない場合は、(!analyze -v をクリックすると表示される) クラッシュ コード、問題と関係があると思われるコンピューターやソフトウェアを表すキーワードで Web を検索します。ここで 1 つ例を紹介したいと思います。ある管理者が、Citrix のサーバー ファームで断続的に発生するクラッシュに悩まされていました。彼は、"原因不明の...の問題" プレゼンテーションを聞くまで、クラッシュ ダンプ ファイルを確認できることにさえ気付いていませんでした。カンファレンスからオフィスに戻った彼は、影響を受けているいくつかのシステムのダンプ ファイルを開きました。ダンプを分析した結果、すべてのシステムで、次のように、リモート ユーザーのログオン (セッション) に関連するカーネル メモリをドライバーが必要なときに解放されていなかったという同じ一般的な結論にたどり着きました。

彼は、Web 検索でヒントが見つけられることを祈りながら、何も失うものはなかったので、ブラウザーの検索ボックスに「session_has_valid_pool_on_exit and citrix」と入力しました。驚いたことに、最初に表示された結果が、まさに彼が直面していた問題を解説している Citrix Knowledge Center のページでした。さらに、この記事では、彼が確認した出力と同じデバッガーの出力が示されていました (下図参照)。

修正プログラムをダウンロードしてインストールすると、サーバー ファームでクラッシュが発生することはなくなりました。

また、別の例では、管理者が数日間のうちにサーバーのクラッシュを 3 度も経験しました。残念ながら、ダンプを分析しても解決策に辿り着くことはできませんでした。分析結果からは、次のように、なんらかの内部のウォッチドッグ タイマーが制限時間内に実行されなかったことがクラッシュの原因であるとだけ示されているように思われました。

先ほどの事例のように、管理者が検索エンジンにクラッシュのテキストを入力すると、最初に表示されたページ (下図参照) で問題の解決策が示されていたので、彼は安心しました。

ページに記載されていた修正プログラムをインストールすると、それ以降、サーバーでクラッシュが発生しなくなりました。

これらの事例から、トラブルシューティングとは、解決策や回避策に導く手掛かりを探すことで、このような手掛かりは明白だったり、少し調査が必要だったり、創造力が必要だったりすることがわかりました。最終的に問題の解決策が見つかれば、手掛かりを見つけるのは、どんな方法でも、どんな場所でもかまいません。