Windows Boot Manager names \Windows\System32\winload.efi and reports that the application or operating system could not be loaded. The loader file may be missing, corrupt, fail integrity validation, or be referenced incorrectly by BCD.

Useful exact searches include File: \Windows\System32\winload.efi, The application or operating system couldn't be loaded because a required file is missing or contains errors, and Windows cannot verify the digital signature for this file. Always search the code, exact file, and exact message together.

Use this procedure when the Recovery screen names winload.efi, the Windows volume is readable, and inspection shows either a missing/damaged file or an incorrect BCD loader path.

Do not use it when the drive is absent, BCD itself is the only named failure, Secure Boot rejects a newly installed non-Microsoft loader, or multiple unrelated system files fail checksums. Multiple changing files point toward storage or memory instability.

The exact Windows build may remain unknown for BCD correction and ordinary offline SFC. It becomes mandatory if DISM requires matching installation media or a known-good repair source.

Before you start:

  • Windows Recovery Environment or installation media
  • Command Prompt
  • Readable Windows and system partitions
  • Matching Windows installation media only if offline component repair requires a source

Open Repair your computer > Troubleshoot > Advanced options > Command Prompt. Detect the Windows volume as W: and the system partition as S: before running repair commands.

  • Do not download winload.efi from a file-replacement website.
  • Do not copy winload.efi from a different PC or arbitrary Windows build.
  • Do not disable Secure Boot or signature enforcement as a permanent workaround.
  • Do not rebuild BCD if the existing loader path is already correct and the file fails integrity checks.
  • Do not assume C: is the offline Windows volume.

Stop when multiple files fail, matching repair content is unavailable, the storage path is unstable, or the failure persists after both file and BCD verification.

Check the cause

  1. Record the code, message, and full winload.efi path.

  2. Detect and map the volumes:

    diskpart
list disk
list volume
select volume <Windows-volume-number>
detail volume
assign letter=W
select disk <Windows-disk-number>
list partition
select partition <system-partition-number>
detail partition
assign letter=S
exit

  3. Inspect the loader files:

    dir W:\Windows\System32\winload.*

  4. Confirm whether winload.efi exists and has a plausible nonzero size. Do not conclude that it is valid solely because it exists.

  5. On UEFI/GPT systems, inspect the BCD loader path:

    bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum osloader /v

  6. On BIOS/MBR systems, use:

    bcdedit /store S:\Boot\BCD /enum osloader /v

  7. For the intended loader, record device, osdevice, path, and systemroot. A normal UEFI loader path is \Windows\System32\winload.efi. A BIOS/MBR installation normally uses winload.exe; a screen that specifically names winload.efi is itself evidence of the UEFI path.

  8. Classify the failure:

    • File absent: Proceed to offline system-file repair.
    • File exists but BCD path/device is wrong: Proceed to BCD/boot-file reconstruction.
    • File exists and the screen reports checksum or signature failure: Use the integrity branch and prepare matching repair media.
    • Different files fail on successive boots: Stop and test storage and memory before replacing files.

Branch A — Repair the protected loader file

  1. Run offline System File Checker against the detected installation:

    sfc /scannow /offbootdir=W:\ /offwindir=W:\Windows

  2. Record the final SFC message.

  3. If SFC reports that it repaired files, confirm winload.efi now exists:

    dir W:\Windows\System32\winload.efi

  4. Restart and test.

  5. If SFC cannot repair the file, do not download a replacement. Obtain Windows media matching the installed architecture, edition, language, and build closely enough to service that installation, then use the matching-source process in FIX-066.

Branch B — Repair an incorrect UEFI BCD reference

  1. Create a backup directory and preserve BCD:

    md W:\BootRepairBackup
copy S:\EFI\Microsoft\Boot\BCD W:\BootRepairBackup\BCD-before-winload-repair

  2. Recreate UEFI boot files and loader references:

    bcdboot W:\Windows /s S: /f UEFI /v

  3. Re-enumerate the store and confirm the loader path:

    bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum osloader /v

  4. Restart twice.

Branch C — Repair an incorrect BIOS/MBR loader reference

  1. Preserve BCD:

    md W:\BootRepairBackup
copy S:\Boot\BCD W:\BootRepairBackup\BCD-before-winload-repair

  2. Recreate BIOS boot files:

    bcdboot W:\Windows /s S: /f BIOS /v

  3. Restart twice.

Check the result

  • Windows starts twice without naming winload.efi.

  • W:\Windows\System32\winload.efi exists and Windows accepts its integrity.

  • The active BCD loader points to the intended Windows device, systemroot, and loader path.

  • SFC reports no remaining integrity violations after Windows becomes usable.

  • The error does not change among multiple unrelated system files.

  • SFC repairs winload.efi and Windows starts: The protected loader file was damaged or missing.

  • BCDBoot corrects the loader path and Windows starts: The BCD reference, not the file content, was wrong.

  • SFC cannot repair the file: Matching repair content is required; continue with FIX-066's DISM source procedure.

  • 0xc0000221 or 0xc0000428 remains: Treat the problem as checksum/signature failure and verify the named file, source match, storage, and RAM.

  • WinRE cannot read W: reliably: Stop. Repairing a loader file is inappropriate until the storage path is stable.

To undo the change:

SFC does not provide a simple per-file undo; preserve logs and use System Restore if its repair makes the condition worse. If BCDBoot removed an intentional loader, restore the saved BCD file from W:\BootRepairBackup to its original system-partition path.