DISMでStorageManagement機能追加が失敗する原因と対処法（0x800f081f・ソース不一致・コンポーネントストア修復）

DISMでRSAT（例：Rsat.WSUS.Tools）は追加できるのに、StorageManagement（Microsoft.Windows.StorageManagement / Microsoft.OneCore.StorageManagement）だけが「ソースが見つからない」「コンポーネントが壊れている」などで失敗し、修復に詰まってインプレース再インストールへ進みがちなケースを、原因の切り分けと現実的な修復手順として整理します。

起きていることを整理する（この症状の“クセ”）

まず前提として、同じ「/add-capability」でも、機能ごとに取得元（Windows Update / WSUS / ローカルソース）や依存関係が微妙に異なります。そのため「ある機能は入るのに、特定の機能だけ入らない」は珍しくありません。

観測される状況	ポイント	よくある落とし穴
Rsat.WSUS.Tools は追加できる	DISM自体が壊れているとは限らない	StorageManagementが別ソース（FOD）依存／依存パッケージ不足
StorageManagementだけ「ソースが見つからない」	最優先はソース不一致の疑い	/LimitAccess の有無より、ソースの中身が合っていない
AnalyzeComponentStore / StartComponentCleanup は正常	WinSxSの大規模破損とは限らない	“整合性OK”でも、機能追加に必要なpayloadが手に入らないことがある
sfc /scannow も問題なし	システムファイルは概ね健全	“修復用ソース”と“追加する機能のソース”は別問題になりやすい
SeaGateツールだけ容量を誤認っぽい	ストレージAPI／ドライバー側の線も残る	ディスクは正常でも、管理層（ドライバー/フィルター/RAID）でズレが出る

質問にある「System Volume Information（SVI）や些細な不整合が原因では？」という発想は筋が悪くありません。ただし実務的には、“ちょっとした不整合だけ”でStorageManagementのCapabilityだけが継続的に落ちるよりも、次のような複合要因で説明できることが多いです。

• Capability名や指定記号（~~~~）のミス
• ISO/メディアのビルド不一致、またはFOD（Features on Demand）不足
• コンポーネントストアは整合していても、追加に必要なpayload取得経路が詰まっている
• WSUS/ポリシーで「オプション機能の取得」だけブロックされている
• ストレージ管理系のWMI/Storageサービス、またはストレージコントローラ周りの歪み

DISMでやっている操作の種類を押さえる

似た言葉が多いので、混乱を防ぐために整理します。

操作	代表コマンド	意味	つまずきポイント
Capability追加	dism /online /add-capability	“Windowsの追加機能（FOD含む）”を追加	ソースの中身・WSUS制御・依存関係で失敗しやすい
Windows機能（Feature）ON	dism /online /enable-feature	既にある機能を有効化（.NETなど）	payloadが未取得だとソースが必要
パッケージ直入れ	dism /online /add-package	CAB/MSUを直接投入	依存CABが複数必要な場合がある

最短で切り分けるためのチェックリスト

闇雲に修復を回すより、「存在確認 → エラーの種類 → ソース一致 → 修復 → 強制投入」の順で詰める方が早いです。

チェック	確認内容	判断
CapabilityがOSに存在するか	Get-WindowsCapability / DISMで一覧確認	一覧に出ないなら、そもそも対象ビルドでは扱いが違う可能性
エラーコード（0x800f…）	dism.log / 画面出力	0x800f081fならソース不備が濃厚
ソース（ISO/FOD）がビルド一致か	install.wim/esdのビルド・エディション	ここがズレると“特定の機能だけ”失敗しやすい
WSUS/ポリシーで取得経路が詰まっていないか	社内PC/ドメイン配下で多発	RSATが入っても、別系統が落ちることがある
コンポーネントストア修復	RestoreHealth + SFC	“軽微な破損”やpending状態を除去
CAB直指定で回避できるか	/add-package	Capability解決に失敗しているだけなら突破口

機能名・書式の再確認（ここで直ることもある）

初歩に見えて、現場で一番多いのがここです。特にStorageManagementのCapability名は見た目が似ていて、記号の打ち間違いが起きがちです。

• 区切りは「~~~~」です（ハイフンや三つ線ではありません）。
• 管理者権限のコマンドプロンプト／PowerShellで実行します。

