1. きっかけ
古いNECのノートPC（Intel Optane Memory 16GB + HDD構成）で、DISM /Online /Cleanup-Image /RestoreHealth を実行したとき、62.3%付近で長時間まったく進まなくなりました。1
タスクマネージャーを見ると、こうなっていました。
- ディスク 0 (C:) のアクティブな時間：100%
- 平均応答時間：470ミリ秒
- 読み取り：368 KB/秒、書き込み：1.7 MB/秒
読み書きの速度自体はそれほど大きくありません。
なのにHDDが100%張り付き、応答時間が数百ミリ秒になっている。
ランダムアクセスが多くて、HDDが処理しきれていない状態です。
「無限ループに入ったのでは」と思うのは、自然なことでした。
1.1. DISM が 62.3% 付近で何をしているか
DISM /RestoreHealth は、Windowsのコンポーネントストアを検査・修復するコマンドです。
コンポーネントストアとは C:\Windows\WinSxS にある、Windowsを構成する部品の保管場所で、破損が見つかれば正常なファイルに差し替えます。2
この処理は、ファイルを1つ読んで終わりではありません。
大量の小さなファイルやメタデータを順に読み込みながら、整合性を確認していきます。
HDDにとって、これは苦手な処理です。
HDDはランダムアクセスが遅く、SSDなら数十マイクロ秒で済む読み取りが、HDDでは数ミリ秒〜十数ミリ秒かかります。
修復対象が多いと、読み書きが積み重なってアクティブ時間が100%に張り付く。
表示上のパーセントが進まないまま、内部では処理が続いている状態です。3
また、/RestoreHealth はデフォルトで Windows Update を修復ファイルの取得元として使います。
Windows Update との通信やダウンロードが発生する場合、ネットワーク速度や更新サービスの状態によっても処理時間が変わります。4
2. 答え合わせ：SSD換装後に再実行した
その後、同じPCのHDDをSSDに換装しました。
起動速度や操作感の改善が主な目的でしたが、ついでにあらためて DISM /RestoreHealth を実行してみました。
すると、また 62.3% 付近で長く止まって見えました。
ただし今回は、タスクマネージャーの数字が違いました。
SSDなのでアクティブ時間は100%にはなっていません。
それでも、同じポイントで時間がかかっています。
そのまま待ち続けると、84.9% まで進みました。
最終的には「復元操作は正常に完了しました」と表示されて終わりました。5
これで、HDDのときに起きていたことがはっきりしました。
62.3% 付近は、DISMが時間をかける処理のポイントです。
HDDの問題ではなく、処理の性質によるものでした。
HDDでも待てば進んでいたはずです。
2.1. HDDのとき「止まっている」と判断しやすい理由
SSDで同じ処理をすると、ディスクは静かです。
アクティブ時間も100%にはならないので、「処理中だろう、待とう」と判断しやすい。
HDDでは、ディスクが100%張り付き、平均応答時間が数百ミリ秒になります。
読み書き速度自体は大きくないのに、PCが重くなったように感じる。
これが「無限ループに入った」「フリーズした」という誤解を生みます。
ディスクが動いている以上、処理は続いています。
見た目の激しさが、判断を狂わせるわけです。
3. 強制終了すべきでない理由
DISM /RestoreHealth は、コンポーネントストアのファイルを書き換えることがあります。
処理途中で強制終了すると修復が中途半端な状態になり、次回の起動時やDISM再実行時に、より深い不整合が起きる可能性があります。
タスクマネージャーで次のどれかが動いていれば、処理中と見てよいです。
dism.exe、TiWorker.exe、TrustedInstaller.exeのCPUまたはディスク使用率が少しでも変化している- ディスクの読み書き速度が変化している
- コマンドプロンプトが応答不能になっていない
2〜3時間以上、ディスク使用率も0%近く、CPUもほぼ0%、読み書きもゼロで変化がないなら、そのときはじめて中断を検討します。6
HDDで 62.3% 付近に来たときの対応は、AC電源をつないでスリープをオフにして放置することです。
目安は 1〜2時間で、状態が重い場合は 3〜4時間かかることもあります。
3.1. SSDに換えたことで得られた副産物
今回、SSD換装は別の理由で行いましたが、結果として「HDDのときに何が起きていたか」を確認できました。
SSDではDISMの全体的な処理時間も短くなります。
HDDで2〜3時間かかっていた作業が、30〜60分程度に収まることが多い。
ただし 62.3% 付近の待ち時間は、SSDでもゼロにはなりません。
ここはDISMの処理の性質によるものなので、ハードウェアを変えても同じポイントで時間がかかります。7
4. まとめ
DISM /RestoreHealth の 62.3% 付近は、処理が重い区間であって、無限ループや異常ではありません。
HDDではランダムアクセスが重なってディスクが100%張り付き、「止まっている」ように見えます。
SSDに換えると、同じ場所でも静かに待てるので判断しやすい。
SSD換装後に再実行して同じポイントで時間がかかり、待ったら進んだことで、HDDのときも「待てばよかった」とわかりました。
強制終了の判断基準は「パーセントが動かない」ではなく、「ディスクもCPUも長時間まったく動いていない」かどうかです。8
- Microsoft Q&A でも同様の報告が多数あります。62.3% で止まって見える現象は複数のWindows 11ビルドで確認されており、「People have been wondering for YEARS why it gets stuck at 62.3%」と表現されるほど広く知られた挙動です。 – DISM RestoreHealth stuck at 62.3% [Info / Resolved]
- コンポーネントストアはWindows Vista以降に導入され、Windows Updateやサービスパック適用のたびに更新されます。更新のたびに古いバージョンのファイルも保持されるため、長く使うほどフォルダサイズが大きくなっていきます。なお、エクスプローラー上で表示されるサイズはハードリンクを考慮しない数値のため、実際の占有量より大きく見えます。 – Manage the Component Store – Microsoft Learn
- Microsoft Q&A の公式回答でも「62.3% で止まって見えるのは、コンポーネントストアの修復に必要なデータを大量に処理しているためで、処理量が多いほど時間がかかる」と説明されています。 – DISM /ONLINE /CLEANUP-IMAGE /RESTOREHEALTH stuck at 62.3% for a long time – Microsoft Q&A
- Microsoftは
/Sourceオプションを使って修復ファイルの取得元をローカルのWindowsイメージに変更できると説明しています。Windows Updateを使わない場合は/LimitAccessを組み合わせます。 – Repair a Windows Image – Microsoft Learn - 処理が正常に完了した場合、コマンドプロンプトには「The restore operation completed successfully.」または日本語環境では「復元操作は正常に完了しました。」と表示されます。この表示が出れば、コンポーネントストアの修復は成功しています。 – DISM Stuck at 62.3% on Windows 11: Fix and Verify
- Microsoft Q&A では「24時間経っても止まったままなら完了しない可能性が高い」とされています。ただし、その段階ではクリーンインストールではなく、設定の「Windowsの問題を修正する」から修復を試みることが推奨されています。 – What to do if DISM scan is stuck at 62.3% – Microsoft Q&A
- 処理の進捗はコマンドプロンプト上のパーセント表示だけでなく、
C:\Windows\Logs\CBS\CBS.logでも確認できます。PowerShellでGet-Content C:\Windows\Logs\CBS\CBS.log -Tail 10 -Waitを実行すると、ログがリアルタイムで末尾に追加されていく様子を確認できます。ログが更新されていれば処理は続いています。 – DISM RestoreHealth stuck at 62.3% [Info / Resolved] - DISM の処理が本当に止まっているかを確認するもう一つの方法として、タスクマネージャーで
TrustedInstaller.exeの動作確認があります。TrustedInstaller.exeは Windows Modules Installer とも呼ばれ、Windows Update やDISMの修復処理に関係するサービスです。このプロセスが動いている場合、DISMは内部で作業を続けています。 – Fix Windows Update corruptions and installation failures – Microsoft Learn