Repair offline Windows system files from WinRE with the correct drive letter

System File Checker can repair protected Windows files in an installation that will not start, but only when /offwindir points to the actual offline Windows directory and /offbootdir points to that installation's boot directory. In Windows Recovery Environment, the installed Windows volume is not guaranteed to be C:; WinRE itself normally runs from X:.

Running sfc /scannow without offline parameters from WinRE scans the recovery environment, not necessarily the failed installation. Running a copied command against the wrong letter can produce a failure, scan the wrong Windows installation, or create false confidence.

Searchable Windows error codes and exact messages

Use this procedure when:

• the correct Windows 10 or Windows 11 installation is present and readable but does not start normally;
• WinRE or Windows installation media can open Command Prompt;
• the symptom is consistent with damaged protected system files, such as CRITICAL_PROCESS_DIED, a boot loop after interrupted servicing, or a named protected Windows binary;
• the Windows volume and the boot/system volume can be identified from their contents; and
• a read-only file-system check does not show RAW media, I/O failure, or an unstable disk.

It can also be used when online SFC cannot run because Windows does not reach a usable desktop, provided the offline image is not in an unsupported servicing state.

Do not use this procedure as the primary repair for a missing BCD/EFI partition, wrong boot entry, wrong storage-controller mode, BitLocker-locked volume, disappearing disk, RAW file system, repeated I/O errors, failed drive diagnostics, damaged registry hive, or a third-party driver that the crash dump identifies.

It does not apply when the only evidence is a generic boot loop and SFC reports no integrity violations. SFC repairs protected system files; it does not repair every Windows component or user file.

Do not use an online DISM /Online command from WinRE to repair the offline installation. X:\Windows is WinRE, not the target image.

The exact event that damaged the protected file and the individual file responsible may remain unknown if offline SFC repairs the image and repeated verification passes.

The following may not remain unknown:

• the offline Windows volume;
• the boot/system volume used by that installation;
• whether the disk is GPT or MBR only when that fact determines the boot-directory location;
• whether the file system is readable and stable;
• the exact SFC exit message and offline log; and
• for DISM repair-source work, the installed edition, architecture, language, and build plus the matching image index.

An exact build is not required for the first offline SFC pass. It is required before supplying an external WIM/ESD repair source.

• Windows Recovery Environment or current Windows 10/11 installation media
• Administrative Command Prompt
• Correct Windows installation already identified by contents, not label alone
• BitLocker volume already unlocked
• Verified backup of important files
• A record of list disk, list volume, and assigned temporary letters
• One unused temporary letter for the Windows volume (W: below)
• When separate, one unused letter for the boot/system volume (S: below)
• Space for an offline SFC log and evidence copies
• Matching Microsoft installation media only if the DISM source branch becomes necessary

Do not continue if assigning a letter changes the apparent identity of a volume, or if more than one Windows directory remains plausible.

Enter Troubleshoot > Advanced options > Command Prompt, or boot current Microsoft installation media and select Repair your computer > Troubleshoot > Command Prompt.

This article uses W: for the verified offline Windows volume and S: for a separate boot/system volume. Confirm each letter is unused before assignment. If the Windows partition also contains the boot directory, use W: for both roles and do not create S:.

Keep stable power. Do not run file-system repair switches or SFC until the correct paths have been proved.

1. Record the complete startup screen, stop code, named file, and any preceding update or power interruption. Correct the evidence record if the displayed name was CRITICAL_PROCESS_DIED, not the nonstandard CRITICAL_PROCESS_DENIED wording.

2. Enumerate disks and volumes without writing to them:

   diskpart
   list disk
   list volume
   

3. Confirm W: is unused. Select the already-identified Windows volume and assign it:

   select volume <Windows-volume-number>
   detail volume
   assign letter=W
   detail volume
   exit
   

4. Verify the target from its files:

   dir W:\Windows\System32\Config\SYSTEM
   dir W:\Windows\System32\ntoskrnl.exe
   dir W:\Windows\WinSxS
   

   Stop if these paths are missing or belong to a different installation.

5. Read the installed edition and international settings with DISM, then read the actual offline build from the verified installation's SOFTWARE hive:

   dism /Image:W:\ /Get-CurrentEdition
   dism /Image:W:\ /Get-Intl
   reg load HKLM\FIX066_OfflineSoftware W:\Windows\System32\Config\SOFTWARE
   reg query "HKLM\FIX066_OfflineSoftware\Microsoft\Windows NT\CurrentVersion" /v CurrentBuildNumber
   reg query "HKLM\FIX066_OfflineSoftware\Microsoft\Windows NT\CurrentVersion" /v UBR
   reg query "HKLM\FIX066_OfflineSoftware\Microsoft\Windows NT\CurrentVersion" /v DisplayVersion
   reg query "HKLM\FIX066_OfflineSoftware\Microsoft\Windows NT\CurrentVersion" /v BuildLabEx
   reg unload HKLM\FIX066_OfflineSoftware
   

   DISM /Get-CurrentEdition and /Get-Intl do not report the installed build. The reg load operation mounts the existing offline hive under a temporary key for queries; these commands do not write values into it. Require The operation completed successfully from both reg load and reg unload. If a query fails, still unload the hive before leaving WinRE. If DISM or the hive cannot be opened, record the exact error. Continue only if the Windows and boot paths are otherwise certain and storage is stable.

