If a Windows computer has corrupted system files, the standard advice is usually:
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
The second command is the one everyone knows. The first is often treated as an optional extra.
For Windows administrators, that is the wrong way around.
When SFC reports that it found corrupted files but could not repair them, the next question should not simply be whether to run SFC again.
The better question is:
Is the Windows Component Store that SFC relies on healthy enough to repair those files?
That is where DISM comes in.
Microsoft’s troubleshooting guidance uses DISM to repair the Windows Component Store and then SFC to scan and repair protected system files. The order isn’t arbitrary.
SFC and DISM repair different things
SFC and DISM are often treated as interchangeable Windows repair tools.
They aren’t.
SFC checks protected Windows system files
System File Checker verifies protected Windows system files and attempts to replace corrupted versions with known-good copies.
sfc /scannow
SFC is concerned with the protected system files used by Windows.
If those files are damaged, SFC can often repair them. But the replacement has to come from somewhere, and that somewhere is the Windows Component Store.
DISM repairs the Windows image and Component Store
DISM, or Deployment Image Servicing and Management, can inspect and repair the Windows image.
For a running Windows installation:
DISM /Online /Cleanup-Image /RestoreHealth
/Online tells DISM to work against the currently running Windows installation.
/Cleanup-Image tells it to perform servicing operations against the Windows image.
/RestoreHealth tells DISM to scan for Component Store corruption and attempt to repair it.
The relationship is straightforward once you see it:
Windows protected system files
^
SFC
^
Windows Component Store
^
DISM
SFC can find a damaged protected system file. But if the underlying Component Store is itself damaged or missing the required repair content, SFC has nothing good to replace it with.
That is the whole argument for running DISM first.
The repair sequence
From an elevated Command Prompt or Windows Terminal.
First:
DISM /Online /Cleanup-Image /RestoreHealth
Let it complete. It can take a while and it may appear to stall around 20 per cent. That’s normal.
Then:
sfc /scannow
DISM repairs the Windows image and Component Store. SFC validates and repairs protected system files.
After SFC finishes, interpret the result rather than simply closing the window.
The three DISM health checks
DISM provides three health operations and they aren’t equivalent.
/CheckHealth
DISM /Online /Cleanup-Image /CheckHealth
Checks whether the image has already been flagged as corrupted. It doesn’t scan; it reads a flag set by a previous operation. Quick, and it tells you nothing if no scan has been run.
/ScanHealth
DISM /Online /Cleanup-Image /ScanHealth
Performs a full scan for Component Store corruption and records the result. Takes several minutes. Doesn’t repair anything.
/RestoreHealth
DISM /Online /Cleanup-Image /RestoreHealth
Scans and repairs. This is the one that matters when you already suspect corruption.
You don’t need to run all three. If you have a reason to suspect a problem, go straight to /RestoreHealth.
What if DISM fails?
This is where the troubleshooting gets interesting, and where most guides stop.
By default, an online DISM repair uses Windows Update as its repair source. If the machine can’t reach Windows Update, or the required files aren’t available there, the repair fails.
You can supply your own source. Microsoft documents this in Repair a Windows Image.
DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:1 /LimitAccess
/LimitAccess prevents DISM from contacting Windows Update, so it uses only the source you’ve given it.
Don’t blindly use :1
The number is the image index inside the WIM, and it has to match the Windows edition you’re repairing. A WIM containing Home, Pro, Education and Enterprise has four indexes, and index 1 is not necessarily the one you want.
Check first:
DISM /Get-WimInfo /WimFile:D:\sources\install.wim
That lists each image with its index, name and edition. Pick the index matching the installed edition.
If the media contains install.esd instead
This catches people out. Modern Windows media downloaded through the Media Creation Tool often contains install.esd rather than install.wim, and DISM cannot use an ESD file as a repair source directly.
Check which you have:
dir D:\sources\install.*
If it’s an ESD, convert it to a WIM first:
DISM /Get-WimInfo /WimFile:D:\sources\install.esd
DISM /Export-Image /SourceImageFile:D:\sources\install.esd /SourceIndex:3 /DestinationImageFile:C:\Temp\install.wim /Compress:max /CheckIntegrity
Replace 3 with the index matching your edition, from the /Get-WimInfo output. Then point /Source at the resulting WIM.
The conversion takes a while and needs several gigabytes of free space, but it’s the difference between having a usable repair source and not.
The source has to match
The repair source must contain the files the installation actually needs. Don’t assume any Windows ISO will do.
Check:
- Windows edition
- CPU architecture
- Windows version and build
- Servicing level
The last one is the trap. If the machine has been patched beyond the source media, the source may not contain the updated component versions, and the repair fails. A machine on 23H2 with two years of cumulative updates won’t necessarily be repairable from the original 23H2 ISO.
Microsoft’s guidance is to use repair media at an appropriate patch level. In practice that often means either letting the machine reach Windows Update, or building patched media.
Error codes worth recognising
0x800F081F
Documented as CBS_E_SOURCE_MISSING. The source for the required package or file could not be found.
At this point, running sfc /scannow repeatedly will not help. The problem is the repair source, not the system files.
Investigate:
- whether the machine can reach Windows Update
- whether the supplied source is appropriate
- whether the source index is correct
- whether the source is patched to a sufficient level
- the DISM and CBS logs
0x800F0831
Documented as CBS_E_STORE_CORRUPTION. Corruption in the Windows Component Store.
This is the clearest case for the DISM-first approach. If an update is failing with this, it isn’t an SFC problem.
0x80073701
Documented as ERROR_SXS_ASSEMBLY_MISSING. A component is missing from the store.
Again, this points at the servicing infrastructure rather than protected system files.
Microsoft’s guide to fixing Windows Update errors covers these codes and the DISM-then-SFC sequence.
Interpreting the SFC result
Once DISM reports success, run SFC and read what it tells you.
No integrity violations
Windows Resource Protection did not find any integrity violations.
SFC found no corruption in the protected system files it checked.
That doesn’t prove the operating system is healthy. It means SFC didn’t find protected system-file corruption. If you’re chasing an application crash or an update failure, keep investigating.
Corrupt files found and repaired
Windows Resource Protection found corrupt files and successfully repaired them.
Restart if the problem involves system files, servicing or Windows Update, then retest the original problem.
A successful repair command isn’t the same as proving the original fault is fixed.
Corrupt files could not all be repaired
Windows Resource Protection found corrupt files but was unable to fix some of them.
Don’t run SFC again hoping for a different answer. Read the log.
Reading CBS.log instead of guessing
%windir%\Logs\CBS\CBS.log
The file can be enormous on a long-running machine. Filter the SFC entries:
findstr /c:"[SR]" %windir%\logs\cbs\cbs.log > "%userprofile%\Desktop\sfcdetails.txt"
That gives you a much smaller file containing only the System Resource entries, which is where SFC records what it found and what it couldn’t fix.
Look for lines mentioning files that could not be repaired. They usually name the file, which tells you whether you’re dealing with something recoverable or something that needs a different approach.
DISM and SFC log to different places
DISM -> %windir%\Logs\DISM\dism.log
SFC -> %windir%\Logs\CBS\CBS.log
If DISM fails, start with dism.log.
If SFC reports files it couldn’t repair, go to CBS.log.
Reading the wrong log is a common way to waste an hour.
Windows Update failures
This is where the DISM-first approach earns its keep.
Windows Update failures are frequently caused by corruption in the servicing infrastructure and Component Store rather than by anything wrong with the update itself.
Microsoft’s own sequence for these is DISM, then SFC, then retry the update. The errors associated with Component Store corruption include:
0x800F081F
0x800F0831
0x80073701
0x80073712
The specific code matters. It tells you whether you’re dealing with missing repair content, store corruption or a missing assembly, and those have different fixes.
Treating every failed update as an SFC problem is why people end up running the same command five times.
When DISM can’t reach Windows Update
Common on managed servers, which may have:
- restricted internet access
- a proxy
- WSUS
- firewall restrictions
- deliberate network isolation
In that case, supply the source yourself, using the WIM approach above. Identify the correct index, confirm the source is patched to an appropriate level, and use /LimitAccess so DISM doesn’t waste time attempting Windows Update.
A mounted Windows image can also serve as a source. Both WIM files and mounted installations are valid source types.
When neither is enough
If DISM fails and SFC still reports corruption, you’ve reached the point where more investigation is needed rather than more commands.
Check the logs, then consider:
- correcting the repair source
- repairing Windows Update itself
- checking the underlying disk
- clearing pending servicing operations
- an in-place repair install
Don’t jump straight to rebuilding. But equally, recognise when you’ve reached the point where a repair install is faster than continuing to troubleshoot. That judgement is part of the job.
The sequence to remember
DISM /Online /Cleanup-Image /RestoreHealth
|
v
Repairs the Windows image and Component Store
|
v
sfc /scannow
|
v
Checks and repairs protected system files
|
v
Retest the original problem
If DISM fails, investigate DISM.
If SFC can’t repair files, read CBS.log.
If the problem was Windows Update, retry the update after the repair.
SFC is still a useful tool. The mistake is treating it as the entire repair process.
On a modern Windows system, DISM gives SFC a healthier foundation to work from. That’s why running DISM first is usually the more useful starting point.
Microsoft references
- Repair a Windows Image –
/RestoreHealth,/Sourceand/LimitAccess - Fix Windows Update errors – the DISM and SFC sequence, and the component-store error codes
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.