Windows 10 IoT LTSC 2021 で「システムの復元」を実行した直後に CRITICAL_PROCESS_DIED のブルースクリーンが出て起動できなくなると、現場は一気に止まってしまいます。本記事では、WinRE を使った基本的な復旧手順から IoT 特有の UWF 対応、最終的なインプレース修復まで、実運用を想定した具体的な復旧フローを整理します。
システムの復元後に CRITICAL_PROCESS_DIED が発生する典型パターン
今回のケースは、次のような状況を想定しています。
- OS：Windows 10 IoT Enterprise LTSC 2021（バージョン 21H2／ビルド 19044.6126）
- 操作：通常起動中に「システムの復元」を実行し、復元ポイントへロールバックした
- 結果：再起動後、Windows ロゴ表示直後にブルースクリーン（BSOD）で停止し、エラーコードが CRITICAL_PROCESS_DIED になる
- 自動修復もループし、通常起動までたどり着けない
Windows 10 IoT LTSC は、KIOSK や産業機器など「止められない装置」で使われることが多く、この状態になると現場対応がシビアになります。そのため、できるだけ OS を再展開せずに復旧することが重要です。
CRITICAL_PROCESS_DIED（BugCheck 0xEF）とは何か
CRITICAL_PROCESS_DIED（バグチェックコード 0xEF） は、起動に必須なプロセスが異常終了したときに発生するブルースクリーンです。具体的には、次のようなプロセスが正常に動けない場合に発生します。
| 代表的なプロセス | 役割 | 停止した場合の影響 |
|---|---|---|
smss.exe | セッションマネージャー。ユーザーセッションの初期化 | Windows ロゴの後に進まない、ログオン画面が出ない |
wininit.exe | サービスや Win32 サブシステムの起動 | サービス起動前に BSOD、ループ状態になりやすい |
services.exe | サービス制御マネージャー | サービスの読み込み途中で BSOD |
csrss.exe | クライアント／サーバーランタイム | ユーザー環境が構成されず即 BSOD |
これらのプロセスは OS のごく初期段階で起動するため、ドライバーやレジストリ、システムファイルの不整合があると、ログオン画面が出る前のタイミングで CRITICAL_PROCESS_DIED が起きやすくなります。
システムの復元直後に起きる主な原因整理
システムの復元実行後に CRITICAL_PROCESS_DIED が発生する場合、原因はある程度絞り込めます。代表的なものを一覧にすると次の通りです。
| 症状・状況 | 想定される原因 | 確認・対処のポイント |
|---|---|---|
| 復元直後から BSOD が毎回発生 | 復元ポイントのファイル／レジストリが現在の状態と噛み合っていない | 「復元の取り消し」または別の復元ポイントでやり直す |
| 特定のドライバー更新の後に復元を実行 | ドライバーのバージョン不整合や署名の問題 | セーフモードで問題ドライバーをアンインストール／無効化 |
| IoT デバイスで UWF（書き込みフィルター）を使用 | 復元時の書き込みが保護され、復元が中途半端な状態で終了 | UWF を一時的に無効化してから復元を行う／オフラインで SFC・DISM を実施 |
| 突然の電源断やストレージ障害の前歴あり | ストレージ不良や MFT 破損 | chkdsk によるディスクチェック、SMART 情報の確認 |
| ミニダンプが生成されていない | ページファイル無効、UWF で書き込みが保持されない | 起動できたらページファイル構成と UWF 設定を見直す |
以降では、復旧のしやすさと現場インパクトを考慮し、「簡易復旧」→「オフライン修復」→「セーフモードでの切り分け」→「最終手段」 の順に手順を紹介します。
まず試す簡易復旧：WinRE（Windows 回復環境）からの操作
ブルースクリーンループになっている状態でも、多くの場合は Windows 回復環境（WinRE）には入れます。標準的には以下のいずれかで WinRE を起動します。
- Windows ロゴが出たら電源ボタン長押しで強制終了、これを 2～3回繰り返す
- インストールメディア（USB/DVD）から起動し、「コンピューターを修復する」を選択
WinRE に入ったら、次の順番で簡易な復旧を試します。
スタートアップ修復を実行する
- 「トラブルシューティング」
- 「詳細オプション」
- 「スタートアップ修復」
- 対象の Windows 10 IoT を選択
スタートアップ修復は、ブートローダーや簡単なシステムファイル障害を自動的に修復してくれます。CRITICAL_PROCESS_DIED がごく初期の不整合によるものであれば、この段階で復旧することもあります。
システムの復元をやり直す（復元の取り消し／別ポイント）
復元処理そのものが不整合を生んでいる場合、復元の取り消し で元の状態に戻せる可能性があります。
- WinRE で「トラブルシューティング」 → 「詳細オプション」 → 「システムの復元」
- 「復元の取り消し」が表示されていれば選択し、ウィザードに従って進める
- 別の復元ポイントが利用可能な場合は、より新しい／古いポイントを選択し直して実行
特に、ドライバー更新直後の復元ポイント は不安定になることがあるため、少し前のポイントを選び直すのも有効です。
直近の更新プログラムをアンインストールする
品質更新プログラムと復元ポイントの組み合わせによって不整合が起きている場合、更新プログラムを削除すると改善することがあります。
- WinRE で「トラブルシューティング」 → 「詳細オプション」 → 「更新プログラムのアンインストール」
- 「最新の品質更新プログラムのアンインストール」を選択
- アンインストール完了後、再起動して挙動を確認
ここまでで復旧しない場合は、次のオフライン修復に進みます。
オフラインからの整合性修復（SFC・DISM・chkdsk）
ブルースクリーンループでオンライン起動ができない場合でも、WinRE のコマンドプロンプトからシステムファイルやコンポーネントストアの修復を行うことができます。
最重要：OS パーティションのドライブ文字を確認する
WinRE 上では、通常の起動時と OS のドライブ文字が異なる ことが非常によくあります。まずは次のコマンドで OS の場所を確認します。
bcdedit | find "osdevice"
例えば、次のような結果だとします。
osdevice partition=D:
この場合、以降のコマンドでは D: を OS ドライブとして扱います（慣れで C: のまま打たないよう注意）。
chkdsk でディスクとファイルシステムを検査する
まずはディスクの物理エラーや MFT の破損を洗い出します。
chkdsk D: /f /r
/f：ファイルシステムの論理的なエラーを修復/r：不良セクターの検出と、可能なデータの回復
ストレージ容量や状態によっては、完走までかなり時間がかかります。不良セクターが大量に検出される場合は、OS 修復だけでなくストレージ交換も検討すべきです。
SFC（オフライン）でシステムファイルを検査・修復する
次に、システムファイルの整合性を検査します。オフライン環境のため、/offbootdir と /offwindir を指定します。
sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows
ここで OS ドライブが C: と決めつけてしまうと、別のパーティションに対して SFC をかけることになり、いつまでも「問題なし」と表示されてしまいます。必ず bcdedit の結果を反映してください。
DISM で保留中の操作を取り消す
システムの復元や更新プログラムの適用が中途半端な状態で止まっていると、起動時に毎回失敗処理が走り、結果として必須プロセスの起動に失敗することがあります。この場合は DISM の /RevertPendingActions が有効です。
dism /Image=D:\ /Cleanup-Image /RevertPendingActions
このコマンドは、「適用待ち」の状態になっているオペレーションを取り消してくれます。実行後は一度再起動して挙動を確認します（必要に応じて、続けて /RestoreHealth も実行）。
DISM でコンポーネントストアを修復する
コンポーネントストア（WinSxS）が破損している場合は、/RestoreHealth で修復します。
dism /Image=D:\ /Cleanup-Image /RestoreHealth
環境によっては、インストールメディアなど別ソースを指定する必要があります。同一エディションのインストールメディアがある場合は、次のように実行します。
DISM /Image=D:\ /Cleanup-Image /RestoreHealth ^
/Source:X:\sources\install.wim:1 /LimitAccess
X:はインストールメディアのドライブinstall.wim:1のインデックス番号は、実際のエディションに合わせて調整
オフライン修復コマンドの整理
| コマンド | 目的 | 時間の目安 | 注意点 |
|---|---|---|---|
chkdsk D: /f /r | ディスクとファイルシステムの修復 | 数十分～数時間 | 不良セクターが多い場合はストレージ交換も検討 |
sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows | システムファイルの整合性チェック | 数十分程度 | OS ドライブ文字を間違えない |
dism /Image=D:\ /Cleanup-Image /RevertPendingActions | 保留中の更新・復元操作の取り消し | 数分～十数分 | 実行後は一度再起動して挙動確認 |
dism /Image=D:\ /Cleanup-Image /RestoreHealth | コンポーネントストア（WinSxS）の修復 | 十数分～ | 必要に応じてインストールメディアをソースに指定 |
セーフモードでの切り分け：ドライバー／常駐ソフトを疑う
オフライン修復後、セーフモードで起動できるようになったら、原因切り分けのチャンスです。特に直前に追加したドライバーやウイルス対策ソフト、常駐系ソフトウェアは重点的に確認します。
セーフモードで起動する手順
- WinRE の「トラブルシューティング」 → 「詳細オプション」 → 「スタートアップ設定」
- 「再起動」を選択
- 再起動後に表示されるメニューで「4）セーフモード」または「5）セーフモードとネットワーク」を選択
ここで起動に成功する場合、基本的なシステムファイルは動いているが、通常モードで読み込まれるドライバー（またはサービス）が怪しい と判断できます。
最近導入したドライバー・セキュリティ製品のアンインストール
- デバイスマネージャーで、新しく追加したデバイスやドライバーを右クリック → 「デバイスのアンインストール」
- サードパーティのウイルス対策ソフトや監視エージェントは、いったんアンインストールして OS 起動を優先
- Windows Defender だけの状態で起動を確認し、その後必要なソフトを一つずつ戻していく
どうしても起動中にアンインストールできないドライバーの止め方
問題のドライバーが特定できており、オンラインでの削除が難しい場合は、オフラインでドライバーファイルをリネームして読み込みを止める方法もあります。
- WinRE → 「トラブルシューティング」 → 「詳細オプション」 → 「コマンド プロンプト」
- OS ドライブを確認（例：
D:） - 問題ドライバーのファイル名を特定（例：
xxxx.sys）
ren D:\Windows\System32\drivers\xxxx.sys xxxx.sys.disabled
リネーム後に再起動して、BSOD の発生状況が変化するかどうか確認します。もしエラーコードやタイミングが変われば、そのドライバーが原因の一つである可能性が高まります。
ログとダンプから原因を深掘りする
現場での一次対応では「とにかく起動させる」ことが最優先ですが、同じトラブルを繰り返さないためには原因調査も重要です。ここでは、WinRE から取得できるログとダンプの位置を整理します。
ミニダンプと WER レポートの場所
- ミニダンプ：
D:\Windows\Minidump（またはMinidumpsフォルダー） - エラーレポート（WER）：
D:\ProgramData\Microsoft\Windows\WER\ReportArchive
ミニダンプが生成されていない場合は、ページファイルが無効になっているか、UWF などで書き込みが永続化されていない可能性があります。
イベントログのエクスポート
WinRE のコマンドプロンプトから、イベントログをファイルに書き出すことができます。後で別の PC にコピーして Event Viewer で確認できます。
wevtutil epl System D:\System.evtx
wevtutil epl Application D:\Application.evtx
これにより、起動直前にどのサービスやドライバーでエラーが起きているか、詳細に追いかけることができます。
IoT 環境での UWF（Unified Write Filter）とログ
IoT デバイスでよく使われる UWF（Unified Write Filter） を有効にしている場合、再起動すると書き込みがロールバックされるため、ログやダンプ自体が保存されないケースがあります。
起動できる状態になったら、管理者権限のコマンドプロンプトで次のコマンドを実行し、設定を確認します。
uwfmgr get-config
一時的にログを確実に残したい場合は、次のようにフィルターを無効化します。
uwfmgr filter disable
再起動後は書き込みが永続化されるため、ミニダンプやイベントログが記録されるようになります。調査が終わったら、忘れずに再度有効化してください。
IoT 環境特有の注意点：UWF とページファイル
UWF 有効環境でシステムの復元を行うリスク
UWF が有効なまま「システムの復元」を実行すると、
- 復元処理で書き込まれた変更が再起動時にロールバックされる
- 一部だけが書き込まれ、結果として整合性が崩れる
といった不安定な状態を招くことがあります。システムの復元や大規模更新を行う前には、次のような運用を推奨します。
- UWF を無効化（
uwfmgr filter disable） - 再起動して書き込みを永続化
- システムの復元や機能更新を実行
- 正常動作を確認後、再度 UWF を有効化
これを怠ると、「復元は成功した」と表示されるにもかかわらず、実際には一部のファイルやレジストリが元のまま、という危険な状態になりがちです。
ページファイルとミニダンプの関係
IoT デバイスでは「書き込みを減らす」目的でページファイルを無効化している構成も少なくありません。しかし、ページファイルはミニダンプやメモリダンプの出力にも関係するため、完全に無効化すると原因調査が難しくなります。
ブルースクリーンが落ち着いたら、次の項目を確認しておくとよいでしょう。
- 「システムのプロパティ」 → 「詳細設定」 → 「起動と回復」から、デバッグ情報の書き込みを「小（256KB）メモリ ダンプ」に設定
- 同じ画面の「仮想メモリ」で、OS ドライブにシステム管理サイズのページファイルを確保
これにより、今後同様のブルースクリーンが発生しても、より正確に原因を切り分けられるようになります。
最終手段：インプレース修復とイメージ再展開
ここまでの手順を試しても改善しない場合は、OS 自体を上書きする復旧が必要になります。可能であれば、ユーザーデータやアプリケーションを残せる方法から検討します。
インプレース修復（修復インストール）
通常起動が可能になった段階であれば、インプレース修復 が有力な選択肢です。
- Windows 10 IoT Enterprise LTSC 2021 と同じ版／言語のインストールメディアを用意
- OS 上から
setup.exeを実行 - 「個人用ファイルとアプリを引き継ぐ」を選択してセットアップを進める
これにより、ユーザーデータや多くのアプリケーション設定を維持したまま、システムファイルやコンポーネントを再構成することができます。ただし、組み込み用途でカスタマイズしている場合は、アプリケーションとの整合性を事前に確認しておきましょう。
システムイメージの回復／ファクトリーイメージ再展開
IoT デバイスでは、ベンダー提供の ファクトリーイメージ や、自社で事前に取得した システムイメージ を用意しているケースが多くあります。
- ベンダー純正のリカバリーメディアや、WinPE ベースのリカバリーソフトを使用
- 事前に
DISM /Capture-Imageなどで取得した WIM イメージを再展開
この方法は OS を完全に初期状態へ戻すため、ユーザーデータやログは事前にバックアップ しておく必要があります。その代わり、もっとも確実に問題を解消できる方法です。
実践で使えるチェックリストとフロー
現場対応で迷わないよう、CRITICAL_PROCESS_DIED 発生時の対応フローをチェックリスト形式でまとめます。
| 優先度 | 作業内容 | 目的 | 備考 |
|---|---|---|---|
| 高 | WinRE 起動、スタートアップ修復の実行 | ブート関連の簡易修復 | 短時間で済むので最初に実施 |
| 高 | システムの復元やり直し／復元の取り消し | 復元ポイント由来の不整合解消 | 別の復元ポイントがあれば再試行 |
| 中 | 最新の品質更新プログラムのアンインストール | 更新プログラムとの不整合解消 | 特定の KB 適用直後の障害に有効 |
| 中 | bcdedit で OS ドライブ確認 → chkdsk / SFC / DISM を実行 | ファイルシステムとシステムファイルの整合性回復 | 時間はかかるが成功率が高い |
| 中 | セーフモードで起動し、直近導入のドライバーや常駐ソフトを削除 | ドライバーやセキュリティ製品の不具合切り分け | 起動できるようになったら最優先で実施 |
| 低 | ログ・ミニダンプ・WER の採取 | 再発防止・原因分析 | すぐに復旧できない場合は先にログを確保 |
| 最終 | インプレース修復またはイメージ再展開 | 環境を再構築して完全に復旧 | 事前にバックアップを必ず取得 |
再発防止のための運用ポイント
同じトラブルを繰り返さないために、Windows 10 IoT LTSC 環境では次のような運用を意識すると効果的です。
- 標準イメージを必ず作成しておく
初期構成が完成した時点で、DISM やベンダーツールでシステムイメージを取得しておくと、最悪の場合でも短時間で復旧できます。 - UWF の状態を明確に管理する
「普段は有効だが、更新や復元時は必ず無効化してから作業する」といった運用ルールを文書化し、現場担当者にも周知しておきます。 - 大きな変更の前には必ず復元ポイント＋イメージを取る
ドライバー更新や大型アップデートの前には、復元ポイントに加えて、できれば丸ごとイメージバックアップも取得しておきます。 - ページファイルとダンプ設定を適切に構成する
書き込み寿命を気にしすぎてページファイルを完全にゼロにするのではなく、問題解析に必要な最小限の構成を維持します。 - テスト機で更新を検証してから本番に適用
可能であれば同型機を 1 台テスト用に確保し、更新プログラムやドライバーを先に検証してから現場に展開します。
よくある質問（FAQ）
Q. CRITICAL_PROCESS_DIED が出たら必ずハードウェア不良だと考えるべきですか？
A. いいえ。ディスク不良が原因になることもありますが、システムファイルやドライバーの不整合だけで発生するケースも多く、まずは本記事のようなオフライン修復とドライバーの切り分けを優先して問題ありません。
Q. オフライン SFC を実行しても「要求された操作を実行できませんでした」と表示されます。
A. 多くの場合、/offbootdir や /offwindir の指定が誤っている、もしくは OS パーティションのドライブ文字を間違えていることが原因です。bcdedit | find "osdevice" の出力を再確認し、Windows フォルダーの直下をきちんと指定しているか確認してください。
Q. システムの復元と UWF（Unified Write Filter）は併用しても問題ありませんか？
A. パラメーター次第ですが、基本的には 「併用する場合は手順を慎重に」 と考えてください。UWF が有効な状態で復元を行うと、復元処理に必要な書き込みがロールバックされる可能性があるため、復元前に UWF を無効化 → 再起動 → 復元 → 正常動作確認後に再度有効化 という流れを徹底することをおすすめします。
Q. インプレース修復とクリーンインストール、どちらを優先すべきですか？
A. 業務停止時間を短くしたい IoT 環境では、ユーザーデータとアプリを維持できるインプレース修復を優先するケースが多いです。ただし、環境が複雑にカスタマイズされている場合や、再現性の低い不具合が頻発している場合は、クリーンインストールやファクトリーイメージ再展開を検討した方が、長期的には安定することもあります。
まとめ：CRITICAL_PROCESS_DIED は「整合性の崩れ」を疑う
Windows 10 IoT LTSC 2021 でシステムの復元後に発生する CRITICAL_PROCESS_DIED は、
- 復元ポイントと現在の状態の不整合
- ドライバーや更新プログラムとの競合
- UWF やページファイル設定など IoT 特有の要因
といった「整合性の崩れ」が原因になっていることがほとんどです。まずは WinRE からの簡易復旧を試し、うまくいかなければ SFC / DISM / chkdsk によるオフライン修復、セーフモードでのドライバー切り分け、最終的にはインプレース修復やイメージ再展開までを視野に入れましょう。
同時に、UWF の扱いやバックアップ運用を見直しておくことで、次回以降は「ブルースクリーンが出ても落ち着いて戻せる」状態を作ることができます。本記事の手順とチェックリストを、自社環境向けの運用マニュアルに落とし込んでおくと、現場対応の品質向上にもつながります。
コメント