## TL;DR
DISM often appears stuck around 62 percent because that phase verifies and replaces a large block of store files and progress reporting is coarse - but hours with no disk, CPU, or log movement means it is genuinely stalled, commonly on a locked file or a bad source read. Check DISM.log timestamps and process activity before killing it. If it is dead, end it cleanly, restart, and rerun with a local matching source and a fresh log so the stall point is captured.

```text
dism restorehealth stuck at 62 percent for hours
```

## Use this when
- RestoreHealth has shown about 62 percent for well over an hour.
- DISM.log has stopped gaining new entries while the command still appears to run.
- The repair was started to fix update failures and cannot be left indefinitely on a production machine.

## Not for this skill when
- DISM is progressing slowly but its log and disk activity are advancing. Let it finish rather than restarting the clock.
- DISM already exited with an error code. Troubleshoot that code directly.

## Steps
1. Judge life signs before touching the process: note the DISM percentage, then check the DISM.log last entry time twice, fifteen minutes apart, plus CPU and disk activity for the DISM and servicing processes in Task Manager. Advancing logs or steady disk activity mean slow, not stuck, and the correct action is patience with a defined review point. Verify: you can state with timestamps whether DISM is advancing or fully stalled
2. Check what could be locking store files: a running Windows Update install, an antivirus scan of the component store, or a backup job touching system files at the same time. Pause competing work you control, because servicing needs exclusive access to files it is replacing and contention shows up as an endless wait at one percentage. Verify: competing update, scan, and backup activity is paused or ruled out, and the observation clock restarts after the change
3. If there is no log, CPU, or disk movement for a full additional hour after removing contention, treat it as hung: close the DISM window or end the DISM process, then restart the machine before any new servicing attempt so half-applied store state and file locks are cleared by the boot. Verify: the hung process is ended and the machine restarts cleanly with no configuring updates activity stuck at boot
4. Rerun RestoreHealth with a better source and clean logging: mount installation media matching the edition and build, run RestoreHealth pointing at that local source with LimitAccess, and rename the old DISM.log first so the new run has an unambiguous log to read if it stalls again at the same place. Verify: the new run either completes or stalls at a documented point with a fresh log that shows the exact package being processed
5. Finish the sequence properly when RestoreHealth completes: run ScanHealth to confirm a clean store, then SFC, then the update that needed the repair. If the second run stalls at the identical package, escalate toward repairing or removing that component or a repair install, using the stall package as evidence instead of repeating generic runs. Verify: ScanHealth reports no corruption and SFC completes, or the repeated stall package is documented for escalation

## Why it happens
RestoreHealth does not progress linearly: large verification and replacement phases report few percentage updates, and the figure around 60 percent covers some of the heaviest store work, so a long pause there can be normal on slow storage or a large store. A true stall is different - the servicing stack waits indefinitely on a file lock, a source read that never returns, or a component whose repair deadlocks. Timestamps and activity separate patience from intervention, which matters because killing a working DISM wastes the elapsed repair and can leave pending operations, while leaving a dead one blocks all other servicing on the machine.

## Variants and edge cases
### Stuck at 62 percent on a virtual machine with slow storage
Storage latency stretches the heavy phases dramatically. Check host storage performance and run the repair in a quiet host period before declaring a hang.

### DISM stalls at the same package after a clean rerun
A single component is the blocker. Note its name from the log and consider removing the associated feature or update, or plan a repair install if it is a core component.

### RestoreHealth stuck while Windows Update is also installing
Never run DISM repair and update installs concurrently. Let one servicing operation own the store at a time and schedule them in sequence.

Compatibility: Applies to Windows 10, Windows 11, and Windows Server 2016 and later. DISM runs need an elevated terminal and matching installation media for local sources.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SqbiYTCL90xkBDdqeiTWpA