Windows Server 2016でWindows Updateエラー「0x80073712」とDISMエラー1734を直す実践手順（KB適用失敗の原因と復旧）

Windows Server 2016で最新の累積更新プログラム（CU）を入れようとしたら 0x80073712 で失敗し、sfc /scannow も「一部修復できない」、さらに DISM /Online /Cleanup-Image /RestoreHealth は Error: 1734（The array bounds are invalid）――この組み合わせは、更新に必要な“部品置き場”（コンポーネントストア）が不整合を起こしているときに起きやすい典型例です。0x80073712は更新ファイルの欠損・破損やコンポーネントストア不整合で発生しやすいエラーとして案内されています。Microsoft Learn+1

• Windows Server 2016でWindows Updateエラー「0x80073712」とDISMエラー1734を直す実践手順（KB適用失敗の原因と復旧）
  • 起きていることを整理する（症状から見える原因）
  • まずやるべき安全準備（失敗を増やさない）
  • 手順1：Windows Updateコンポーネントのリセット（基礎体力の回復）
  • 手順2：DISMを「修復ソース指定」でやり直す（ここが本命）
  • 手順3：コンポーネントストアのクリーンアップ（破損の温床を減らす）
  • 手順4：CU（KB）を手動適用して検証する
  • 手順5：ログで“次の一手”を決める（CBS/DISM）
  • 最終手段：インプレース修復（役割を壊さずOSを修復する）
  • まとめ：この症状の攻略順は「キャッシュ → ソース指定DISM → SFC → 手動KB」

起きていることを整理する（症状から見える原因）

今回のログの流れは次の通りです。

• Windows Updateで 0x80073712

• sfc /scannow：破損は見つかるが 一部修復不可

• DISM /RestoreHealth：100%まで進むが Error 1734

0x80073712は、更新で参照するコンポーネントストア（WinSxS）側の不整合・破損が疑われる代表的なサインです。Microsoft Learn+1
そしてDISMの1734は「修復を実行しようとして最後に落ちる」ケースがあり、オンライン修復だけでは完走できない状況に入り込んでいる可能性があります。Microsoft Learn+1

ここから先は、「Windows Updateのキャッシュを捨てる」レベルでは足りず、“修復ソースを指定したDISM” や オフライン寄りの手当て が効いてきます。

まずやるべき安全準備（失敗を増やさない）

手順に入る前に、これだけは押さえてください。

• 空き容量：Cドライブに十分な空き（目安 15～20GB以上）

• 再起動保留の解消：Pending状態を残したまま修復を回すと悪化しやすい

• 可能ならスナップショット/バックアップ（特に仮想環境）

手順1：Windows Updateコンポーネントのリセット（基礎体力の回復）

コンポーネントストア破損が主因でも、更新キャッシュが絡んで失敗がループすることがあります。まず更新関連サービスを止め、キャッシュを退避してから再起動します。

管理者のコマンドプロンプトで実行：

この後、再起動してからWindows Updateを再試行します。
（Microsoftも更新失敗時の修復として、DISM/SFCと並行して更新周りの問題切り分けを案内しています。Microsoft Learn）

手順2：DISMを「修復ソース指定」でやり直す（ここが本命）

/RestoreHealth が1734で落ちる場合、オンライン修復で参照できるソース側が不足していたり、参照先が壊れていることがあります。そこで 同一ビルド系のインストールメディア（ISO） を用意し、install.wim（またはinstall.esd）を修復ソースにします。Microsoftは修復ソースとして同一OSバージョンのコンピューターやメディアを使う手順を案内しています。Microsoft Learn

1. Windows Server 2016のISOをマウント（例：D:）

2. エディション確認（WIMのIndexを調べる）

3. ソース指定で修復（例：Index 2だと仮定）

ポイント：

• LimitAccess を付けると、Windows Update側を参照せず“指定ソース優先”になります

• install.esd の場合は Source:esd: を使います

完走したら、続けてSFCをもう一度：

手順3：コンポーネントストアのクリーンアップ（破損の温床を減らす）

修復が通った後は、コンポーネントストアの整備で再発しにくくします。

※この工程だけで壊れたものが直るわけではありませんが、更新の“詰まり”を軽くする方向に働きます。

手順4：CU（KB）を手動適用して検証する

Windows Update経由で失敗する場合でも、スタンドアロン（手動） で通ることがあります。

• Microsoft Update Catalogから該当KBのmsuを取得

• 管理者で実行して適用

• それでも0x80073712なら、修復がまだ不十分な可能性が高い

（0x80073712が「必要ファイルが欠損/破損」で更新が止まるケースとして説明されることがあります。Microsoft Learn+1）

手順5：ログで“次の一手”を決める（CBS/DISM）

ここまでで改善しないときは、闇雲にコマンドを繰り返すよりログの要点を拾うのが早道です。

• C:\Windows\Logs\CBS\CBS.log

• C:\Windows\Logs\DISM\dism.log

見どころは以下：

• repair source が見つからない（source不一致/不足）

• パッケージ適用の失敗（特定KBやコンポーネント名が出る）

• manifest / payload の欠損（SxS関連）

ログで特定コンポーネント名が出る場合、同一ビルドのソース指定DISMが効くことが多いです。

最終手段：インプレース修復（役割を壊さずOSを修復する）

DISMがどうしても通らない、CBSが延々と同じ破損を出す――この段階では、インプレースアップグレード（修復インストール） が現実的な着地点になります。
Server 2016でも、同等エディション/同系統ビルドのメディアで“上書き修復”を行うことで、コンポーネントストアをまとめて再構成できます（アプリや設定を極力維持する狙い）。なお、環境依存が大きいので事前バックアップは必須です。

まとめ：この症状の攻略順は「キャッシュ → ソース指定DISM → SFC → 手動KB」

0x80073712＋SFC修復不可＋DISM 1734は、更新周りの“小手先”では抜けにくい状態です。効率よく直すなら次の順番が堅いです。

1. Windows Updateコンポーネントをリセット

2. ISOを使ったソース指定DISM（/LimitAccess付き）

3. SFCを再実行

4. KBを手動適用で再テスト

5. ログで原因特定、それでもダメならインプレース修復

この流れで、更新を「通せる状態」に戻しやすくなります。