DISM RestoreHealth: What the Command Does, and What to Do When It Fails

Updated: October 2026

Somebody on the team has already typed sfc /scannow and watched it report files it couldn't fix. The next line in every forum thread is the DISM restore health command, usually with no explanation of what it touches or why it sometimes sits at 62.3% for what feels like forever. Here's what it repairs, the order to run things in, how to get past the missing-source error, and how to run it on more than one machine at a time.

What the DISM Restore Health Command Does

Windows keeps a store of known-good copies of its own components, the component store, in C:\Windows\WinSxS. SFC repairs your system files from that store. If the store itself is damaged, SFC has nothing clean to copy from, and that's the job DISM does: it repairs the store.

The full command is DISM /Online /Cleanup-Image /RestoreHealth. /Online means the Windows you're running right now, rather than an image file on disk. By default DISM pulls replacement files from Windows Update, according to Microsoft's SFC guidance.

There are three switches, and they do different amounts of work.

Microsoft's Repair a Windows Image page puts it plainly: CheckHealth reports the image as healthy, repairable or non-repairable. If it's non-repairable, the advice is to discard the image and start again.

Run DISM First, Then SFC

The order matters because of how the two tools depend on each other. Microsoft's instruction is short: "You should run DISM prior to running the System File Checker." Fix the store, then let SFC use it.

1. Open an elevated prompt. Command Prompt or PowerShell, run as administrator.
2. Repair the store. Run DISM /Online /Cleanup-Image /RestoreHealth and let it finish.
3. Repair the files. Run sfc /scannow.
4. Read the result. SFC reports no integrity violations, repaired files, or files it couldn't fix.
5. Check the log if it failed. SFC writes to %windir%\Logs\CBS\CBS.log, and DISM writes to %windir%\Logs\DISM\dism.log.

If SFC says it "could not perform the requested operation", Microsoft's page points you to Safe Mode for the rerun.

Does the pair fix anything? This r/sysadmin thread asks exactly that. The top answers land somewhere sensible: it won't fix an application bug or a flaky headset, but on the machine with corrupted system files it saves you a rebuild.

Why It Sits at 62.3%

RestoreHealth has a famous pause at 62.3%. The progress bar stops, nothing moves, and it looks frozen. In a Microsoft Q&A answer, the explanation is that this stage does the heavy repair work on the component store, so a long wait there is normal.

How long is too long depends on the machine, its disk and its connection to Windows Update. A slow spinning disk or a throttled link stretches it. If you want to know it's alive, watch dism.log grow in another window, or check that the DISM process is still using disk and CPU.

The wait turns into a failure when DISM can't reach a usable source. In this r/sysadmin thread, a tech watches RestoreHealth run for forty-five minutes, stall at 80%, then report the source files missing. Several replies point at the same culprit: machines managed by WSUS, which DISM tries to use instead of Windows Update.

Fixing 0x800f081f: Point It at a Local Source

Error 0x800f081f means "The source files could not be found." DISM looked where it was told to look, usually Windows Update or a WSUS server, and didn't get the files it needed. The fix is to hand it a source yourself.

The same code shows up in two other places. Windows Update can report it as "install error - 0x800f081f". The meaning doesn't change: Windows servicing looked for files it needed and didn't find them, which Microsoft logs as CBS_E_SOURCE_MISSING. So the source fix below applies there too.

Turning on .NET Framework 3.5 or another optional feature can fail with it as well. Microsoft's .NET 3.5 install errors article lists three causes: the source path doesn't hold the feature files, the account can't read them, or the files don't match the installed version of Windows. For .NET 3.5, point the install at the sources\sxs folder on matching media:

code
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /Source:D:\sources\sxs /LimitAccess

The cleanest source is the install.wim from Windows installation media, mounted as a drive. Microsoft's syntax uses a Wim: prefix and the index of the edition inside the file:

code
DISM /Online /Cleanup-Image /RestoreHealth /Source:Wim:D:\sources\install.wim:1 /LimitAccess

/LimitAccess stops DISM from falling back to Windows Update, so it uses only the source you gave it. Run DISM /Get-WimInfo /WimFile:D:\sources\install.wim first to find the index that matches the installed edition. Media built by the Media Creation Tool ships install.esd instead, and the same pattern works with an Esd: prefix.

Here's the catch that sends people in circles. Microsoft's repair source guidance says the source must be patched to the latest cumulative update, because a target that's newer than the source may need files the source doesn't have. An ISO from launch day often won't repair a machine that's two years of updates ahead of it.

For machines on WSUS, the same page describes a Group Policy that controls where repairs come from: Computer Configuration, Administrative Templates, System, "Specify settings for optional component installation and component repair". It can point repairs at a network share, or send them to Windows Update directly instead of WSUS.

Ask Leo's walkthrough covers the basic run and what the output means, if you'd rather see it on screen first.

Run It Across Endpoints

On one machine you run DISM by hand. On forty, you want a script. PowerShell has a native cmdlet for this, Repair-WindowsImage, with the same switches:

powershell
Repair-WindowsImage -Online -RestoreHealth -Source "\\fileserver\repair\mount\Windows" -LimitAccess

Wrap it in Invoke-Command to run it on several machines at once, the same pattern our PowerShell commands guide uses for fleet checks. Then run sfc /scannow in the same session.

Three habits keep a fleet run from turning into a fleet incident. Run it outside working hours, because RestoreHealth is heavy on disk and CPU. Start with a few machines, read their dism.log, and only then widen it. And copy each machine's dism.log and CBS.log back to one place, so you can see which machines failed and why.

OpenFrame can run the same scripts across devices as bulk operations or on a schedule, with approval gates so nothing risky runs without a tech signing off.

When Windows Won't Boot: Repair It Offline

/Online needs a running Windows. When the machine loops at startup, boot into Windows Recovery Environment or installation media, open Command Prompt, and point DISM at the installed Windows as an offline image with /Image instead.

code
DISM /Image:C:\ /Cleanup-Image /RestoreHealth /Source:Wim:D:\sources\install.wim:1

Drive letters shift in the recovery environment, so run dir on each letter first to find which one holds the Windows folder and which one holds the media. Windows Update isn't available offline, so the source isn't optional here. Once DISM finishes, sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows runs the file check against the same offline install.

When DISM Isn't the Fix

DISM repairs Windows' own components. It won't fix a failing disk, and if corruption keeps coming back on the same machine, the disk is the first suspect. Check its SMART status before you run DISM a third time.

It also won't fix a driver, a third-party app, or a bad update that installed cleanly. If a stop code keeps returning, our blue screen of death guide covers reading the dump to find the driver. And when CheckHealth reports the image as non-repairable, stop repairing. An in-place repair upgrade or a reset gets the machine back faster than a fourth DISM run.

The Short Version

DISM repairs the store, SFC repairs the files from it, and the order is the whole trick. When DISM can't find its files, give it a source that matches the machine's build and add /LimitAccess. If you're managing updates centrally, our guide to stopping Windows Update covers the WSUS and policy side that decides where Windows looks for files.