Repairing a damaged Windows image: DISM ScanHealth/RestoreHealth then sfc /scannow

Goal

Diagnose and repair a Windows Server image whose component store or protected system files are damaged, in the right order, from an elevated PowerShell or command session.

Prerequisites

Administrator rights; for /RestoreHealth without internet access to Windows Update, a known-good repair source (installation media or a WIM) reachable from the target.

Steps

1. Check for corruption first, without changing anything: Dism /Online /Cleanup-Image /ScanHealth. Microsoft's own repair guidance runs this "to check for corruption" before repairing.
2. Repair the component store: Dism /Online /Cleanup-Image /RestoreHealth. If the target has no Windows Update access, or the online source is itself damaged, point at known-good files: Dism /Online /Cleanup-Image /RestoreHealth /Source:C:\RepairSource\Windows /LimitAccess. /RestoreHealth's documented syntax includes [/Source: <filepath>] [/LimitAccess], where /LimitAccess prevents DISM from also reaching out to Windows Update.
3. Only after the component store is confirmed healthy, repair individual protected files against it: sfc /scannow. Microsoft documents sfc /scannow as the tool "to scan and repair files" for "a quick check of an online image," run after the deeper DISM pass because sfc relies on the same store DISM just repaired.
4. If corruption remains, review the detailed logs: %windir%\Logs\CBS\CBS.log for DISM/component-servicing detail, %windir%\Logs\DISM\dism.log for the DISM session itself, and %windir%\servicing\sessions\Sessions.xml as an index between the two — the Sessions.xml "will point to the DISM.log and CBS.log files for more details."

Expected result

/ScanHealth (or /CheckHealth) reports no corruption, sfc /scannow completes with no violations found or with violations successfully repaired, and re-running step 1 confirms a clean image.

Limits and test basis

Running sfc /scannow before the DISM pass can fail to repair files whose underlying component-store copy is itself corrupt, which is why the health check and /RestoreHealth come first. There is nothing to "undo" in a strict sense — these are repair operations, not configuration changes — but CBS.log should be preserved before further repair attempts if the failure needs escalation, since later runs append to and can rotate it. Neither step requires a reboot on a running online image; a reboot is only needed if the repair itself replaces files that are currently loaded.