6. Detect the boot-directory layout. Return to DiskPart:

   diskpart
   list disk
   list volume
   

   • On a GPT Windows disk, identify the small FAT32 EFI System Partition associated with the installation. Assign unused S: temporarily and verify S:\EFI\Microsoft\Boot\BCD.
   • On an MBR Windows disk with a separate System Reserved partition, identify the NTFS system partition, assign S:, and verify S:\Boot\BCD.
   • If the verified Windows volume itself contains the active BIOS boot directory W:\Boot\BCD, use W:\ as /offbootdir.

   Do not choose a partition by size alone. Stop if multiple disks contain plausible active BCD stores and the store for this installation cannot be proved.

7. For a separate system partition, assign and verify S::

   select volume <system-volume-number>
   detail volume
   assign letter=S
   detail volume
   exit
   

   Then inspect the applicable path:

   dir /a S:\EFI\Microsoft\Boot\BCD
   dir /a S:\Boot\BCD
   

8. Run CHKDSK in read-only mode against the Windows volume:

   chkdsk W:
   

   Stop if the volume is RAW, CHKDSK reports I/O or unreadable-sector errors, the disk disappears, or the error token changes between reads. Protect data and diagnose storage first.

9. If CHKDSK reports logical errors but no hardware/I/O failure, back up accessible files before any repair. A later chkdsk W: /f is a separate corrective branch; /r is not a routine prerequisite for SFC and should be reserved for a justified sector-read investigation.

10. Create an evidence directory on the Windows volume or a healthy external volume:

md W:\BootEvidence\FIX-066

11. Confirm the intended command without running it:

Separate boot/system partition:

sfc /scannow /offbootdir=S:\ /offwindir=W:\Windows /offlogfile=W:\BootEvidence\FIX-066\sfc-offline.log

Combined Windows/boot partition:

sfc /scannow /offbootdir=W:\ /offwindir=W:\Windows /offlogfile=W:\BootEvidence\FIX-066\sfc-offline.log

12. Proceed only when the selected /offwindir and /offbootdir both belong to the same intended installation and the read-only storage check is acceptable.

Branch A — File system is clean enough and offline SFC can run

1. Run exactly one of the two commands proved in section 7.

   Separate boot/system partition:

   sfc /scannow /offbootdir=S:\ /offwindir=W:\Windows /offlogfile=W:\BootEvidence\FIX-066\sfc-offline.log
   

   Combined Windows/boot partition:

   sfc /scannow /offbootdir=W:\ /offwindir=W:\Windows /offlogfile=W:\BootEvidence\FIX-066\sfc-offline.log
   

2. Record the complete final message. Do not close Command Prompt until it is photographed or copied.

3. If SFC reports successful repairs, run the same offline command a second time. Require either no integrity violations or another explicitly recorded repair result.

4. Remove only temporary letters assigned by this article:

   diskpart
   list volume
   select volume <system-volume-number-if-S-was-assigned>
   detail volume
   remove letter=S
   select volume <Windows-volume-number>
   detail volume
   remove letter=W
   exit
   

   Omit the S: lines if no separate system letter was assigned. Do not remove a letter that existed before the procedure.

5. Restart and test Windows.

6. If Windows starts, open an elevated Command Prompt and run the online scan once:

   sfc /scannow
   

7. Restart again and continue to section 12.

Branch B — Read-only CHKDSK reports logical file-system errors without I/O failure

1. Back up all accessible important data first.

2. Run a bounded logical repair:

   chkdsk W: /f
   

3. Do not interrupt it. Preserve the complete result.

4. Run chkdsk W: without repair switches again. Continue only if the logical check is now acceptable and no I/O errors appeared.

5. Return to Branch A. Do not automatically add /r; a surface/sector scan is a storage-diagnosis decision, not a stronger generic SFC preparation step.

Branch C — SFC cannot repair files and DISM reports the component store is repairable

Use this branch only with an official Microsoft repair source whose Windows release, edition, architecture, and system/default UI or install language match the offline installation, and whose servicing level is compatible with—not older than—the component version DISM needs. If those facts cannot be established, stop rather than treating any ISO that exposes the same edition name as a valid source.

1. Preserve sfc-offline.log and run:

   dism /Image:W:\ /Cleanup-Image /CheckHealth
   dism /Image:W:\ /Cleanup-Image /ScanHealth
   