dism /online /add-capability /capabilityname:Microsoft.OneCore.StorageManagement~~~~0.0.1.0
dism /online /add-capability /capabilityname:Microsoft.Windows.StorageManagement~~~~0.0.1.0

加えて「そのCapabilityが本当に“今のOSで扱える状態”か」を確認します。

dism /online /get-capabilities | findstr /i storagemanagement
dism /online /get-capabilityinfo /capabilityname:Microsoft.Windows.StorageManagement~~~~0.0.1.0

PowerShellが使える場合は、一覧・状態確認が見やすいです。

powershell -NoProfile -Command "Get-WindowsCapability -Online | Where-Object {$_.Name -like '*StorageManagement*'} | Select-Object Name, State | Format-Table -Auto"

ここでStateが「NotPresent」なら追加対象、「Installed」なら既に入っています。「Staged」は“取り込み済みだが完全有効化前”のような中間状態として現れることがあります（環境差あり）。

エラーコードの意味をざっくり掴む（次の一手が変わる）

「ソースが見つからない」「コンポーネントが壊れている」といった文言は、実際には複数の原因が同じ見え方をします。エラーコードで方向性を決めるのが安全です。

代表的なコード	見え方	濃厚な原因	優先対応
0x800f081f	ソースファイルが見つからない	ソース不足／FOD不足／ビルド不一致	ISO/FODの一致確認、/Source見直し
0x800f0954	取得に失敗（環境依存）	WSUS配下でオプション機能取得が詰まる	ポリシー変更（WUから直接取得）
0x80073712	コンポーネントストア破損扱い	WinSxSの破損・更新の中途半端	RestoreHealth（正しいソース指定）→SFC
0x800f0831	必要な更新/依存がない	依存パッケージ不足、更新の欠落	最新CU適用、ログで依存特定
0x80070002 / 0x80070003	ファイル/パスがない	指定パス誤り、メディア構成違い	メディア構造確認、パス再指定

どのコードか分からない場合は、後述の「ログの見方」でdism.logから拾うのが確実です。

ソース（ISO/メディア/FOD）の一致確認が最重要

StorageManagementだけが落ちるケースで一番多いのは、追加に必要なパッケージが“そのソースに入っていない”、またはビルドが一致していない状態です。

結論：「WindowsのインストールISOをマウントした」だけでは、Capability追加に必要なものが揃わないことがあります。特にオプション機能は、FOD（Features on Demand）ISOが別で必要になる環境があります。

OS側のバージョン・エディションを固定する

まず対象PCの情報を採取します。

winver
systeminfo | findstr /b /c:"OS 名" /c:"OS バージョン"
dism /online /get-currentedition

インストールメディア側のビルド・エディションを確認する

ISOをマウントしてドライブ文字を仮にG:とします（環境に合わせて読み替えてください）。install.wim が無く install.esd の場合もあります。

dism /get-wiminfo /wimfile:G:\sources\install.wim

ここで表示されるインデックス（Index）とエディション（例：Pro/Enterprise）が、OSと噛み合っているかを見ます。エディションが違う・世代が違う（例：21H2のPCに22H2のメディア）だと、特定パッケージだけ解決できずに落ちることがあります。

メディア構造の目安（よくある見落とし）

「sources\sxsがあるからOK」と思いがちですが、そこに入っているのは主に“Windows機能（Feature）向けのコンポーネント”で、Capabilityすべてを賄えない場合があります。

ソースの種類	よくあるパス	得意な用途	注意点
通常のWindowsインストールISO	G:\sources\install.wim / G:\sources\sxs	RestoreHealthの修復ソース、Featureの有効化	Capabilityのpayloadが不足することがある
FOD ISO（Features on Demand）	（ISO内のCab群）	RSATや言語、オプション機能のpayload	OSのビルド/言語に厳密に合わせる必要がある
Windows Update（インターネット）	オンライン取得	不足分を自動取得	/LimitAccessで遮断される。企業NWだと到達できないことも
WSUS	社内更新サーバー	更新配布	オプション機能の取得が制限され、0x800f0954系が出やすい

コンポーネントストア修復（“正常”でも一度揃え直す）

AnalyzeComponentStoreやSFCが問題なしでも、更新の取り込み順やpayload解決の齟齬で、特定Capabilityだけが失敗することがあります。ここは“やり直し”の価値があります。

