Command Prompt Stuck at 62 3

DISM or Command Prompt pausing at 62.3% is often normal servicing, but treat it as a hang if the percentage sits there for hours with no disk, CPU, or log activity. Mixing those two cases wastes time and can send you toward the wrong repair. This guide shows how to read CBS and DISM logs, check system symptoms, and choose the next repair step.

For Microsoft’s own command syntax and servicing guidance, see the DISM documentation on Microsoft Learn, the Windows servicing/repair guidance, the SFC support article, and the CHKDSK support article: DISM image management command-line options, Repair a Windows image, Use the System File Checker tool to repair missing or corrupted system files, and Check your hard disk for errors in Windows. For CBS and DISM logs, Microsoft documents the servicing log locations and repair workflow in the same repair guidance.

Is 62.3% actually a freeze?

Usually, no. DISM /Online /Cleanup-Image /RestoreHealth repairs the current Windows image, and the 62.3% point can be a visible pause while it processes component store data, fetches repair content, or finishes a larger servicing task. The best first move is to leave it running, then confirm activity in CBS.log and Task Manager before you force anything closed. Microsoft’s repair guidance and DISM command reference both describe this as normal servicing behavior rather than a live progress meter.

What DISM is doing at 62.3%

The command can be working on the component store, also called WinSxS, where Windows keeps repair files and reclaimable packages. Heavy system load, large missing updates, or several corrupted files can make that phase take longer than the progress bar suggests. The bar is not a live meter, so it may sit still while servicing continues in the background. Microsoft Learn’s DISM documentation and repair guidance both place this work inside the Windows image servicing pipeline.

How long to wait

Use the system and the repair path as your guide. On an SSD with an online repair, a quiet period of about 15 to 45 minutes can still be normal; on an HDD, or when Windows Update is fetching files, a common window is about 1 to 3 hours. An offline repair from local media should usually move sooner, so a long pause there deserves more suspicion.

62.3%: normal delay or real stall?

Use symptoms, not the percentage alone, to decide. If CBS.log keeps adding lines, TrustedInstaller is still active, or disk activity continues, 62.3% is more likely normal servicing. If the log stops advancing, the servicing process disappears, and the machine sits idle for a long stretch, treat it as a real stall and move to the next fix.

How to check the log in real time

Use PowerShell as administrator, then tail the servicing log with this command: Get-Content C:\Windows\Logs\CBS\CBS.log -Wait. The -Wait option keeps the file open and appends new lines as they arrive, which is the clearest way to see whether DISM is still moving forward. You can also open C:\Windows\Logs\DISM\dism.log for more detail. Microsoft’s servicing guidance uses these logs to verify whether repair activity is still progressing.

Say your laptop shows 62.3% for 25 minutes on an SSD, but CBS.log keeps printing package entries every minute. That is a delay, not a freeze. Suppose the same laptop sits at 62.3% for 40 minutes with no new CBS lines and no disk light at all. That points to a real stall, not a normal pause.

Likely causes

Most often, the slowdown is tied to Windows Update, a cluttered component store, or another repair path that still needs to finish. Less commonly, disk errors or corrupted system files keep DISM from completing. Start with the cause that matches the symptom pattern in CBS.log and the machine’s current activity.

Windows Update is blocking repair

When DISM uses Windows Update as the repair source, download failures or poor connectivity can leave the command sitting at 62.3% while it waits for missing content. Microsoft’s repair workflow calls for using Windows Update first when online repair is available, and then switching to a local source when the online path cannot provide the files.

1. Open Services and confirm Windows Update and Background Intelligent Transfer Service are not disabled.
2. Open Command Prompt as administrator and run net stop wuauserv, net stop bits, then net start wuauserv and net start bits.
3. Reset Windows Update if needed by using the Windows Update Troubleshooter at ms-settings:troubleshoot.
4. Run DISM /Online /Cleanup-Image /RestoreHealth again.

If Windows Update still fails, use a local source. Microsoft’s supported syntax for a local repair source uses the exact /LimitAccess switch, not the misspelled variant. A valid example is DISM /Online /Cleanup-Image /RestoreHealth /Source:X:\Sources\install.wim:1 /LimitAccess, with X replaced by the drive letter that holds the image. Microsoft Learn documents the /Source and /LimitAccess behavior for DISM image repair.

Clean the component store first

A cluttered WinSxS store can slow repair work near the 62.3% point because DISM may need to inspect and reconcile more packages before it can finish. Microsoft’s repair workflow allows servicing cleanup before a fresh RestoreHealth pass, especially when the component store is large or has accumulated update supersedence.

1. Open Command Prompt as administrator.
2. Run dism /online /cleanup-image /startcomponentcleanup.
3. Wait for the command to complete fully.
4. Run DISM /Online /Cleanup-Image /RestoreHealth again.

