Windows Serverのブルースクリーン「CRITICAL_PROCESS_DIED」から復旧する実践手順：Hiren’s BootCD PEと“Server向け”ツールで直す考え方

Windows Serverで突然ブルースクリーンが出て「Stop Code: CRITICAL_PROCESS_DIED」と表示されたとき、多くの人が真っ先に試すのは sfc や dism、chkdsk です。ところが、原因が“サーバー特有の領域”に踏み込んでしまったケースでは、それらがほとんど効かないことがあります。特に、Domain Controller（DC）に対して一般的なパスワードリセットを行った直後に発生するCRITICAL_PROCESS_DIEDは、直し方の発想を変えないと長期戦になりがちです。

• Windows Serverのブルースクリーン「CRITICAL_PROCESS_DIED」から復旧する実践手順：Hiren’s BootCD PEと“Server向け”ツールで直す考え方
  • CRITICAL_PROCESS_DIEDとは何が起きているのか
  • 典型的な落とし穴：DCに「一般向けパスワードリセット」を当てる
  • sfc / dism / chkdsk が効かない理由
  • 発想の転換：Hiren’s PEは「起動ディスク」ではなく「動くWindows」
  • 実践手順：Hiren’s環境でServer向け修復ツールを導入して直す
    • 1) Hiren’s PEでネットワークを有効化する
    • 2) Server向けの復旧ツールを入手する
    • 3) Hiren’sのRAMドライブ（例：X:）へダウンロードして実行
    • 4) 「ブート修復（Boot Repair）」系の機能を最優先で実行
    • 5) 起動確認後、恒久対応（再発防止）へ
  • 予防策：Domain Controllerでやってはいけないこと・代替案
  • まとめ：復旧の鍵は「ServerをServerとして扱う」こと

CRITICAL_PROCESS_DIEDとは何が起きているのか

「CRITICAL_PROCESS_DIED」は、Windowsの起動に不可欠なプロセスが異常終了したときに発生する停止コードです。単純なファイル破損だけでなく、起動構成・レジストリ・ドライバ・認証周りの整合性が崩れた場合にも起こり得ます。
そしてWindows Server、とりわけDomain Controllerは“ローカルPCとは前提が違う”ため、一般向けの復旧手順をそのまま当てると逆効果になることがあります。

典型的な落とし穴：DCに「一般向けパスワードリセット」を当てる

Hiren’s BootCD PEのようなレスキュー環境には、オフラインで管理者パスワードを変更・リセットできるツールが多数あります。デスクトップOSのローカルアカウント相手なら便利ですが、Domain Controllerに対して安易に適用すると、次のような問題が起きやすくなります。

• DCはActive Directoryのデータベース（NTDS.dit）を含む複数の要素が整合した状態で起動する前提

• “ローカル前提の書き換え”を行うと、サーバー起動時に必要な認証・サービス・ブート関連の期待値が崩れる

• 結果として、Windowsロゴが一瞬出た後にCRITICAL_PROCESS_DIEDで落ちる、といった症状につながる

要するに「ローカル用の道具でDCの中身を触る」のが危険、ということです。

sfc / dism / chkdsk が効かない理由

以下は定番の修復コマンドです。

• sfc /scannow

• dism /online /cleanup-image /restorehealth

• chkdsk /f

これらは主に「システムファイルの破損」や「コンポーネントストアの修復」、「ディスク不良・ファイルシステム不整合」の改善に強い一方で、今回のようにブート構成やレジストリ、サーバー固有の起動パラメータが壊れているタイプには刺さりません。
“壊れた場所が違う”のに“得意分野の修復”を続けてしまうのが、復旧が長引く原因になります。

発想の転換：Hiren’s PEは「起動ディスク」ではなく「動くWindows」

ここで大事なのが、Hiren’s BootCD PEの正体です。これは単なるツール集ではなく、Windows PEベースの軽量OSです。つまり、起動さえできているなら——

• ネットワークを有効化できる

• ブラウザを使える

• 必要なツールを追加で入れられる（実行できる）

という“現地作業用のWindows”として扱えます。プリインストールの道具が目的に合わないなら、目的に合う道具をその場で持ち込めばいい、という考え方に切り替えます。

実践手順：Hiren’s環境でServer向け修復ツールを導入して直す

ここからは、考え方と手順をできるだけ再現しやすい形でまとめます。ポイントは「Server（特にDC）を想定した修復機能」を使うことです。

1) Hiren’s PEでネットワークを有効化する

• NICドライバを認識させ、ネットワークが使える状態にします

• 可能なら有線LANが安定です

• オフラインで進めたい場合でも、少なくともツール入手のために一時的に接続する価値があります

2) Server向けの復旧ツールを入手する

一般向けではなく、Windows ServerやDCを想定したエディション／機能を持つツールを選びます。記事のケースでは「Server Edition」が存在し、ブート修復の“Quick Fix”のような機能が有効でした。
重要なのは製品名そのものよりも、「Serverのブートや役割を理解した修復ロジックがあるか」です。

3) Hiren’sのRAMドライブ（例：X:）へダウンロードして実行

Hiren’s PEでは作業領域がRAMドライブ（しばしば X:）になっていることがあります。そこに実行ファイルを置いて起動します。
ここで驚きがちなのですが、PE環境でも動くインストーラやポータブル実行ができるツールは少なくありません。

4) 「ブート修復（Boot Repair）」系の機能を最優先で実行

DCでの一般的なパスワードツール適用後に落ちた場合、まず疑うべきは起動周りの破損・不整合です。
Server向けツールの「Quick Fix」「Boot Repair」といった機能は、起動パラメータやブート構成の前提をサーバー寄りに解釈して修復してくれるため、一般ツールより成功率が上がります。

5) 起動確認後、恒久対応（再発防止）へ

復旧してログオンできたら終わりではありません。DCの場合は特に、復旧直後に最低限の健全性チェックを行うのが安全です。

• AD関連サービスが正常に起動しているか

• イベントログに重大エラーが残っていないか

• パスワード変更・アカウント操作の手順が正しかったか

• そもそも「DCのローカル管理者をオフラインでいじる」必要があったのか

この段階でバックアップ戦略や復旧手順（DR手順）も見直すと、同じ事故を繰り返しにくくなります。

予防策：Domain Controllerでやってはいけないこと・代替案

今回の本質は「目的に合わない道具を使った」ことです。再発防止の観点で、DC運用では次を強く意識してください。

• DCに対して、クライアントOS前提の“オフラインパスワードリセット”を安易に実施しない

• 変更が必要なら、可能な限り正規の管理経路（適切な権限・適切な手順）で行う

• どうしても復旧環境が必要なら、Server対応を明記したツールを準備しておく

• 事前に「復旧USBに何を入れておくべきか」を標準化する（ネットワーク、ドライバ、Server向け修復ツールなど）

まとめ：復旧の鍵は「ServerをServerとして扱う」こと

CRITICAL_PROCESS_DIEDは一見すると“ありがちなブルースクリーン”ですが、Domain Controllerが絡むと意味合いが変わります。sfc や dism が効かない状況は珍しくなく、一般向けのパスワードツールが引き金になることもあります。
解決への近道は、Hiren’s PEを「ただの起動ディスク」ではなく「必要な道具を追加できる作業用Windows」と捉え、Server向けの修復ツールでブートを正しく直すこと。これができると、行き止まりに見える復旧が一気に進みます。