クリーンアップ

dism /online /cleanup-image /startcomponentcleanup

正しいインストールイメージをソースにしてRestoreHealth

インデックス番号は、先ほどの /get-wiminfo で確認して合わせます。

dism /online /cleanup-image /restorehealth /source:G:\sources\install.wim:1 /limitaccess

install.esdの場合の例：

dism /online /cleanup-image /restorehealth /source:G:\sources\install.esd:1 /limitaccess

最後にSFC

sfc /scannow

この流れの狙いは、「壊れているかどうか」ではなく、“現在のOS状態”と“修復ソース”の整合を取り直すことです。StorageManagementだけが落ち続ける場合でも、ここで復帰することがあります。

WSUS/社内ポリシーが絡む場合の対処（RSATが入っても油断しない）

ドメイン参加端末や社内ネットワークでは、Windows Updateの経路が制御されていて、更新は取れているのにオプション機能だけ取得できないことがあります。典型例が0x800f0954系です。

管理対象端末でよく見るのが、グループポリシー「オプションコンポーネントのインストールとコンポーネント修復の設定」による挙動差です。可能なら次の方針に寄せます。

• オプション機能の修復コンテンツをWSUSではなく、Windows Updateから直接取得する設定を許可する
• または、FOD ISOを社内共有し、/Sourceで必ずそこを参照する運用に寄せる

レジストリで一時的にWSUS参照を切り替える手法もありますが、組織ポリシーに抵触する場合があるため、運用ルールに従ってください（ここでは詳細は割愛します）。

System Volume Information（SVI）とVSSの観点（“原因になり得る”範囲を見極める）

SVIは復元ポイントやシャドウコピー（VSS）などが利用する領域で、権限や内部データの不整合があると、更新やバックアップ周りで副作用が出ることがあります。ただし、StorageManagementのCapability追加失敗の主因は、SVI単体よりもソース不一致・取得経路詰まりであるケースが多いです。

まずは“破壊的でない”確認から

chkdsk /scan
vssadmin list writers
vssadmin list shadows

• vssadmin list writersでエラーが多い場合、SVIやVSS周りの整合が崩れている可能性があります。
• chkdskが短時間で正常でも、VSS writer側で詰まるケースはあります。

復元ポイント／シャドウコピーの整理（影響はあるが比較的コントロールしやすい）

注意：復元ポイントが消えます。運用上問題がない状況でのみ実施してください。

vssadmin delete shadows /all /quiet

SVIの権限リセット（takeown / icacls）は、環境によっては副作用が大きく、復元機能の挙動に影響することがあります。実施するなら「最終手段寄り」として、バックアップと影響範囲の理解が前提です。まずは上の“非破壊チェック”と“シャドウ削除”までで状況が変わるかを見た方が安全です。

CapabilityがダメならCAB直入れで突破する（/add-package）

/add-capability が「名前解決」や「取得経路」で詰まっているだけなら、メディア内のCABを直接指定して回避できることがあります。

CABを探す

マウントしたISOやFODメディア内から、StorageManagementを含むCABを検索します。

dir /s /b G:\*.cab | findstr /i storagemanagement

PowerShell例：

powershell -NoProfile -Command "Get-ChildItem -Path G:\ -Recurse -Filter *.cab -ErrorAction SilentlyContinue | Where-Object {$_.Name -match 'StorageManagement'} | Select-Object -First 30 FullName"

見つけたCABを指定して追加

dism /online /add-package /packagepath:"G:\(見つけたパス)\xxxxxx.cab"

この方法は強力ですが、パッケージによっては依存CABが複数必要な場合があります。追加後は、次のように状態を確認し、必要に応じて追加の依存パッケージを投入します。

dism /online /get-capabilities | findstr /i storagemanagement

ストレージドライバー／ハードウェア側の診断（SeaGateツールの違和感を放置しない）

SeaGateツールだけが容量や空き領域を誤って読んでいるように見える場合、ディスク自体の故障だけでなく、ストレージ管理APIに渡る情報がどこかで歪んでいる可能性があります。特に以下の条件があると差が出やすいです。

• Intel RST / RAID / ストレージコントローラの独自ドライバーを利用している
• フィルタードライバー（暗号化、バックアップ、仮想化系）が挟まっている
• パーティション構成が特殊（多重ブート、ベンダー領域、ストレージスペース）

