DISM /RestoreHealthの進捗が動かなくても、表示だけでフリーズとは判断できません。修復元の検索、Windows Updateからの取得、コンポーネントの処理中は、同じ割合や無表示の状態が続くことがあります。まず活動とログを確認し、エラーで終了した場合はコードに応じて修復ソースを見直します。
安全な基本順序は管理者のコマンドプロンプトでDISMを実行し、成功後にSFCです。「何分で止める」という共通の基準はありません。容量、ストレージ、破損状態、通信条件が違うため、電源を切ったり修復コマンドを何本も同時実行したりせず、終了メッセージまで確認してください。
イメージのバージョンだけ・62.3%・100%から進まない場合
DISMが100%と表示されても、成功メッセージが出て処理が終了するまでは、修復成功と判定できません。
| 表示 | 確認すること |
|---|---|
| Version / Image Versionだけで進捗が出ない | これはツールと対象イメージの情報。表示だけでは修復の成功・失敗を判定しない。 |
| 一定の割合で動かない | その実行時刻のログとサービス側の活動を合わせて確認する。 |
| 100%でもプロンプトが戻らない | 最後の成功/失敗/再起動要求が出るまで確認する。 |
| 100%の後にエラーが出た | 割合よりエラー全文とログを優先し、修復元・通信等を調べる。 |
| スクリプトで実行して何も表示されない | Quiet指定、出力のリダイレクト、実行したコマンド全文を確認する。 |
DISMの公式オプションでは、/Quietはエラー以外の情報・進捗表示を抑えます。無表示を検証する際は、実行中の処理を重ねず、終了後にコマンド全文を確認します。無表示や割合が同じという条件だけで、30分・1時間など一律の強制終了時間は決められません。
進まないときに、最初に確認する4つのこと
- 電源と保存:ノートPCは電源に接続し、作業中のデータを保存します。重要なファイルのバックアップと、暗号化端末の回復キーを確認します。
- 更新と再起動:Windows Updateが再起動を要求している場合は、現在の修復処理が終了してから通常の再起動で完了させます。
- 空き容量と通信:システムドライブの空き容量、Windows Updateの利用可否、組織のプロキシや修復元ポリシーを確認します。
- 実行中の処理:別のDISM・SFC・更新処理を重ねて始めていないか確認します。ひとつの処理が終わってから次へ進みます。
大きな修復を始める前の備えは、Windows 11のシステムイメージバックアップと復元を参照してください。読み書きエラーや異音などストレージ故障の疑いがある場合は、修復の反復よりデータの保全を優先します。
表示が止まっているか、処理が続いているかを確認する
タスクマネージャーでCPU・ディスク・ネットワークの活動を確認します。dism.exeだけでなく、Windowsのサービス側でも処理が行われるため、ひとつのプロセスが低負荷という理由だけでは停止と断定できません。ログの更新時刻や末尾の内容も合わせて見ます。
| 確認対象 | 見方 |
|---|---|
| %windir%\Logs\DISM\dism.log | DISMの実行・ソース取得・エラーを確認。末尾と更新時刻を比較する |
| %windir%\Logs\CBS\CBS.log | コンポーネントの処理やSFCの結果を確認する |
| コマンド画面 | 終了してプロンプトが戻ったか、成功・エラー・再起動要求があるか |
ログは過去の実行も含みます。対象の開始時刻以降を確認し、Errorという単語ひとつで全体を失敗と判断しないでください。コンソールが文字の選択状態になっている場合はEscで選択を解除して表示を確認します。処理時間だけで強制終了する判断はできません。
ログの末尾と更新時刻を読み取る
Microsoftのログ資料では、DISM.logがオンライン処理の主なログ、CBS.logが詳細なサービス処理のログです。PowerShellなら次の例で更新時刻と末尾を読み取れます。これは別の修復を開始するコマンドではありません。
Get-Item -LiteralPath "$env:windir\Logs\DISM\dism.log" |
Select-Object FullName,LastWriteTime,Length
Get-Content -LiteralPath "$env:windir\Logs\DISM\dism.log" -Tail 40
Get-Content -LiteralPath "$env:windir\Logs\CBS\CBS.log" -Tail 40
/LogPathで別の保存先を指定した場合は、そのファイルを確認してください。既定のログには過去の処理も残り、更新時刻だけでも正常終了は証明できません。コマンドを開始した時刻と末尾の内容を合わせ、必要な期間のログを保存してから管理者へ渡します。
基本手順:DISMが終了してからSFCを実行する
スタートで「cmd」を検索し、「コマンドプロンプト」を「管理者として実行」します。実行中のWindowsを修復する基本コマンドは次のとおりです。/Onlineは現在起動しているWindowsを対象にする指定で、インターネット接続の意味ではありません。
DISM.exe /Online /Cleanup-Image /RestoreHealth
「復元操作は正常に完了しました」などの成功結果を確認した後、次を実行します。必要な再起動が案内された場合は、その指示にも従います。
sfc /scannow
/CheckHealthは既に記録されている破損状態の確認、/ScanHealthは破損のスキャンで、どちらも修復そのものではありません。最初にすべての確認コマンドを繰り返す必要はなく、目的に合わせて使います。SFCは検証が100%になるまでウィンドウを閉じず、最後の結果を読みます。
DISMが失敗したら、エラーと修復元を確認する
| 状況・コードの例 | 次に確認すること |
|---|---|
| 0x800f081f/ソースが見つからない | 修復元の内容、バージョン・更新状態、言語、WIMのインデックス、パス |
| ダウンロードや更新元への接続に失敗 | Windows Update、プロキシ、組織の修復元設定。正確なコードとログを確認 |
| アクセス拒否/管理者権限の案内 | 管理者として実行したか、修復元の読み取り権限があるか |
| 修復不可能と判定される | データを保全し、Windowsの修復再インストールなど別の回復手段を検討 |
コードは原因を絞る材料です。同じソース不足でも、ファイルがない場合と、必要なバージョンのコンポーネントが含まれない場合があります。企業PCでは管理者が修復元を指定していることがあるため、更新サービスやグループポリシーを勝手に変更せず、エラー全文を渡してください。
0x800f0906「ソースファイルをダウンロードできませんでした」の確認
MicrosoftのCBSエラー説明では、0x800F0906をCBS_E_DOWNLOAD_FAILURE、0x800F081FをCBS_E_SOURCE_MISSINGとしています。同資料の具体的な導入手順は.NET Framework 3.5向けです。一般のRestoreHealthに、NetFx3の機能追加コマンドや特定の旧WindowsのSxS手順をそのまま適用しません。
- エラーが出たコマンド全文と、DISM/CBSの同じ時刻のメッセージを確認する。
- 修復元としてWindows Updateを使う構成か、組織が指定したパスを使う構成かを確認する。
- 通信・プロキシ・修復コンテンツの取得を管理者と確認する。ブラウザーでWebを開けることだけで、修復サービスの取得成功と判定しない。
- Source指定済みなら、パスと読取権限、必要なコンポーネント・更新状態・言語・インデックスを確認する。
- LimitAccessを付けた場合はWindows Updateから補完されないことを確認し、適合する修復元を準備する。
0906だけでネットワークが唯一の原因、081FだけでISOが壊れた、と確定しません。修復元の構成は公式の修復ソース資料に沿って判断します。WSUS/GPOの一括解除や修復処理中の更新サービス停止を共通の対処にしないでください。
ISO・WIMを修復ソースにする場合の選び方
Microsoft公式のインストールメディアや、組織が用意した修復元を使います。対象Windowsと同じリリース系統・エディション・アーキテクチャ・必要な言語を確認し、更新状態も照合します。対象より古い更新状態のソースでは、必要なファイルが足りず失敗することがあります。「Windows 11のISOなら何でもよい」という選び方はできません。管理者が修復元を準備する場合は、公式資料が案内するRTMメディアを基にした累積更新の適用条件も確認します。新しい配布メディアであっても、必要な旧ファイルが含まれるとは限りません。
winverでWindowsのバージョン・OSビルドを確認し、「設定」→「システム」→「バージョン情報」でエディションとシステムの種類を確認します。- ISOをエクスプローラーでマウントし、ドライブ文字と
sources内のファイルを確認します。下記のD:は例なので実際の文字に置き換えます。 install.wimがある場合は、次のコマンドで収録されているイメージとインデックスを確認します。
DISM /Get-ImageInfo /ImageFile:D:\sources\install.wim
表示されたName・Indexから対象のエディションを選びます。インデックス1を固定で選ばないでください。詳細を確認するときは、調べた番号を/Indexに指定します。次は番号6だった場合の例です。
DISM /Get-ImageInfo /ImageFile:D:\sources\install.wim /Index:6
修復対象とソースの条件が合うことを確認できたら、次のように実行します。:6は例であり、自分のメディアの番号に変更してください。
DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:6 /LimitAccess
/LimitAccessはWindows Updateを修復元・補助修復元として使わない指定です。ソースの不足を解決する機能ではないため、指定したWIMだけで必要な内容を用意できる場合に使います。更新元からの補完が必要な環境では、管理方針に従って選択してください。
install.esdしかない場合も、まずDISM /Get-ImageInfo /ImageFile:D:\sources\install.esdで内容を確認します。ファイルの拡張子をwimへ改名しても形式は変わりません。形式・インデックスの指定に迷う場合は、適合するWIMや読み取り専用でマウントしたWindowsイメージを管理者に用意してもらいます。ISOのドライブ直下や存在しないフォルダーを/Sourceに指定しないでください。
SFCの結果別に次の行動を決める
| SFCの最終結果 | 対応 |
|---|---|
| 整合性違反は検出されなかった | システムファイルの破損は検出されていない。元の症状を別の原因から調べる |
| 破損ファイルを修復した | 必要に応じて再起動し、元の症状が改善したか確認 |
| 一部を修復できなかった | CBSログとDISM結果を確認し、適合する修復元や修復再インストールを検討 |
| 要求された操作を実行できない | Microsoftの案内に沿ってセーフモードでの実行などを検討 |
例えばデスクトップの一部アイコンだけが白い場合、SFC成功後もアプリの更新やショートカットの状態が別の原因で残ることがあります。Windows 11の白いショートカットアイコンの対処のように、残った症状ごとに確認してください。DISM・SFCの成功は、すべてのアプリや設定が正常になったことまで保証しません。
それでも完了しないとき
同じ処理が繰り返し失敗するなら、コマンド、開始時刻、終了コード、ログ末尾、Windowsのバージョン、修復ソースの情報をそろえます。Windows回復環境ではドライブ文字が変わり、BitLocker解除が必要な場合もあります。オフライン修復へ進む場合は対象を確認し、起動中の手順をそのまま当てはめないでください。
修復再インストールを検討する場合も、ファイル・アプリの保持条件とバックアップを確認してから行います。ログを削除する、WinSxSを手動削除する、処理中の電源を切るといった操作を、進捗表示の問題への対処として使わないでください。
公式情報・参考資料
仕様・画面名は更新されるため、対象のアカウント・製品・接続方式を確認してください。以下の公式情報で、対象OSと修復元の条件を確認できます。
- Microsoft:DISMとSFCでシステムファイルを修復:管理者実行とDISM→SFCの順序・結果の判定
- Microsoft Learn:Windowsイメージの修復:CheckHealth/ScanHealth/RestoreHealthとLimitAccess
- Microsoft Learn:Windows修復ソースの構成:修復元の条件とWIMのインデックス
- Microsoft Learn:DISMイメージ管理コマンド:イメージの情報確認とインデックス指定

コメント