Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Dmytro Koval
A winload.efi error is Windows Boot Manager saying it cannot find, read or trust the OS loader. How to read the error code, the four causes in order of likelihood, and the repair ladder from WinRE with bcdboot, bootrec and sfc, plus the Secure Boot certificate change that now breaks old boot media.
A machine stops at a blue Recovery screen, names a file under System32, and the user reads out an error code that means nothing to them. The file is the Windows OS loader, and the code tells you which link in the boot chain gave up. This guide covers what winload.efi does, how to read the error code, the four causes in order of likelihood, and the repair ladder that fixes each one from WinRE.
Windows starts in four handoffs, and Microsoft's startup troubleshooting guide names each one. The firmware runs its self-test and finds a system disk. On a UEFI machine it then loads the Windows Boot Manager, \EFI\Microsoft\Boot\bootmgfw.efi, from the EFI System Partition. Boot Manager reads the Boot Configuration Data store, finds the entry for the Windows installation, and starts the OS loader on that partition: \Windows\System32\winload.efi. The loader pulls in the kernel and the boot-start drivers, then hands over to ntoskrnl.exe.
So winload.efi is the third link, and the error screen that names it is the second link complaining. Boot Manager looked for the loader where the BCD said it would be and either found nothing, found a file it could not read, or found a file whose signature it would not accept. The fix is almost never the file itself. It is the pointer, the partition, or the trust chain around it.
On a legacy BIOS machine the same role belongs to winload.exe, started from bootmgr on the active partition. The error screens look alike, but the repair commands differ, which is why the first thing to confirm is the firmware mode. Our BIOS explainer covers the two boot paths side by side.
The code under the file name narrows the cause before you touch a command prompt.
| Code | What Boot Manager is saying | Usual cause |
|---|---|---|
| 0xc0000225 | The loader is not where the BCD points | BCD device or path wrong after a disk change, clone or partition edit |
| 0xc000000f | The boot device or the BCD store itself cannot be read | Missing or damaged BCD, a disk the firmware cannot see |
| 0xc0000001 | A required device is inaccessible | Storage controller mode changed, failing disk, lost EFI partition |
| 0xc0000098 | The file exists but is damaged | Interrupted update, power loss mid-write, file system damage |
| 0xc0000428 | The loader's signature could not be verified | Secure Boot rejecting an unsigned, revoked or outdated loader |
Two of those are pointer problems, two are disk problems, and one is a trust problem. The repair for each is different, which is the reason to read the code before running the first command someone posted in a forum. If the screen names winload.exe rather than winload.efi, the machine booted through the legacy path, and the bootrec commands further down are the ones that apply.
The BCD points at the wrong place. The Boot Configuration Data store records which disk and partition hold the Windows folder. Clone the system to a new SSD, pull a second drive, change a SATA port, resize a partition, or let an imaging tool rewrite the disk signature, and the stored pointer stops matching reality. This is the common cause behind 0xc0000225, and the fix is to rebuild the pointer, not to touch the file. A dual-disk machine is the trap version: two bootable disks, and the firmware picks the one you did not mean. In the thread below, a desktop quietly booted from an old clone on a SATA drive until the clone was unplugged, at which point the real system disk surfaced with a winload.efi error of its own.
The file is damaged or missing. A cumulative update replaces the loader as part of servicing. Cut the power mid-write and the file on disk is half old and half new, which reads as 0xc0000098. The same thing happens when a disk with bad sectors lands one of them under System32. Rebuilding the BCD does nothing here, because the pointer is fine. The file has to be restored from the component store, or the update finished, or the disk replaced.
Secure Boot refuses the loader. The firmware checks the signature on every boot component against its trust database. A loader signed by a certificate the firmware has revoked, or a boot manager older than the minimum version the firmware now requires, fails with 0xc0000428. Since 2023 this has a specific trigger: the move from the 2011 Microsoft certificates to the 2023 set. More on that below.
The disk is failing. A disk that drops out under load, or a controller whose mode flipped from AHCI to RAID after a firmware reset, produces 0xc0000001 or a loader error that changes between boots. Every repair in this guide assumes the hardware can be trusted. If the error moves around, check the disk before the boot files, using the SMART counters in our guide to checking SSD health.
Every step below runs from the Windows Recovery Environment or from installation media. Boot the media, choose Repair your computer, then Troubleshoot, then Command Prompt. If the machine cannot reach WinRE on its own, the ways in are in our WinRE guide. Work down the ladder and stop at the first rung that boots.
Startup Repair first. It is automatic, it is non-destructive, and it fixes a plain BCD mismatch on its own. When it fails, read the log it leaves at %windir%\System32\LogFiles\Srt\Srttrail.txt before moving on. The log names the test that failed, which often tells you which rung to jump to.
Find the partitions. Drive letters inside WinRE do not match the ones the user sees. The Windows partition is often D: or E:, and the EFI System Partition has no letter at all. Assign it one before anything else:
codediskpart list vol select vol N assign letter=S exit
The EFI partition is the small FAT32 volume, usually 100 MB to 500 MB, with no label or the label SYSTEM. Note which letter holds the Windows folder; the commands below use C: for it, so substitute yours.
Rebuild the boot files with bcdboot. This is the UEFI repair. Microsoft's BCDBoot reference describes it as the tool to "recreate the system partition files by using new copies of these files from the Windows partition". One line copies a fresh boot manager to the EFI partition and writes a new BCD that points at the Windows folder you name:
codebcdboot C:\Windows /s S: /f UEFI
Reboot. For the pointer problem this is the whole fix, and the video below walks the same steps on a Windows 11 machine for anyone who wants to see the screens before running them.
bootrec is the legacy tool. On a BIOS and MBR machine, the sequence from Microsoft's guide is bootrec /fixmbr, bootrec /fixboot, bootrec /scanos and bootrec /rebuildbcd. On a UEFI machine /fixmbr has nothing to repair and /fixboot often returns "Access is denied", which is the command telling you to use bcdboot instead. Run bootrec only when the screen said winload.exe or the disk is MBR; the MBR vs GPT guide shows how to tell in diskpart.
Rebuild the EFI partition when it is gone. A clone that skipped the EFI partition, or a partition tool that deleted it, leaves nothing for bcdboot to write into. Recreate it in diskpart: select disk 0, create partition efi size=260, format fs=fat32 quick, assign letter=S, then run the bcdboot line again. Confirm the disk is GPT first, because an EFI partition on an MBR disk boots nothing.
Repair the file when the pointer is right. For 0xc0000098, run the System File Checker against the offline installation, which pulls a clean copy of the loader from the component store:
codesfc /scannow /offbootdir=C:\ /offwindir=C:\Windows
If the component store itself is damaged, the DISM pass in our DISM RestoreHealth guide runs from the same prompt. For a machine that died mid-update, Microsoft's guide also has the DISM commands that list and revert pending packages, which is the right move when the error appeared right after Patch Tuesday.
Signature enforcement is a diagnostic, not a fix. A BCDEdit switch tells the loader to skip integrity checks for one boot. It can get a machine up long enough to copy data off or finish an update, and it tells you the problem is trust rather than the file. Leave it set and the machine is running with its boot-time signature check off, so reverse it the same day. A reader who wants the full BCD store syntax should wait for our BCDEdit guide; this post keeps to the repair.
When it is the disk. A loader error that changes code between boots, a diskpart listing that shows the volume as RAW, or a chkdsk that finds bad clusters every run means the ladder ends here. Image what can be read, replace the drive, and restore. Rebuilding boot files on a dying disk buys a day.
Microsoft is replacing the 2011 Secure Boot certificates with a 2023 set, and the swap changes which loaders a machine will run. Per Microsoft's KB5025885, the mitigations add the 2023 certificates to the firmware's trust database, install a boot manager signed by the Windows UEFI CA 2023, and then revoke the Windows Production PCA 2011 certificate, after which "the Boot Manager will refuse to run" anything below the new minimum version. The page is plain about the consequence: "Recovery or install media will need to be updated so that it will work with a device that has the mitigations applied." The last of the 2011 certificates, the one that signs the Windows boot loader, expires on October 19, 2026, per Microsoft's certificate expiration notice, KB5062710.
The practical version of that sentence is a signature error at boot from media that worked last month. A WinPE image built with an older ADK, a vendor rescue disk, or a PXE boot image that still carries only the 2011 signature fails on a machine whose firmware now trusts the 2023 set. The thread below is a July 2026 report of exactly that: Lenovo machines refusing a PXE boot with a winload.efi error after the certificate update, and the replies pointing at rebuilding the boot image with the updated certificates.
Three habits keep this off the help desk. Rebuild every piece of boot media, USB and PXE, from a current ADK and date the stick. Check which certificate state each machine is in before the firmware rollout, using the steps in our Secure Boot check. And when a loader error appears on a machine that was never cloned or resized, test the media on a second machine before assuming the disk is at fault. If you run OpenFrame, a script across a client's devices that reads the Secure Boot state and the certificate status, with the output collected in one place, turns that check into a list rather than a round of site visits.
Every help desk has watched Startup Repair run three times on the same machine before anyone read the log:
Four questions settle the rung. Did the disk layout change recently, by clone, resize, second drive or port swap? Then the BCD is pointing at the wrong place, and bcdboot is the fix. Did the error appear right after an update or a power cut? Then the file is damaged, and the offline sfc pass, or reverting the pending update, is the fix. Is the code 0xc0000428, or does the machine boot from one piece of media and not another? Then Secure Boot is rejecting the loader, and the media or the certificate state is the fix. Does the code change between boots, or does diskpart show RAW? Then the disk is the problem, and the ladder ends at replacement.
Anything that does not fit those four gets Startup Repair, then bcdboot, then a read of Srttrail.txt, in that order. If the boot files come back clean and Windows itself is still broken, the next step is a repair install, which rebuilds the installation without touching user data.
A winload.efi error is Boot Manager saying it cannot find, read or trust the loader, and the code says which of the three. Read it, confirm the firmware mode, and rebuild the pointer with bcdboot before you do anything to the file. Keep boot media current with the 2023 certificates, and the Secure Boot version of this error stops arriving at all. When the machine will not even reach the recovery screen, start with the entry points in the WinRE guide.
Head of Product Engineering
Hi! My name is Dmytro, but everyone calls me Dima. I’m a Software Developer and together with the development team, I help bring Flamingo to life — putting it on its feet from a technical perspective. Originally from Lviv, Ukraine 🇺🇦, but currently based in Spain, where I’ve been enjoying the blend of great weather, culture, and nature. I’m passionate about the mountains and love traveling — exploring new places and cultures really inspires me. These experiences constantly recharge me and give me a fresh perspective, both personally and professionally.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.