最終更新日付： 2019年8月18日
Windowsサーバーを運用していると、突然のブルースクリーンに見舞われることがあります。
ブルースクリーンになると、メモリダンプという原因のヒントになるエラーになったメモリ状態をまるまる出力をしてくれますが、インフラSEにはWindowsの中の何が原因なのか追及が難しくお手上げになってしまいます。
しかし、意外と簡単にメモリダンプを解析して、切り分けや原因のヒントをつかむことが出来ます。
レジュメ
環境・前提条件
- Windows Server 2016
- メモリダンプはカーネルメモリダンプ
で、停止コード：BAD POOL HEADERというブルースクリーンが発生してOSがハングして停止してしまいました。
サーバーで出力されたメモリダンプ「C:\Windows\memory.dmp」をクライアントのWindows10上で解析してみました。
結論、マイクロソフト純正フリーソフトWinDbgでメモリダンプから原因の切り分けが出来る
クラッシュしたWindows Server OSのメモリダンプを解析し、原因の切り分けが出来ると、インフラSEとして一皮むけたプロになった気になれます＾＾
実際に、メモリダンプの解析をWinDbgを使ってやってみましょう。
WinDbgのインストール
メモリダンプを解析するフリーソフト「Windows 10 SDK」を Windows10にインストールしましょう。
「WinDbg」（＝Debugging Tools for Windows）は、「Windows 10 SDK」のコンポーネントの一つとしてインストールできます。
参考：Debugging Tools for Windows のダウンロード - WinDbg - Windows drivers | Microsoft Docs
メモリダンプを解析するシンボルの設定
WinDbgをインストールしたら、メモリダンプを解析するためのシンボルファイルを設定しましょう。
シンボルファイルは、メモリダンプを解析するために必要なものです。
参考：メモリダンプに !analyze -v するまで・後編 ~ ダンプを開く~ – Japan WDK Support Blog
「File」メニューから「Symbol File Path」をクリックし、上記のように記載し「OK」ボタンを押します。
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
そうしたら、いよいよメモリダンプ解析です。
いざ、メモリダンプの解析！クラッシュダンプの中身を覗く
「File」メニューから「Open Crash Dump」をクリックし、Windowsサーバーから持ってきたメモリダンプファイルを開きます。
青文字リンクの「!analyze -v」をクリックし解析スタート
メモリダンプはファイルサイズも大きいですし解析には少し時間がかかります。
「!analyze -v」をクリックして、より詳細を見ていきます。
青文字のリンクをクリックしていくと、今回のメモリダンプの原因について切り分けが出来ます。
今回「BAD POOL HEADER」のブルースクリーンの原因になったのは、mfehidk.sysということがわかりました（マカフィー）。
ブルースクリーンと言う不明確なストップエラーでも、ここまでわかれば次のアクションプランが取れますね！
実際のところはハードの老朽化が原因だったり、ホコリが基板上でショートさせてたりするけど
それがあかんってところは結局ログみてもわかんないというところですねー問題は。
>winmaniaさん
返信が遅くなり失礼しました。
その通りですね、、、CPUやメモリや基盤といった場合は、ブルースクリーンにもならないケースがありますね。
ブルースクリーン画面は、ダンプ ファイル生成中に電源を落とさないようユーザに注意喚起するために表示しています。
つまりダンプ ファイルを生成できない場合は、ブルースクリーン画面を表示せず、いきなり PC を再起動させます。
ブルースクリーン画面が表示されない代表的な例としては、OC 設定による熱暴走やストレージの故障。
そもそもブルースクリーン発生原因のほとんどは、ソフトウェア起因によるもの。
ホコリでブルースクリーンなんていうのは、ブルースクリーンの発生メカニズムを理解していない連中が作り出した都市伝説。
ハードウェア起因によるブルースクリーンの場合でも、複数のダンプ ファイルを採取しそれらを解析すれば、それなりに原因が見えてきます。
＞John Smithさん
はい、そうですね。
どちらかというと、ソフトウェア問題が大半です。
ソフトウェアと行っても、OSレイヤに入り込むようなデバイスドライバ周りの問題がほとんどです。
デバイスレイヤが問題か、ハードウェアが問題か、というと切って切り離せない部分があるので、ハードウェア問題のケースも時々ありますね（ファームウェアも含む）。
ダンプファイルから原因の特定らしきものがつかめるようになると、プロっぽさを感じますね笑。
> ソフトウェアと行っても、
> OSレイヤに入り込むようなデバイスドライバ周りの問題がほとんどです。
「OSレイヤに入り込むようなデバイスドライバ周り」という認識は、すこしズレていると思います。
ブルースクリーンは、NT カーネルがカーネル モード空間内での異常を検出したときに起きる現象です。
ユーザ モード空間でのエラーで起きるのがアプリケーション クラッシュ (AppCrash) に対して、カーネル モード空間でのエラーで起きるのがシステム クラッシュ (ブルースクリーン) です。
デバイスドライバに限らず、ファイル システムやネットワーク プロトコル等、カーネル モード空間内での処理でリカバリー不能なエラーを NT カーネル (ntoskrnl.exe) が検出したときに、システム クラッシュが発生します。
そもそもハードウェア起因によるシステム クラッシュの方が、ダンプ解析で原因を特定しやすいです。
「ブルースクリーン ＝ ハードウェアの問題」といういい加減な情報が多すぎるから、出来の悪いソフトウェアが一向に減らないのです。
(大体 “!analyze -v” コマンドだけで原因特定できるケースなんて、ほとんどありません。)
>John Smithさん
詳しいですね。
「OSレイヤに入り込むようなデバイスドライバ周り」＝カーネルモード
を指していました。