Windows 11 24H2 で累積更新プログラム KB5065426 のインストールが 0x800f081f で失敗し続け、さらに修復インストールも SAFE_OS フェーズ(MIGRATE_DATA)で止まると、原因が「Windows Update だけ」の問題ではない可能性が高くなります。この記事では、壊れやすいポイントを押さえながら、成功率が高い順に具体策を整理します。
今回の症状を整理する(切り分けの出発点)
まずは「何が失敗しているのか」を整理すると、やるべき手当ての順番がブレません。質問の状況は次のような組み合わせです。
| 項目 | 内容(例) | 意味合い |
|---|---|---|
| 対象OS | Windows 11 Version 24H2 | 24H2(26100系など)前提で整合する修復ソースが必要 |
| 失敗する更新 | KB5065426 / 26100.6584 | 累積更新(LCU)で詰まる=コンポーネントストアや更新経路の破損が疑わしい |
| 代表エラー | 0x800f081f | 「必要なソースが見つからない/部品が欠けている」系で出やすい |
| 追加症状 | Windows Update トラブルシューティングが動作しない | トラブルシューティング側の依存部品も壊れている可能性 |
| 修復インストール | SAFE_OS フェーズの MIGRATE_DATA で失敗 | 更新処理が WinPE/一時OS側で止まる=ドライバー/暗号化/ディスク/移行対象データが絡みやすい |
結論から言うと、0x800f081f は「コンポーネントストア(WinSxS)破損・不足」か「修復ソース不足(DISM のソースが合っていない)」が主因になりやすく、その状態で何度も更新を繰り返すと失敗履歴・キャッシュが増えて状況が悪化しやすいです。だからこそ、闇雲に「再試行」よりも、順番を決めて修復します。
作業前にやっておくと失敗率が下がるチェック
以下は「根本修復」ではありませんが、失敗率を下げたり、ログが取りやすくなったりするための前提整理です。特に SAFE_OS / MIGRATE_DATA で止まるケースでは効きやすい項目です。
| チェック項目 | 目安 | 理由 |
|---|---|---|
| 空き容量 | システムドライブ(C:)に 30GB 以上 | 更新の展開・退避・ロールバック領域が足りないと SAFE_OS 側で失敗しやすい |
| 外付け機器 | USBメモリ/外付けHDD/SDカード/ドングル類は外す | 起動デバイス順やドライバーが絡み、セットアップの誤判定を招くことがある |
| セキュリティソフト | 可能なら一時的に停止、難しければアンインストールも検討 | フィルタードライバーが MIGRATE_DATA(データ移行)を邪魔する定番要因 |
| BitLocker/デバイス暗号化 | 有効なら回復キーの控え+一時停止を検討 | SAFE_OS での移行・再起動で暗号化状態が絡むと失敗するケースがある |
| ドライバー/BIOS | 特にストレージ(NVMe/IRST/RAID)関連を優先して更新 | SAFE_OS はドライバー互換性にシビア。古いストレージ周りがボトルネックになりがち |
| 重要データのバックアップ | ユーザーフォルダー+業務データは別媒体へ | 修復の途中で最終手段(クリーン)が必要になっても戻れるようにする |
0x800f081f が示すもの(更新失敗の“芯”)
0x800f081f は、Windows の更新や機能追加、DISM の修復などで頻出するエラーです。共通しているのは、Windows が「必要な部品(コンポーネント)」を見つけられない状態になっていることです。
- コンポーネントストア(WinSxS)の破損:更新の差分を適用するための“部品置き場”が壊れている、または整合性が取れていない。
- 修復ソースの不足:DISM が修復に必要なファイルを Windows Update から取得できない、あるいはローカルソースが OS と一致していない。
- ポリシー/ネットワークの制約:企業PCで WSUS 運用、プロキシ、帯域制限、セキュリティ製品などにより修復に必要な取得が遮られている。
ポイントは、「SFC だけ」「キャッシュ削除だけ」では直りきらないことがある点です。まず DISM でコンポーネントストアを正し、次に SFC でシステムファイルを整える。この順番が基本になります。
対処は“成功率が高い順”に進める
ここからは実際の手順です。実行順に意味があります。途中で改善したら、後ろの手順は無理に全部やる必要はありません。
DISM → SFC の基本修復(まずここ)
管理者のコマンドプロンプト(または PowerShell 管理者)で実行します。
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
完了後は再起動し、KB5065426 を再試行します。ここでポイントになるのが、DISM が途中で 0x800f081f で失敗する場合です。その場合は次の「修復ソース指定」がほぼ必須になります。
DISM を“正しいソース”で通す(0x800f081f 対策の本丸)
0x800f081f が出る環境では、DISM が Windows Update から修復部品を取れないことがあります。そこで、Windows 11 24H2 の ISO(同一バージョン)を修復ソースとして指定します。
| やること | ポイント |
|---|---|
| Windows 11 24H2 の ISO を用意 | “同じ 24H2” かつ “同じ言語・同じエディションに近いもの” を選ぶ(Home/Pro など) |
| ISO を Windows 上でマウント | エクスプローラーで ISO を右クリック → 「マウント」 |
| install.wim / install.esd を確認 | マウントしたドライブの sources フォルダーにある |
次に、WIM/ESD の “インデックス” を確認します(エディションごとに番号が違うため)。ドライブ文字を D: と仮定します。
DISM /Get-WimInfo /WimFile:D:\sources\install.wim
install.esd の場合はこちら。
DISM /Get-WimInfo /WimFile:D:\sources\install.esd
表示された一覧から、使用中の Windows エディション(例:Professional)に該当するインデックス番号を選び、次のように実行します。
DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:6 /LimitAccess
ESD の場合は wim を esd に置き換えます。
DISM /Online /Cleanup-Image /RestoreHealth /Source:esd:D:\sources\install.esd:6 /LimitAccess
/LimitAccess を付けることで、Windows Update へ取りに行かず ISO を優先できます。完了したら再度 SFC を実行します。
sfc /scannow
この一連が通ると、更新エラーの根本(部品不足)が解消され、KB の適用が通るケースが多いです。
コンポーネントストアの整理(修復後の“詰まり”を減らす)
修復が通った後でも、部品置き場の肥大化や古い差分が残っていると更新が不安定になることがあります。次を実行して整理します。
DISM /Online /Cleanup-Image /StartComponentCleanup
さらに状態確認をしたい場合は次も有効です(確認のみ)。
DISM /Online /Cleanup-Image /AnalyzeComponentStore
Windows Update コンポーネントをフルリセット(キャッシュ破損を潰す)
質問文では最小構成のリセット(Download フォルダー削除)を行っていますが、改善しない場合は “もう少し徹底したリセット” が効くことがあります。管理者のコマンドプロンプトで、以下を順に実行します。
net stop wuauserv
net stop bits
net stop cryptsvc
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start msiserver
net start cryptsvc
net start bits
net start wuauserv
再起動後に Windows Update を実行します。SoftwareDistribution.old や catroot2.old は更新が成功してしばらく問題がなければ削除して構いません(すぐ消す必要はありません)。
Microsoft Update Catalog から KB を手動インストール(経路変更)
Windows Update 経由が詰まる場合でも、Microsoft Update Catalog から該当 KB(x64/ARM64 など)をダウンロードして手動適用すると通ることがあります。これは “更新の通り道” を変える方法です。
- 「Microsoft Update Catalog」で KB5065426 を検索
- 自分の環境に合うアーキテクチャ(多くは x64)を選んでダウンロード
- ダウンロードした
.msuをダブルクリックしてインストール
手動インストールでも 0x800f081f になる場合は、やはりコンポーネントストア修復(DISM ソース指定)側が未解決の可能性が高いです。
修復インストールが SAFE_OS / MIGRATE_DATA で失敗する時の追加策
ここが今回の「もう一段深い」ポイントです。修復インストール(上書きアップグレード)が SAFE_OS フェーズで止まる場合、Windows Update の問題に加えて、移行対象データ、ドライバー、暗号化、ディスク状態が絡んでいることがあります。
上書きアップグレードを正しい手順で実施できているか確認
同じ「ISOを使う」でも、手順を間違えるとクリーン寄りになったり、移行が増えて失敗率が上がったりします。基本は次の流れです。
| 推奨 | 手順 | 狙い |
|---|---|---|
| ◎ | Windows 上で ISO をマウント → setup.exe 実行 → 「個人用ファイルとアプリを引き継ぐ」 | 更新経路だけ変えて OS を修復しやすい |
| △ | インストール アシスタントを使用 | 手軽だが、環境によっては途中で同じ壁に当たる |
| ×(今回の趣旨では避ける) | USB から起動してセットアップ | クリーンインストール寄りになり、想定外のデータ移行や削除が起きやすい |
よくある混同として、Media Creation Tool を開いても「Upgrade this PC」が見当たらないケースがあります。Media Creation Tool は主に ISO/USB の作成を目的にするツールなので、上書きアップグレードは ISO をマウントして setup.exe から行うのが分かりやすいです。
クリーンブートで「邪魔する常駐・ドライバー」を減らす
SAFE_OS / MIGRATE_DATA は、セキュリティ製品・バックアップ製品・仮想化・ストレージ管理ツールなどの影響を受けやすい工程です。まずはクリーンブートで変数を減らします。
- Win + R →
msconfig→ 「サービス」タブ - 「Microsoft のサービスをすべて隠す」にチェック → 「すべて無効」
- 「スタートアップ」→ タスクマネージャーを開き、不要なスタートアップを無効
- 再起動 → 修復インストール(ISO の
setup.exe)を再試行
成功したら、必要なものから戻します。失敗した場合でも、ログがより“純粋な形”で残り、原因が追いやすくなります。
暗号化(BitLocker / デバイス暗号化)の扱いを見直す
BitLocker が有効な状態でも更新は可能ですが、SAFE_OS 側での再起動や移行で引っかかることがあります。次を確認してください。
- 回復キーを控える(Microsoft アカウント/AD/紙控えなど)
- 可能なら一時停止(「保護の中断」)を検討し、更新・修復後に再開する
組織ポリシーで変更できない場合は無理に触らず、後述のログ採取で原因を特定します。
ディスクの整合性を先に直す(MIGRATE_DATA の定番対処)
MIGRATE_DATA はファイル移行が絡むため、ファイルシステムの軽微な不整合でも失敗することがあります。次を実施します。
chkdsk C: /scan
エラーが出る、または修復が必要と言われた場合は、次を実行します(再起動が必要です)。
chkdsk C: /f
その後、DISM → SFC をもう一度実行し、修復インストールを試します。
移行対象データで詰まるケース(OneDrive/リダイレクト/長いパス)
SAFE_OS / MIGRATE_DATA で止まる原因が「ファイルそのもの」のこともあります。特に次の条件があると要注意です。
- ユーザーフォルダーが OneDrive と強く連携している(既知のフォルダー移動/KFM)
- ドキュメントやデスクトップがネットワークドライブ/別パーティションにリダイレクトされている
- 非常に長いパス、特殊文字、アクセス権が壊れたフォルダーがある
- ジャンクション/シンボリックリンクを多用している(開発環境など)
対策としては、更新・修復の間だけでも次を検討します。
- OneDrive の同期を一時停止、可能ならサインアウト(更新後に戻す)
- ネットワーク経由のフォルダーリダイレクトを一時的に解除できるなら解除
- 容量の大きいフォルダー(例:仮想マシン、node_modules、巨大アーカイブ)を一時退避
「触るのが怖い」場合は無理に移行対象をいじらず、ログから“どのパスでコケたか”を拾う方が安全です。
ストレージ/ネットワーク系ドライバーを最新化する
SAFE_OS で止まるときは、ストレージ(NVMe、SATA、RAID、IRST)やネットワーク(VPN、仮想NIC)関連が絡むことが多いです。更新候補の優先度は次の順が目安です。
| 優先 | 対象 | 理由 |
|---|---|---|
| 高 | BIOS/UEFI、チップセット、ストレージコントローラ | SAFE_OS のブートとディスクアクセスの安定性に直結 |
| 中 | GPU ドライバー | 必須ではないが、セットアップ画面の不具合や TDR を避ける意味で更新する価値あり |
| 中 | VPN/仮想化(VirtualBox/VMware など) | 仮想NICやフィルターが移行工程の邪魔になる場合がある |
| 低 | 周辺機器ドライバー | まずは外して切り分ける。必要なら後で更新 |
企業PCでは勝手に更新できないこともあります。その場合は、サポート(情シス)へ「SAFE_OS / MIGRATE_DATA で失敗する」ことと、該当ドライバーのバージョンを添えて相談すると通りやすいです。
SMB(NAS接続)の話:SMB1 を入れようとして失敗する場合
NAS に接続したい目的で SMB を有効化しようとしている場合、まず大前提として Windows 11 は SMB2/SMB3 は既定で有効です。もし NAS が SMB1 しか対応していない場合、SMB1 はセキュリティ的にリスクが高いため、可能なら NAS 側設定を SMB2/SMB3 に引き上げるのが基本です。
そして重要なのが、SMB1 の追加(Windows の機能追加)が失敗する状況は、今回の 0x800f081f と同根であることが多い点です。つまり、SMB をいじる前に DISM(ソース指定)→ SFC でコンポーネントストアを正常化する方が先です。
原因特定を一気に進めるログの取り方(サポートに出す材料)
ここまでやっても改善しない場合、闇雲に操作を増やすより、ログで「何が不足/拒否/失敗しているか」を押さえた方が早く解決します。代表的なログは次のとおりです。
| ログ | 場所 | 見るべきキーワード例 |
|---|---|---|
| CBS.log | C:\Windows\Logs\CBS\CBS.log | 0x800f081f、Cannot repair、Missing payload、Component store corruption |
| DISM.log | C:\Windows\Logs\DISM\dism.log | Source not found、Error、0x800f081f |
| WindowsUpdate.log | PowerShell の Get-WindowsUpdateLog で生成 | FATAL、WARNING、download、handler、0x |
| セットアップログ | C:\$WINDOWS.~BT\Sources\Panther\ | SAFE_OS、MIGRATE_DATA、setuperr.log、setupact.log |
質問文にある CBS ログ収集はとても有効です。PowerShell(管理者)でまとめて ZIP 化できます。
Compress-Archive -Path "C:\Windows\Logs\CBS\*" `
-DestinationPath (Join-Path ([Environment]::GetFolderPath('Desktop')) "CBS.zip") -Force
追加で DISM.log も一緒に取りたい場合は、次のようにフォルダー単位でまとめると解析がしやすくなります。
Compress-Archive -Path "C:\Windows\Logs\DISM\*" `
-DestinationPath (Join-Path ([Environment]::GetFolderPath('Desktop')) "DISM.zip") -Force
修復インストールの失敗(SAFE_OS / MIGRATE_DATA)まで含めて切り分けるなら、Panther フォルダーのログも重要です。存在する場合は次を ZIP 化します。
Compress-Archive -Path "C:\$WINDOWS.~BT\Sources\Panther\*" `
-DestinationPath (Join-Path ([Environment]::GetFolderPath('Desktop')) "Panther.zip") -Force
これらを揃えると、「どのコンポーネントが欠けているのか」「どのファイル移行で止まったのか」が分かり、対処が一気に具体化します。
よくある質問(詰まりどころ)
DISM が 0x800f081f のまま進みません
この場合は、ISO のバージョン不一致やインデックス違いが多いです。次を見直してください。
- ISO が 24H2 であること(できれば現在のビルドに近い)
- install.wim / install.esd のインデックス番号がエディションに合っていること
- ドライブ文字(D: など)が実際のマウント先と一致していること
Windows Update トラブルシューティングが動きません
トラブルシューティング自体も OS の部品に依存するため、コンポーネントストアが壊れていると正常に動かないことがあります。先に DISM(ソース指定)→ SFC を優先し、必要なら Update コンポーネントのリセットを行う方が近道です。
上書きアップグレードは最後の手段ですか?
今回のように Windows Update 経由が詰まり、しかも OS 修復系も不安定な場合、上書きアップグレードは「最後」ではなく有力な迂回路です。ただし SAFE_OS / MIGRATE_DATA で失敗するなら、クリーンブート・暗号化・ストレージドライバー・ディスク整合性など、環境要因の除去が先になります。
最終手段を選ぶ前に:ここまでやれば“やり残し”が少ない
最後に、再試行の前に実施できているかをチェックリスト化します。ここまで押さえると、個人でできる範囲としてはかなり網羅的です。
| チェック | 実施内容 | 狙い |
|---|---|---|
| コンポーネント修復 | DISM(ISO ソース指定)→ SFC | 0x800f081f の根本原因を潰す |
| 更新経路の整理 | SoftwareDistribution/Catroot2 のリセット | キャッシュ破損の影響を排除 |
| 環境変数の排除 | 外付けを外す、クリーンブート、セキュリティ製品の影響を減らす | SAFE_OS / MIGRATE_DATA の失敗要因を減らす |
| ディスク健全性 | chkdsk、空き容量確保 | 移行工程の土台を安定させる |
| ログ採取 | CBS/DISM/Panther を ZIP 化 | 原因特定を最短化する |
それでも KB5065426 の適用や修復インストールが通らない場合は、ログに基づく個別解析(特定ファイル/特定ドライバー/特定コンポーネント)が必要です。サポートへ相談する際は「0x800f081f」「SAFE_OS / MIGRATE_DATA」「CBS.zip / DISM.zip / Panther.zip を取得済み」を伝えると、やり取りがスムーズになります。

コメント