Windows Updateの0x80070643とDISMエラー998、SFCも失敗する事象を構造で整理する

本記事の対象となる事象は、Windows Update が 0x80070643 で失敗し、同時に DISM の /RestoreHealth が エラー 998（Invalid access to memory location） で止まり、sfc /scannow も正常に完走しない、という複合障害です。更新系の仕組みは複数の部品で成り立つため、単一の原因に見えても実際は「更新基盤」「コンポーネントストア」「インストーラー」「回復環境（WinRE）」などが連鎖して破綻していることがあります。以下では、発生→展開→整理の順で、論点を分解していきます。 (Microsoft Learn)

• 事象の組み合わせで見える「同時故障」のパターン
• SFC・DISM・Windows Updateが連動する理由
• 主因を分類して整理する（更新・WinRE・インストーラー・記憶域）
• ログと標準手順での切り分け（何が壊れているかを確定する）
• 解決策が分岐するポイントと、再発を避けるための整理

事象の組み合わせで見える「同時故障」のパターン

0x80070643とエラー998が並ぶ場合、更新処理の途中で必要な修復機能そのものが同時に使えなくなっている可能性が高いです。

まず 0x80070643 は、Windows Update で「更新のインストールに失敗した」局面で広く出るコードとして扱われ、個別の更新（例：WinRE更新など）に紐づいて繰り返し出ることがあります。Microsoft のコミュニティでは、回復パーティション（WinRE側）の空き容量不足が原因となり、特定の KB の適用が失敗する事例が整理されています。 (Microsoft Learn)

一方、DISM のエラー998は「Invalid access to memory location（メモリ位置への無効アクセス）」として表示され、DISM.exe /Online /Cleanup-image /Restorehealth の実行途中で停止する報告があります。実際にフォーラム投稿では、DISM のバージョン・イメージバージョン表示の直後に Error: 998 が出て、修復処理へ進めない形が確認できます。 (Sysnative Forums)

ここで重要なのは、SFC と DISM が更新基盤と同じ部品（Windows Modules Installer など）に依存する点です。SFC は実行の詳細を CBS.log に書き込み、同じログに更新インストールの痕跡も混在します。つまり、更新が壊れていると SFC/DISM 側も失敗し、逆に修復手段が失敗すると更新も復旧しにくくなります。 (Microsoft Learn)

SFC・DISM・Windows Updateが連動する理由

SFCとDISMは「システムファイル」と「コンポーネントストア」を前提に動くため、更新基盤の破損と切り離せません。

SFC（System File Checker）は Windows リソース保護（Windows Resource Protection）の枠組みで、整合性検証と修復を行い、結果を %windir%\Logs\CBS\CBS.log に記録します。さらに CBS.log は Windows Modules Installer サービスも書き込むため、更新処理（機能追加・更新・サービスパック等）の記録が同じ場所に集まります。 (Microsoft Learn)

DISM（Deployment Image Servicing and Management）は、OSイメージの「コンポーネントストア（component store）」を検査・修復し、更新の破損（Windows Update corruptions）にも用いる、という整理がMicrosoft文書側にあります。更新が失敗している状況では、DISM を先に通してから更新へ戻す流れが前提として書かれています。 (Microsoft Learn)

この点から、SFC が走らない／DISM が 998 で落ちるという状態は、単に「更新に失敗した」よりも深く、(1) 修復元の参照に失敗している、(2) 更新コンポーネント自体が破損している、(3) ストレージや暗号関連（catroot2 等）周辺の整合性が崩れている、といった複線の確認点になります。なお、0x80070643 はインストーラー系の失敗（ERROR_INSTALL_FAILURE 相当）として扱われることがあり、更新がMSIベースの手順を含む場合に再現しやすくなります。 (Python Bug Tracker)

主因を分類して整理する（更新・WinRE・インストーラー・記憶域）

同じエラー表示でも、原因が「更新基盤」なのか「WinRE領域」なのかで、確認すべき対象が変わります。