2. If DISM says the image is non-repairable, stop. Do not force package or registry changes.

3. Mount or insert matching media and identify its drive as <M>. Determine whether it contains install.wim or install.esd:

   dir <M>:\sources\install.*
   

4. List image indexes and select the one matching the offline edition:

   WIM media:

   dism /Get-WimInfo /WimFile:<M>:\sources\install.wim
   

   ESD media:

   dism /Get-WimInfo /WimFile:<M>:\sources\install.esd
   

5. Run one matching repair command, replacing <index>:

   WIM:

   dism /Image:W:\ /Cleanup-Image /RestoreHealth /Source:wim:<M>:\sources\install.wim:<index> /LimitAccess
   

   ESD:

   dism /Image:W:\ /Cleanup-Image /RestoreHealth /Source:esd:<M>:\sources\install.esd:<index> /LimitAccess
   

6. If DISM returns 0x800F081F, stop and correct the source match. Do not try random indexes or third-party component files.

7. After DISM completes successfully, return to Branch A and rerun offline SFC.

Branch D — SFC cannot perform the requested operation

Recheck W:, S:, the exact paths, and read-only CHKDSK. Review sfc-offline.log. If the paths are correct and storage is stable, run DISM /CheckHealth only. Do not use revertpendingactions, rename WinSxS, edit TrustedInstaller service values offline, or delete pending-operation files without a separate diagnosis.

• Successfully repaired followed by a clean second scan and successful boot supports protected-file corruption as the repaired mechanism.
• No integrity violations on the first scan means SFC found no protected-file defect; route to the displayed stop code, driver, BCD, registry, servicing, or hardware evidence.
• Unable to fix some files requires the offline log and, when the component store is repairable, a matching DISM source. It does not justify copying files manually from another computer.
• Could not perform the requested operation requires path, file-system, and servicing-state diagnosis; repeating the same command is not progress.
• If Windows starts but crashes again with 0xEF, preserve the dump. A successful SFC operation does not exclude a boot driver, storage, registry, or hardware cause.
• If CHKDSK reports I/O errors or the volume disappears, stop all repair writes and switch to data protection/storage diagnosis.

• Do not assume offline Windows is C: or that WinRE X: is the installation.
• Do not run plain sfc /scannow from WinRE and claim that it repaired the offline Windows image.
• Do not use /offbootdir from one installation and /offwindir from another.
• Do not manually replace ntoskrnl.exe, winload.efi, or arbitrary protected files from another machine.
• Do not use a repair WIM/ESD with an unverified edition, architecture, language, index, or incompatible build.
• Do not use chkdsk /r as a ritual; it is a long sector-read/recovery operation with a different purpose.
• Do not run DISM /Online in WinRE to target W:\Windows.
• Do not delete pending.xml, rename WinSxS, transplant registry hives, or use /RevertPendingActions under this article.
• Do not rebuild BCD when the evidence only shows protected-file corruption.

SFC and DISM do not provide a command that automatically restores every file they replaced. The practical rollback is the verified system backup or image created before repair.

Temporary drive letters can be removed as shown in Branch A. CHKDSK repairs are not generally reversible; that is why data is backed up and read-only checking precedes /f.

If Windows behavior worsens after SFC/DISM:

1. Return to WinRE.
2. Preserve the offline SFC log and DISM logs from W:\Windows\Logs\DISM and W:\Windows\Logs\CBS.
3. Do not rerun the commands repeatedly.
4. Restore the verified pre-repair backup, or use a supported repair-install/reinstall path after protecting data.

1. Require a second offline SFC pass to report no integrity violations, or document exactly what remains unrepaired.
2. Start Windows twice from a full shutdown and twice with Restart.
3. If Windows starts, run online sfc /scannow once and retain its final result.
4. Review Reliability Monitor and Event Viewer for a new 0xEF, disk, NTFS, WHEA, or servicing failure.
5. Confirm Windows Update can scan after the system is stable; do not immediately install a large feature upgrade as the first test.
6. Verify normal sign-in, desktop, core applications, networking, storage, and Device Manager.
7. Preserve sfc-offline.log, CBS/DISM logs, before/after CHKDSK results, and assigned-letter ledger.
8. Make a fresh backup after the installation has remained stable.

Confidence is 80% when the correct offline Windows and boot paths are proved, storage is stable, offline SFC explicitly repairs protected files, a second scan is clean, and Windows then survives repeated starts. It is not an 80% claim that SFC cures every CRITICAL_PROCESS_DIED or boot loop.

Stop when any volume is RAW or intermittent, CHKDSK reports I/O failures, the boot/system partition cannot be paired with the installation, SFC finds no violation, DISM says the image is non-repairable, a matching repair source is unavailable, the same stop recurs after clean scans, or logs identify a driver/hardware/registry cause. No independent TechXplored reproduction has been performed for this article.