先日仕事をしていたら突然 PC が固まりました。
ハングしているだけかと思ってしばらく待っていたらしばらくしてこんな画面になりました。
あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛
ブルー スクリーン (以下 BSoD) でした＼(^o^)／
いつものことなら待っていれば再起動するだろうと思っていたのですが……
なんと起動せずでした。
再実行のために [Enter]、回復環境に入るために [F1] を押下してもすぐにこの画面に戻ってきてしまいます。
この問題に対処したときの方法を備忘録として記載します。
- > まず最初に BSoD のときの [停止コード] を見よう
- > Microsoft の公開情報を確認しよう
- > 要因を考えてみる
- > 推定した要因について確認をしてみる
- > SSD の抜き差しで OS は起動した
- > DISM コマンドと sfc /scannow でシステム イメージの修復を行う
- > 修復結果
- > 原因調査をしてみよう
- > 一連の対処のまとめ
- > 結論 : ダンプ ログが無いから原因はわからないけど対処はできた
> まず最初に BSoD のときの [停止コード] を見よう
最初にやるべきことは、なぜ OS がクラッシュしたかを見極めることです。
今回の私の環境で起きた BSoD の停止コードを見てみましょう。
Critical Process Died
見るからにヤバそうなエラーですね……
> Microsoft の公開情報を確認しよう
とりあえず情報収集をしてみましょう。
情報収集は可能な限り公式サイトが望ましいので Microsoft のサイトで何か載っていないかを確認します。
原因のところを見てみましょう。
CRITICAL_PROCESS_DIED のバグチェックの値は、0x000000EF です。 これは、重要なシステムプロセスが停止したことを示します。 重要なプロセスは、システムが終了するかどうかをバグチェックに強制するプロセスです。 これは、プロセスの状態が破損している場合、または破損している場合に発生する可能性があります。 この場合、これらのプロセスが Windows の操作にとって重要であるため、オペレーティングシステムの整合性に問題があると、システムのバグチェックが行われます。
これは……起動しなくなったことを考えると結構ヤバそうな感じです。
対処方法を見てみるとハードウェアを交換したら戻してみるとか、ウイルス ソフトがマスタブートレコードを確認していないか、といった確認項目がありますね。
> 要因を考えてみる
先程の公開情報から、いくつか考察できそうなことがありましたので、ここで列挙してみます。
この時点では当てずっぽうでも予測でも大丈夫です。
どういうところをチェックできそうかを考えてみるという工程になります。
- ハードウェア (SSD) が壊れた
- ウイルスソフトがマスタブートレコードなどの重要なファイルにアクセスしていて、ほかの機能がアクセスできなくて異常終了した
- そもそも大事なファイルが壊れた
このうちまともに再帰できそうなのは 2 と 3 ですね。
でも 3 も場合によっては OS のクリーン インストールが必要になりそうな予感がします。
> 推定した要因について確認をしてみる
当然ですが、OS は SSD などの記憶媒体に入ったデータです。
起動障害をゼロからやる場合、私個人の見解としては低レイヤーから確認していく方がよいと思っています。(人によって諸説あり)
低レイヤーというのはシステムの動作において最も下にあるもの、つまりハードウェアのことです。
正常なハードウェア上で OS が稼働するので、ハードウェアがダメなら OS もちゃんと動くわけないよね、という考えです。
それではまずは uEFI から SSD の認識状態を確認しましょう。
私は以下のマザー ボードを使っているのですが、このボードの uEFI は視覚的に各スロットに何が搭載されているかを確認できる便利な機能があります。
確認した結果がこちらです。
真ん中の網掛けのところに C ドライブとして使う SSD を挿しています。
M.2_1 Connector : Empty なので存在しているはずの SSD を認識していません。
ということで今回の問題は、まずはハードウェアがダメ (SSD が認識されていない) ということがわかりました。
> SSD の抜き差しで OS は起動した
完全に SSD が壊れていそうな気もしますが、接触不良という可能性もあります。
なのでまずは PC を分解して SSD の抜き差しを行うことにしました。
結果として OS は無事に起動しました。
よかったよかった。
とはまだいきません。
Critical Process Died の原因はハードウェア的な問題か、OS の大事なファイルが破損しているか、でした。
もし OS の大事なファイルが壊れていて、今は偶然アクセスしていないけど、破損したファイルが必要になったらまた BSoD になるということです。
念には念をということで、ファイル破損の確認もしていきましょう。
> DISM コマンドと sfc /scannow でシステム イメージの修復を行う
システム ファイルの修復を行うコマンドの代表には DISM コマンドと sfc /scannow があります。
どちらも似たようなコマンドですが、実は実行する順番があります。
必ず DISM -> sfc の順番で実行するようにしましょう。理由は後述します。
その前に、各コマンドの役割を説明します。
DISM コマンド
Dism /Online /Cleanup-Image /ScanHealth
これはシステム イメージが破損していないかどうかを確認するコマンドです。
確認するだけで修復は行いません。
用途としては、修復のような時間がかかりそうな作業は後回しにしたいときなど、サッと破損状況を確認したいときに使います。Dism /Online /Cleanup-Image /RestoreHealth
これは上記の /ScanHealth と異なって、修復まで行ってくれます。
システム イメージが破損していた場合は Windows Update から情報を入手して修復を行います。
sfc /scannow
破損のチェックを行うところまでは同じなのですが、こちらのコマンドはローカルのキャッシュ ファイルの情報を参照して修復を行います。
つまり、もともとローカルのファイルが破損していたらキャッシュ ファイルの情報も破損しているので修復をかけても意味がないということになります。
先に DISM コマンドで Windows Update からちゃんとした情報を取ってきて、そのあとにローカルで修復を行う、という流れを意識しましょう。
> 修復結果
私は今回はまず先に Dism /Online /Cleanup-Image /ScanHealth を使いました。
結果は問題なしでした。
続いてこの状態で sfc /scannow を実行します。
何か修復されましたね。
やはりシステム イメージが何か破損していたようです。
とりあえず現時点はこれで対処は完了です。
> 原因調査をしてみよう
BSoD のときはダンプ ファイルが作成されます。
デフォルトでは %SystemRoot% 配下に MEMORY.DMP という名前で作成されますので、これを WinDbg を使って解析します。
そのはずなのですが、今回は MEMORY.DMP が存在しませんでした。
なんとその理由はシステム イベントに記録されていました。
…………( ゜Д ゜;)
> 一連の対処のまとめ
今回の起動障害は以下の流れで対処しました。
- 停止コードが意味する内容を確認する
- 原因を予想する
- ハードウェアに問題ないかを確認する
- SSD の抜き差し
- Dism /Online /Cleanup-Image /ScanHealth を実行
- sfc /scannow を実行
> 結論 : ダンプ ログが無いから原因はわからないけど対処はできた
とても不完全燃焼な感じですが、ダンプ ログが無いのでこれ以上原因を追うことはできません。
SSD の認識がなかったというハードウェア的な問題は気になりますが、OS としては sfc /scannow でシステム破損を復旧したのでとりあえずの対処は完了しています。
もし再発するなら疑うべきはハードウェアになります。
そうなると SSD の買い替えを視野に入れなければなりません。
2 TB の NVMe SSD、結構高かったのでもう少し長持ちしてくれることを祈るばかりです。
そして今回の対処をして思ったのですが。
sfc /scannow って本当にシステム破損直せるんですね。うまくいったの初めて見た気がします