ドライバーの棚卸し（最低限）

pnputil /enum-drivers
driverquery /v | findstr /i "stor"

できればデバイスマネージャーで以下を重点的に確認します。

• 「記憶域コントローラー」「IDE ATA/ATAPI コントローラー」配下のデバイス名
• ドライバー提供元（Microsoft / Intel / メーカー独自）とバージョン

SMART/診断の追加観点

chkdskが正常でも、SMARTの生値やエラーカウントに兆候が出ていることがあります。SeaToolsやsmartmontools（smartctl）で確認し、異常があれば先にディスク／ケーブル／ケース（USB-SATA変換等）まで含めて切り分けます。

観測	疑うべき層	やること
OSは正常、特定ツールだけ誤認	ツールの互換性 / API依存	ツールを最新版へ、別ツールでも再現確認
複数ツールで値がブレる	ドライバー / フィルター	ストレージコントローラ更新、不要フィルターの除外検証
SMARTに警告兆候	ディスク本体	バックアップ優先、交換判断

ログで“どのファイル／パッケージで死んでいるか”を特定する

最終的にはログが一番確実です。StorageManagementの追加が失敗する場合、dism.logに「どの段階で」「何を探して」「見つからなかったか」が出ます。

• DISMログ：C:\Windows\Logs\DISM\dism.log
• コンポーネント（CBS）ログ：C:\Windows\Logs\CBS\CBS.log

GUIで追うより、フィルタして“当たり”を拾うのが早いです。

findstr /i /c:"error" /c:"0x800f" C:\Windows\Logs\DISM\dism.log > "%USERPROFILE%\Desktop\dism_error.txt"
notepad "%USERPROFILE%\Desktop\dism_error.txt"

ログに「探しているcab名」「参照しているパス」「失敗コード」が出るので、次の判断ができます。

• 参照パスがISOではなくWindows Updateを向いている → /LimitAccess や /Source の設計を見直す
• 参照パスは正しいがcabが無い → そのソースにStorageManagementのpayloadが無い（FOD不足）
• cabはあるのに適用で落ちる → 依存パッケージ不足、またはコンポーネントストア側の問題

Windows Updateコンポーネントのリセット（修復が進まないときの現実解）

DISM/SFCを正しいソースで回しても改善せず、ログ上も更新コンポーネント周りの詰まりが疑われる場合は、Windows Update関連フォルダーの再初期化が効くことがあります。

注意：更新履歴表示などに影響が出る場合があります。業務PCでは運用ルールに従ってください。

net stop wuauserv
net stop bits
net stop cryptsvc

ren C:\Windows\SoftwareDistribution SoftwareDistribution.bak
ren C:\Windows\System32\catroot2 catroot2.bak

net start cryptsvc
net start bits
net start wuauserv

この後に再度、RestoreHealth → add-capability を試します。

どうしても直らないときの判断（インプレース再インストールの位置付け）

ここまでの「ソース一致の再確認 → RestoreHealth/SFC → 取得経路（WSUS/ポリシー） → CAB直入れ → ドライバー周り」までやっても、StorageManagementだけが頑固に失敗し続ける場合、インプレースアップグレード（上書きインストール）は現実的な選択肢です。

ただし、インプレースは“万能薬”ではなく、原因がソース不一致や取得経路にある場合は、同じ設計のまま繰り返すと再発します。実行前に次の2点だけは押さえておくと、やり直しが減ります。

• 使用するISOは、対象PCのエディション/言語/ビルドに揃える
• 企業環境なら、オプション機能の取得がWSUSで詰まるかどうかを事前に確認する

まとめ（この記事の結論）

• StorageManagementだけが落ちる現象は、SVIの“些細な不整合”単体よりも、ソース不一致・FOD不足・取得経路詰まり（WSUS/ポリシー）の影響が濃厚です。
• 最短ルートは、Capabilityの存在/状態確認 → エラーコード把握 → ソース一致確認 → RestoreHealth（正しいソース）です。
• /add-capabilityが詰まるなら、CAB直指定（/add-package）が突破口になります。
• SeaGateツールの誤認があるなら、ストレージコントローラ/フィルタードライバーも並行して疑い、診断と更新を進めるのが安全です。
• 上記を尽くしても改善しない場合に、最後のカードとしてインプレース再インストールを検討します。