0x80070643 は汎用性が高い一方で、実務上は「どの更新が失敗したか」によって論点が変わります。2024年に広く報告された WinRE 更新（例：KB5034441 系）では、回復パーティション容量が不足して更新が失敗するケースが明確に整理されています。 (Microsoft Learn)
他方、.NET Framework 更新など、インストーラー（MSI）系の失敗として 0x80070643 が出る筋もあり、同じコードでも故障点が異なります。 (Microsoft Learn)

DISM 998 側は、更新失敗後に派生して発生した報告があり、更新コンポーネントの破損や、修復に必要な参照先の不整合が疑われます（フォーラム投稿レベルの観測）。 (Sysnative Forums)
そのため、「更新のダウンロード保管庫」「署名カタログ（catroot2）」「CBS/DISMログ」「回復領域」「記憶域エラー」の5点が、まず切り分け軸になります。

なお、論点を比較しやすくするため、代表的な症状と確認対象を表にまとめます。

この結果、原因特定の順序は「どのKBか」→「WinRE関与の有無」→「更新コンポーネント破損」→「修復ソース不足」→「記憶域/暗号周辺」の順が、整理として合理的になります。

ログと標準手順での切り分け（何が壊れているかを確定する）

CBS.logとDISMログの読み分けができると、「更新の失敗」と「修復の失敗」を分離できます。

SFC のログは CBS.log に残り、SFC のエントリには [SR] タグが付くため、更新処理のログからSFC関連を抽出して確認できます。Microsoft 文書は CBS.log の場所と [SR] を明示しています。 (Microsoft Learn)
一方、DISM の失敗は C:\Windows\Logs\DISM\dism.log 側にまとまる運用が一般的で、エラー998の事例でも保存先が表示されています。 (Sysnative Forums)
つまり、CBS と DISM を並行に見ることで「修復が失敗した原因が更新側ログに引きずられているだけか」または「修復基盤自体が破綻しているか」を分けられます。

また、Microsoft のトラブルシューティング文書では、Windows Update の破損に対して DISM を用い、その後に SFC を実行し、再度更新を試すという工程が示されています。これは「コンポーネントストア→システムファイル→更新適用」の依存順を前提にしています。 (Microsoft Learn)
ただし、DISM が 998 で止まる場合は、この順序が回らないため、更新コンポーネントの手動リセット（BITS/Windows Update/Cryptographic service 停止と関連フォルダ再生成）が切り替え候補になります。Microsoft は Windows Update コンポーネントの手動リセット手順の骨格（対象サービス名）を追加資料としてまとめています。 (Microsoft Learn)

以上を踏まえると、現場での整理は「(A) WinRE更新由来の0x80070643」か「(B) 更新基盤破損＋修復コマンド連鎖失敗」かを最初に確定し、その後にログの根拠で分岐させる流れになります。

解決策が分岐するポイントと、再発を避けるための整理

同じ0x80070643でも、WinRE容量不足の系統とMSI系失敗の系統では、対処の選択肢が一致しません。

WinRE更新が失敗する系統では、回復パーティションの空き領域不足が論点になり、コミュニティ回答でも容量調整が回避策として提示されています。ただし、これはディスク構成の変更を含むため、運用上の確認点（BitLockerの状態、管理ポリシー、バックアップの有無）が先に立ちます。 (Microsoft Learn)
他方、MSI/インストーラー由来の 0x80070643 は「インストール失敗」を示す範囲が広く、.NET Framework 更新など個別コンポーネントの不整合が関係する場合があります。 (Microsoft Learn)

そして、DISM 998 が絡む場合は、更新を直すための修復（DISM）が先に止まるため、更新コンポーネントの再生成、修復ソースの見直し（同一ビルドのインストールメディア参照）といった「別経路の修復」に寄せる必要が出ます。Microsoft の文書でも、修復ソースを指定して DISM を実行する考え方が示されています。 (Microsoft Learn)

要点を整理すると、0x80070643 は結果コードであり、原因はKB単位・領域単位で分岐します。そのため、(1) 失敗しているKB名と種類、(2) WinRE関与の有無、(3) CBS.log と dism.log の失敗点、(4) 更新コンポーネント再生成で変化が出るか、を順に確かめることが判断材料として重要です。以上を踏まえると、最終的に「修復コマンドで回復できる破損」か「構成（回復領域等）を変えないと進まない失敗」かを切り分けるのが、本記事で整理した結論になります。