Windows Server 2022/2016で「0x800F0922」—パッチ火曜日の更新が入らないときの原因と直し方

Windows Server 2022 または 2016 で、月例の「Patch Tuesday（パッチ火曜日）」更新を適用しようとすると インストール エラー 0x800F0922 で止まることがあります。再試行しても失敗を繰り返し、運用中サーバーだと時間だけが溶ける厄介なトラブルです。
この記事では、よくある原因を整理したうえで、現場で効く手順を「安全に戻せる順（低リスク→高リスク）」でまとめます。

• Windows Server 2022/2016で「0x800F0922」—パッチ火曜日の更新が入らないときの原因と直し方
  • 0x800F0922 とは？症状の典型
  • よくある原因（まずここを疑う）
  • まずやるべき「低リスク」対処（上から順に）
    • 1) VPN/プロキシを一時的に外す、セキュリティ製品を確認
    • 2) 再起動→更新の再実行（意外と効く）
    • 3) DISM と SFC でOS側の破損を修復
    • 4) Windows Update コンポーネントのリセット（定番）
  • それでもダメなら「原因を絞る」観点
    • 5) 予約領域/回復領域の空きとWinRE状態を確認
  • 最終手段に近いが効くことがある：WINEVT Publishers の修復（レジストリ）
    • 実施前の安全策
    • 実施の流れ（要点）
  • 更新を通すための実務的なコツ（失敗を減らす）
  • まとめ：最短で直す優先順位

0x800F0922 とは？症状の典型

• Windows Update / WSUS / 手動適用（msu/cab）いずれでも失敗する

• 途中まで進むが最後にロールバックする

• 「更新プログラムを構成できませんでした」系のメッセージが出ることがある

• CBS.log や WindowsUpdate.log では、コンポーネントストア、予約領域、WinRE、イベントログ関連など複数パターンに分岐する

0x800F0922 は「これが原因」と一発で決まらず、環境要因が絡みやすいのが特徴です。

よくある原因（まずここを疑う）

1. システム予約領域/EFI/回復領域の空き不足
   更新の種類によっては小さな領域の空きが足りず失敗します。

2. WinRE（回復環境）関連の更新で失敗
   回復環境が無効、またはパーティション構成の都合で更新が当たらないケース。

3. VPN/プロキシ/セキュリティ製品が通信や書き込みを阻害
   パッチ火曜日直後は配布経路も混み、タイムアウトやブロックが表面化します。

4. Windows Update コンポーネントの破損・キャッシュ不整合
   SoftwareDistribution や catroot2 の不整合、署名検証の詰まりなど。

5. コンポーネントストア破損（DISMで直ることが多い）

6. イベントログの「Publisher」定義の不整合（レジストリ）
   一部環境で、イベントの発行元定義が壊れて更新処理が転ぶことがあります。

まずやるべき「低リスク」対処（上から順に）

1) VPN/プロキシを一時的に外す、セキュリティ製品を確認

• サーバーがインターネットへ直接出ない運用でも、社内プロキシや検疫装置が原因になることがあります。

• 一時的に更新用の経路をシンプルにし、再試行します。

2) 再起動→更新の再実行（意外と効く）

パッチ火曜日直後は更新の前提パッケージ（SSUなど）が絡み、保留状態が積み上がっていることがあります。
再起動して保留を解消してから、改めて更新します。

3) DISM と SFC でOS側の破損を修復

管理者のコマンドプロンプト（または PowerShell）で順に実行します。

• DISM（コンポーネントストア修復）

• SFC（システムファイル整合性）

運用上は、DISM → 再起動 → SFC の流れが安定です。

4) Windows Update コンポーネントのリセット（定番）

キャッシュや署名カタログの不整合で失敗する場合に効きます。
ポイントは、更新関連サービスを止めてから SoftwareDistribution / catroot2 を退避（リネーム）し、サービスを戻すことです。
再実行時にキャッシュが再生成され、詰まりが解消します。

それでもダメなら「原因を絞る」観点

5) 予約領域/回復領域の空きとWinRE状態を確認

• システム予約領域（または EFI）に極端に空きがない

• 回復パーティションが小さすぎる／存在しない

• WinRE が無効になっている

この系統は、更新内容によっては 領域拡張 が必要になります。
ただしパーティション操作はリスクが高いので、バックアップと手順の確実性が担保できるときに実施してください。

最終手段に近いが効くことがある：WINEVT Publishers の修復（レジストリ）

入力テキストにあった以下の削除コマンドは、イベントログの発行元定義（Publisher）を持つレジストリキーを消すものです。

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{53e3d721-2aa0-4743-b2db-299d872b8e3d} を削除

この手当が効くのは、更新処理がイベントログの登録・参照でつまずいているタイプのときです。
ただし、レジストリ削除は影響範囲が読みづらいので、次の順で「戻せる状態」を作ってから行います。

実施前の安全策

1. システムの復元点相当がないサーバーでは、必ずフルバックアップ（最低でもSystem State）

2. 該当キーを エクスポート（regedit で右クリック→エクスポート、または reg export）

3. 可能ならメンテナンス時間帯で実施

実施の流れ（要点）

• キーをエクスポート

• 削除コマンドでキー削除

• 再起動

• 更新を再実行

削除後、必要に応じて定義が再生成されます。もし副作用が出た場合は、エクスポートした .reg を戻して再起動し、原状復帰します。

更新を通すための実務的なコツ（失敗を減らす）

• パッチ火曜日直後は混むので、少し時間を置いてから再試行するだけで通ることがあります

• WSUS配下なら、対象KBの承認状態・配布状況・期限切れを確認

• 「累積更新＋前提（SSU等）」が絡む場合は、前提を先に適用してから累積更新を当てる

• 何度も失敗するサーバーは、ログを見て「領域」「通信」「破損」「イベントログ」どれが濃いかを決め打ちすると早い

まとめ：最短で直す優先順位

1. VPN/プロキシ/セキュリティの影響を外して再試行

2. 再起動→DISM→SFC

3. Windows Update コンポーネントのリセット

4. 予約領域/回復領域/WinREの確認（必要なら拡張を検討）

5. どうしても詰まる場合に限り、WINEVT Publishers のレジストリ修復（必ずバックアップ）

0x800F0922 は焦るほど長引きます。まずは低リスク手順で土台を整え、それでもダメなら「領域」と「イベントログ定義」を疑う流れが、現場では一番再現性が高いです。