Windows 11 25H2でDISMの0x800f0915が出る事象を整理する（26200.6899）

本記事の対象となる事象は、PCのクラッシュ後に DISM.exe /Online /Cleanup-Image /RestoreHealth を実行したところ 0x800f0915 が返り、同時に sfc /scannow は問題なし（整合性違反なし）として完了する、という組み合わせです。Windows 11 Pro 25H2（OS ビルド 26200.6899）環境で起きた例を前提に、DISMとSFCの役割差、0x800f0915が示す構造、実務上の切り分け順を淡々と整理します。なお、OS ビルド 26200.6899 は 2025年10月の累積更新で示されている範囲に該当します。 マイクロソフトサポート

• Windows 11 25H2でDISMの0x800f0915が出る事象を整理する（26200.6899）
  • 事象の概要と前提条件の整理
  • DISMとSFCの役割差と、確認に使うログの位置づけ
  • 0x800f0915が示す構造と原因カテゴリ
  • 段階的な復旧手順の考え方（Windows Update → ローカルソース）
  • 収束しない場合の論点と、再発条件の整備

事象の概要と前提条件の整理

本記事が示す状況では、クラッシュ後にWindowsのコンポーネントストア（更新・修復に使う部品群）側の不整合が疑われたため、DISMの修復（RestoreHealth）を試みたものの失敗しています。一方で、SFCはOS稼働中の保護対象システムファイルを照合し、欠落や破損があれば置換しますが、SFC単体で「問題なし」になるケースもあります。 マイクロソフトサポート+1

加えて、前提にある環境情報（例：Windows 11 Pro 25H2、ASUS ROG STRIX B450-F、Ryzen 5 3600X、メモリ約16GB、ストレージ複数台構成）は、DISMの修復ソース選定や更新経路（Windows Updateかローカルメディアか）に影響し得ます。特に複数ドライブ構成では、修復に必要なファイル探索の経路が複雑になり、条件差が生じる可能性があります。

SFCが正常でも、DISMが失敗する組み合わせは「矛盾」ではなく、対象領域が異なるため成立します。 そのため、この段階では「SFCが通ったから問題がない」とは整理しません。そうすることによって、次章でDISMとSFCの機能差を前提に切り分け条件を並べられます。

DISMとSFCの役割差と、確認に使うログの位置づけ

Windowsの公式情報では、SFCは不足・破損したシステムファイルの修復に用いられ、DISMはより広い範囲としてコンポーネントストアの整合性確認・修復に使われます。DISMは既定でWindows Updateを修復ソースに使うため、更新クライアント側の問題やソース取得不能があると失敗し得ます。 マイクロソフトサポート+1

この点から、0x800f0915の局面では「OS内部にある修復材料が足りない」か「修復材料はあるが参照できない」かのどちらかに寄せて整理できます。言い換えると、SFCが見ている範囲（稼働中の保護対象ファイル）が正常でも、DISMが必要とする修復材料（コンポーネントストア側の部品や更新由来のファイル）が欠けている、または取得不能なら失敗します。

実務上の確認点としては、DISMの結果だけで終わらせず、ログで「ソース探索の失敗」なのか「パッケージ適用の失敗」なのかを区別します。一般的にDISMやCBSのログ（例：C:\Windows\Logs\DISM\dism.log、C:\Windows\Logs\CBS\CBS.log）に根拠が残るため、次章の原因整理で扱う分類に接続できます。 Sysnative Forums

0x800f0915の切り分けは、DISMが参照した修復ソースの成否をログで押さえることが中心になります。 ただし、ログ読解は詳細に踏み込みすぎると章立てが崩れるため、次章では原因カテゴリを先に固定します。

0x800f0915が示す構造と原因カテゴリ

コミュニティ事例では、0x800f0915は「repair content（修復に必要な内容）が見つからない」趣旨の失敗として現れ、Windows Update経由でもローカルでも必要ファイルに到達できない局面が報告されています。 Windows 11 Forum+1 つまり、DISMの処理手順のうち「修復材料の探索・取得」に失敗している構造が中心になります。

要点を整理すると、原因は大きく(1)更新経路の問題、(2)修復ソースの不一致、(3)外部要因によるブロック、の3群にまとめられます。なお、Windows Updateの単体破損だけでなく、グループポリシー等で修復ソース参照が制限されている場合もあり、解釈が分かれる余地があります。 Microsoft Learn+1

この結果を、確認軸として最小限の表にすると次のようになります。

0x800f0915は「修復材料に到達できない」系の失敗として整理し、更新経路・ソース整合・外部干渉を順に潰すのが筋です。 そのため、次章では「段階的に修復条件を増やす」進め方を示します（いきなり最終手段に寄せないため）。

段階的な復旧手順の考え方（Windows Update → ローカルソース）

公式情報では、DISMは既定でWindows Updateを修復ソースとして使い、必要に応じて /Source と /LimitAccess を使って修復ソースを明示できます。 マイクロソフトサポート+2Microsoft Learn+2 したがって、進め方は「まず既定経路で成立する条件を整える」→「成立しない場合はローカルに寄せる」という順序が合理的です。

まず前段として、Windows Update側が健全に動いていることを確認します。更新サービスの停止・再開、更新キャッシュの再構築、累積更新の再適用などが該当します。ここで重要なのは、OS ビルド 26200.6899 が特定の累積更新に紐づくため、修復ソースとして用意するISOやinstall.wim/esdも同系統の版・言語・エディションで揃える必要がある点です。 マイクロソフトサポート

他方、既定経路が成立しない場合は、ISO等から install.wim（または install.esd）を修復材料に指定する設計になります。一般にこの局面では、/Source を適切に指し、必要なら /LimitAccess でWindows Update参照を止めます。公式サポートでも、Windows Updateクライアントの問題がある場合に、別媒体を修復ソースとして使う考え方が示されています。 マイクロソフトサポート+1

既定（Windows Update）で直らない場合は、同一版のISOを修復ソースにしてDISMを成立させる構成が中核になります。 なお、作業記録としては、各段階でDISMの戻り値とログ差分を保存しておくと検証んが容易になります。

収束しない場合の論点と、再発条件の整備

上記の切り分けで収束しない場合、論点は「OSの更新・修復経路」から「システム全体の一貫性」へ移ります。具体的には、インプレースアップグレード（上書き修復）でOSコンポーネントを再配置する、回復環境（WinRE）の整合を含めて修復計画を立て直す、といった方向です。なお、累積更新が回復周りに影響する事例もあるため、OSビルドに紐づく既知事項の確認は判断材料として重要です。 Windows Central+1

また、クラッシュ後にDISMが失敗したという経緯からは、ストレージの一時的なI/O不整合、ファイルシステムエラー、メモリエラーなど、OS外の要因が間接的に修復材料の破損や取得失敗を招いた可能性も残ります。このため、DISMの問題を「更新ツールの不具合」に限定せず、ディスク検査（chkdsk）やSMART確認、メモリ診断などを組み合わせて根本要因を狭める運用が一般的です。

最後に、サードパーティAVが更新・修復処理を阻害する可能性は複数の事例で言及されており、外部干渉の有無は独立の確認点として残ります。 Microsoft Learn 以上を踏まえると、復旧が長引くほど「修復ソース整合」「更新経路健全性」「外部干渉」「基盤（ストレージ/メモリ）」の4点を並走で見直す構図になります。

DISM 0x800f0915が続く場合は、修復ソースの整合性に加えて、クラッシュ要因（基盤障害やI/O不整合）まで範囲を広げた再検討が必要になります。