This is the better next step when CBS.log shows slow package work rather than a hard stop. If the store was the bottleneck, the second run often moves more predictably after cleanup.

Should you run SFC or CHKDSK first?

Use SFC when you suspect missing or damaged Windows files, and use CHKDSK when the symptoms point to file-system errors or bad sectors. SFC belongs before or after DISM depending on the failure pattern, while CHKDSK is the better choice when disk problems could be making servicing hang. Both are common companion repairs, but they do different jobs. Microsoft’s support articles describe SFC as the tool for protected system files and CHKDSK as the disk integrity check.

1. Run sfc /scannow in an elevated Command Prompt if Windows files look corrupted.
2. If SFC reports repairs, reboot and run DISM /Online /Cleanup-Image /RestoreHealth again.
3. If the machine shows slow reads, file errors, or repeated repair failures, run chkdsk c: /f /r.
4. Accept the restart prompt if CHKDSK asks for one.

CHKDSK is the better next step when CBS.log keeps failing on file access or the disk behaves erratically. A bad sector can make DISM look frozen when the real problem is storage.

What to try if it still stalls

If the command still sits at 62.3% after the log goes quiet, reboot and rerun DISM from an elevated Command Prompt. Then move to a local repair source if Windows Update cannot fetch files. If CBS.log stops changing across repeated runs, the next step is to inspect the DISM log at C:\Windows\Logs\DISM\dism.log and shift to a more invasive repair path. Microsoft’s repair guidance uses that log to identify failed payload acquisition, package corruption, and source mismatch issues.

1. Restart Windows cleanly.
2. Open Command Prompt as administrator, using Win + R, then typing cmd.
3. Run DISM /Online /Cleanup-Image /RestoreHealth again.
4. If it stalls again, rerun with a local source.
5. If the system still fails, run sfc /scannow after DISM and review dism.log.

For a deeper Windows Update reset sequence, see Windows Update reset steps. For a side-by-side repair sequence, see SFC, CHKDSK, and DISM order. For log interpretation, see CBS.log analysis tips and DISM error patterns.

If that did not work, use Safe Mode as a cleaner environment, especially when another service or driver may be holding files open. Microsoft’s support workflow and repair guidance both point to a cleaner startup context as a practical workaround when normal servicing keeps failing.

Prevention is limited here, but one useful habit is to keep Windows Update healthy and avoid interrupting repair commands before they finish. If DISM keeps repeating the same stall, a local source or a fresh Windows ISO is more reliable than retrying the same online path.

Frequently asked questions

Why is dism stuck at 62.3?

It is usually not truly stuck. That point often marks a long servicing phase where DISM is processing component store data, applying missing updates, or waiting on Windows Update content. Check CBS.log first; if new entries continue to appear, let the command keep running instead of forcing a reboot.

Is DISM actually frozen at 62.3% or still working?

Open C:\Windows\Logs\CBS\CBS.log and watch for new timestamps with Get-Content -Wait in PowerShell. If the log keeps advancing and disk activity continues, DISM is still working. If the log stays quiet and the machine is idle for a long stretch, it is more likely a real stall.

How long should DISM /RestoreHealth stay at 62.3%?

There is no single safe timer. A short pause can be normal on any system, but an SSD often moves sooner than an HDD. Online repair can also take longer than an offline repair. If there are no new CBS.log entries for about 20 to 30 minutes, it is reasonable to start treating it as suspicious.

How can I check DISM progress in real time?

Use an elevated PowerShell window and run Get-Content C:\Windows\Logs\CBS\CBS.log -Wait. That shows new servicing lines as they are written. For DISM-specific detail, open C:\Windows\Logs\DISM\dism.log. The percentage readout itself is not a live progress meter.

What should I do if DISM really is stuck at 62.3%?

Reboot, open Command Prompt as administrator, and run the command again. If the same pause repeats, clean the component store with dism /online /cleanup-image /startcomponentcleanup or use a local source with /Source:X:\Sources\install.wim:1 /LimitAccess. Review dism.log if it still fails.

Does DISM /RestoreHealth need an internet connection?

Not always. DISM can use Windows Update as a repair source, which means a working connection helps when files need to be downloaded. If Windows Update is the bottleneck, use a local Windows image instead and point DISM to that source so the repair does not depend on the network.

Scenario matrix from repair testing

These sample outcomes show how the same 62.3% pause can mean different things depending on storage, source type, and log activity. The useful signal is not the percentage alone; it is the combination of elapsed time, CBS.log movement, and whether TrustedInstaller stays active.

Related: Command Prompt Won T Let Me Type

Sources

Microsoft Learn and Support pages used for the command syntax and repair workflow in this article:

• DISM image management command-line options
• Repair a Windows image
• Use the System File Checker tool to repair missing or corrupted system files
• Check your hard disk for errors in Windows