Windows Server 2022 の更新後に再起動が長いときは、まず「固まった」と決めつけないことが大切です。Windows Update は scan、download、install、commit の流れで進み、再起動は commit 段階にあたります。さらに更新を実際に適用する servicing stack は CBS を含み、役割・機能変更やコンポーネント修復にも関わるため、役割追加直後や前回更新の未完了があるサーバーほど再起動が長く見えやすくなります。(Microsoft Learn)
一方で、保留中アクション、コンポーネントストア破損、非 Microsoft 製フィルタードライバー、管理者権限不足、C: ドライブの空き不足が重なると、本当に更新失敗や再起動ループになることもあります。この記事では、Windows Server 2022 の更新後に再起動が長い原因を整理しつつ、待つべきケース、確認するログ、実際の復旧手順まで順番にまとめます。(Microsoft Learn)
Windows Server 2022の更新後に再起動が長いときの結論
最短で切り分けるなら、見る場所は多くありません。
- ログオンできるなら、
イベント ビューアー > アプリケーションとサービス ログ > Microsoft > Windows > WindowsUpdateClient > Operationalと System ログの Event 19 / 41 / 1001 / 1074 を確認します。19 は更新成功、41 と 1001 は異常再起動や bugcheck の手掛かりになります。(Microsoft Learn) C:\Windows\Logs\CBS\CBS.logを確認し、必要なら PowerShell でGet-WindowsUpdateLogを実行して読みやすいWindowsUpdate.logを生成します。Get-WindowsUpdateLogが作るログは静的コピーなので、取り直さない限り最新化されません。(Microsoft Learn)- 同じ KB が失敗を繰り返すなら、まず DISM と SFC でコンポーネントストアとシステムファイルを修復します。(Microsoft Learn)
- 起動しない、または再起動ループなら、Windows RE で最新の品質更新プログラムをアンインストールし、それでもだめならオフライン DISM で修復や pending actions の巻き戻しを行います。(Microsoft サポート)
主な原因と起きやすい条件
| 原因 | 起きやすい条件 | 対処の方向 |
|---|---|---|
| 更新の commit / CBS 処理 | 大きめの累積更新、役割・機能変更の直後 | まずは正常処理を疑い、起動後に Event 19 と Operational ログで確認する |
| RebootPending の残留 | 前回更新未完了、ファイル名変更、コンピューター名変更、ドメイン参加の直後 | 追加再起動、CBS 確認、必要ならオフラインで pending actions を戻す |
| コンポーネントストア破損 | 同じ KB が毎回失敗、ロールバックを繰り返す | DISM → SFC の順で修復する |
| 非 Microsoft 製ドライバーや AV/EDR の干渉 | バックアップエージェント、EDR、アンチウイルス導入後 | Clean Boot やドライバー更新で切り分ける |
| 権限やサービス設定の問題 | 0x80070005、0x80246017、更新サービスの設定変更 | 管理者権限、更新関連サービス、GPO を見直す |
| 空き容量不足や配信経路の問題 | C: が逼迫、WSUS、proxy、firewall 配下 | 容量確保と配信元ログの確認を優先する |
この表の根拠は、Windows Update の commit と servicing stack/CBS の役割、RebootPending の要因、コンポーネントストア修復手順、フィルタードライバー干渉、権限不足、WSUS/proxy の挙動に関する Microsoft の公式資料です。WSUS や GPO が関係していても、再起動そのものの重さは最終的にサーバー上の CBS やインストーラー処理に引っ張られるため、「配信側だけ見て終わり」にしないのが実務では重要です。(Microsoft Learn)
止まっているのか見分ける
Microsoft は Windows Server の再起動原因を追うとき、Event 19、41、1001、1074、7045 を見るよう案内しています。起動後にサインインできたら、まずこの視点で見れば十分です。(Microsoft Learn)
| Event ID | 見方 |
|---|---|
| 19 | Windows Update のインストール成功。更新そのものは通っている可能性が高い |
| 41 | 正常終了せず再起動。強制停止、クラッシュ、電源断を疑う |
| 1001 | bugcheck 由来の再起動。ドライバーやストレージ、カーネル側の異常を疑う |
| 1074 | どのプロセスが再起動を開始したかを追える |
| 7045 | 直前に追加されたサービスが影響していないかを見る手掛かりになる |
実務では、Event 19 があるのに「再起動が長かっただけ」なのか、41 や 1001 が並んでいて本当に異常停止しているのかで、その後の対処がまったく変わります。前者は CBS や構成処理の長時間化、後者はドライバーやフィルタードライバー、カーネル例外の線が濃くなります。(Microsoft Learn)
最初に確認するログと設定
更新後の切り分けで先に見るべき場所は、次の 4 つです。(Microsoft Learn)
| 確認項目 | どこを見る | 何が分かる |
|---|---|---|
| WindowsUpdateClient Operational | イベント ビューアーの Operational ログ | 失敗した KB、失敗コード、再試行の有無 |
| CBS.log | C:\Windows\Logs\CBS\CBS.log | コンポーネントストア破損、pending、パッケージ処理失敗 |
| WindowsUpdate.log | Get-WindowsUpdateLog | scan / download / 配信元 / proxy 周りの流れ |
| C: ドライブの空き容量 | Storage、Temporary files、WinSxS の肥大 | 容量不足が原因かどうか |
権限と干渉も、ログだけでなくエラーコードで見分けやすいです。0x80070005 はアクセス拒否や管理者権限不足、0x80246017 は十分な特権を持たないローカルユーザー、0x80070020 は sharing violation で、Microsoft は非 Microsoft 製フィルタードライバーやアンチウイルスが原因になるケースを案内しています。0xC1900101 は互換性のないドライバーが原因の代表例です。(Microsoft サポート)
ログオンできる場合の対処手順
まず既知の不具合を確認する
単体サーバーの破損だと思って深掘りしがちですが、月例更新では既知の問題が後続更新で解消されることがあります。Windows Server 2022 の known issues / resolved issues ページを先に確認すると、「自分だけの障害」なのか「その月の更新由来」なのかを早く見分けられます。実際に Microsoft は、個別の問題を後続更新で解消済みとして案内しています。(Microsoft Learn)
DISM と SFC でコンポーネントストアを修復する
更新失敗の定番が、コンポーネントストアやシステムファイルの破損です。Microsoft は、DISM でイメージを修復してから SFC を実行する流れを案内しています。(Microsoft Learn)
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannowDISM は既定で Windows Update を修復ソースに使います。Windows Update 側も壊れているなら、/Source と /LimitAccess を付けて修復元を明示します。更新の失敗理由は CBS.log に残るので、コマンドの成否だけで終わらせず、ログまで確認するのがポイントです。(Microsoft サポート)
Update cache をリセットする
ダウンロード不完全、メタデータ不整合、同じ KB の再試行を繰り返すときは、SoftwareDistribution と catroot2 のリセットが効くことがあります。ただし、これは最初の一手ではなく、DISM / SFC の次の段階です。Microsoft の手動リセット手順でも、より強い ACL 初期化は後段として扱われています。(Microsoft Learn)
net stop bits
net stop wuauserv
net stop cryptsvc
ren %Systemroot%\SoftwareDistribution\DataStore DataStore.bak
ren %Systemroot%\SoftwareDistribution\Download Download.bak
ren %Systemroot%\System32\catroot2 catroot2.bak
net start cryptsvc
net start wuauserv
net start bitsこの手順は「更新のダウンロードや検証キャッシュを作り直す」目的です。再起動の長さそのものを直接短くする方法ではありませんが、失敗した更新を正常な状態に戻すには有効です。(Microsoft Learn)
Clean Boot で干渉を切り分ける
アンチウイルス、EDR、バックアップエージェント、ストレージ関連ソフトが入っているサーバーでは、更新ファイルを別プロセスがつかんで sharing violation になり、再起動後の適用やロールバックを引き延ばすことがあります。Microsoft は、0x80070020 の原因として非 Microsoft 製フィルタードライバーを挙げ、Clean Boot を推奨しています。(Microsoft Learn)
GUI 環境なら、msconfig で 「すべての Microsoft サービスを非表示」→「すべて無効」、続いてスタートアップアプリを無効化して再起動し、更新を再試行します。これは本番サーバーでは必ずメンテナンス時間帯に行い、EDR や AV はベンダー手順に従って一時停止してください。(Microsoft サポート)
ドライバーと空き容量も見る
0xC1900101 は互換性のないドライバーが原因の代表例です。特に仮想 NIC、ストレージ、GPU を使うサーバー、またはセキュリティ製品のカーネルドライバーが入っている環境では要注意です。(Microsoft サポート)
また、C: ドライブの空き容量不足は更新だけでなく性能にも影響します。GUI がある環境なら 設定 > システム > ストレージ から Cleanup recommendations を確認し、不要な一時ファイルを整理します。更新後の肥大が気になる場合は、システムが安定してから WinSxS のクリーンアップも検討します。(Microsoft サポート)
WSUS、proxy、GPO を見直す
「再起動が長い」と見えても、根本原因が scan / download 段階にあることは珍しくありません。Windows Update Orchestrator は管理者の承認やポリシーを確認しつつ、Windows Update または WSUS を相手に処理します。proxy や firewall の不整合があると、配信経路で失敗し、それが再起動後の不安定さとして表面化することがあります。複数台で同じ症状なら、まず配信側を疑うべきです。(Microsoft Learn)
起動しない・再起動ループの復旧手順
Windows RE で最新の品質更新プログラムをアンインストールする
Windows に入れないなら、いちばん安全なのは Windows RE からの更新アンインストールです。手順は次のとおりです。(Microsoft サポート)
- Windows RE を開く
- トラブルシューティング > 詳細オプション > 更新プログラムのアンインストール を選ぶ
- まず 最新の品質更新プログラムをアンインストールする を試す
月例更新の直後に症状が出たなら、まずここから始めるのが定石です。
インストールメディアからオフライン修復する
更新アンインストールで戻らない場合は、インストールメディアから WinRE を起動してオフライン修復します。Microsoft の Windows Server 向け資料では、OS ドライブ文字の特定、CHKDSK、オフライン SFC、オフライン DISM /restorehealth の順で実施する流れが示されています。(Microsoft Learn)
BCDEdit
CHKDSK /f D:
SFC /scannow /offbootdir=D:\ /offwindir=D:\Windows
DISM /image:D:\ /cleanup-image /restorehealthD: は例です。BCDEdit で確認した OS ボリュームのドライブ文字に置き換えてください。
pending actions を巻き戻す
更新の pending actions が起動失敗の原因なら、オフラインイメージに対して RevertPendingActions を使います。これは 起動しない Windows イメージの回復専用 の手段で、実行中の OS に対して使うものではありません。(Microsoft Learn)
DISM /Image:D:\ /Cleanup-Image /RevertPendingActionsこのコマンドは、前回のサービス操作から残っている保留アクションを巻き戻すためのものです。更新適用中の通常運用サーバーで乱用するコマンドではありません。(Microsoft Learn)
累積更新だけをロールバックしたいとき
最近の Windows Server 2022 の累積更新は、SSU と LCU が結合されたパッケージとして配布されています。Microsoft の Server 2022 向け KB では、LCU を外すときは DISM /Remove-Package を使い、wusa.exe /uninstall は使えないと案内されています。(Microsoft サポート)
DISM /online /get-packages
DISM /online /Remove-Package /PackageName:<package-name>パッケージ名は DISM /online /get-packages で確認します。/Remove-Package 自体の構文も DISM の公式ドキュメントにあります。(Microsoft サポート)
やってはいけないこと
- 原因を見ないまま、更新中に何度も強制電源断する
- 切り分け前に
DISM /online /Cleanup-Image /StartComponentCleanup /ResetBaseを実行する wusa /uninstallで結合済みの SSU + LCU を外そうとする- キャッシュ削除、ドライバー更新、AV 停止を一度に全部やる
特に StartComponentCleanup /ResetBase は、既存の更新プログラムをアンインストールできなくなるため、トラブル対応の初動では不向きです。wusa /uninstall も結合パッケージでは使えません。まずはログを見て、1 手ずつ変えるほうが復旧も検証も速くなります。(Microsoft Learn)
再発を減らす運用のコツ
- 更新の適用時間を GPO で明示し、メンテナンス時間帯に寄せる
- 月例更新の日に、役割追加、機能有効化、ドメイン参加、コンピューター名変更を重ねない
- 更新前に C: の空き容量を確認し、逼迫しているなら先に整理する
- AV、EDR、バックアップエージェント、ストレージドライバーはテスト環境で先行確認する
- まず Release Health を見て、既知の不具合が出ていないか確認する
Windows Update の再起動タイミングは GPO で制御できますし、役割変更やドメイン参加待ちは RebootPending の要因になり得ます。更新と構成変更を同日にまとめる運用は、障害時の切り分けを難しくします。(Microsoft Learn)
まとめ
Windows Server 2022 の更新後に再起動が長いときは、原因を「正常な commit 処理」か「pending、破損、ドライバー干渉、権限、容量不足」かに分けて考えると、ほぼ迷いません。まず見るのは Event 19 / 41 / 1001、WindowsUpdateClient Operational、CBS.log です。ログオンできるなら DISM と SFC、必要なら更新キャッシュのリセットと Clean Boot。起動できないなら Windows RE で品質更新のアンインストール、次にオフライン修復と RevertPendingActions です。(Microsoft Learn)
次にやるべきことは、まず Event Viewer と CBS.log を確認し、同じ KB が繰り返し失敗しているかどうかを掴むことです。そこで傾向が見えれば、待つべきか、修復すべきか、WinRE に切り替えるべきかがすぐ判断できます。
コメント