The short version
- 01Read the message rather than the file name: the named file is usually present and intact.
- 02Boot from Windows installation media and choose Repair your computer, then Startup Repair.
- 03Open a Command Prompt in recovery and run bootrec /scanos to find installed systems.
- 04Back up the store with bcdedit /export before editing anything in it.
- 05Rebuild the store with bootrec /rebuildbcd if Startup Repair does not fix it.
- 06Reconnect any disk you removed, since the BCD may still point at a partition on it.
Raw message
File: \Windows\system32\winload.exe Status: 0xC000000E Info: The application or operating system couldn't be loaded because a required file is missing or contains errors.
Likely causes
- A device specified in the Boot Configuration Data that does not exist.
- A BCD entry left pointing at a partition after the disk layout changed.
- A drive that has been cloned, imaged or migrated to a new disk.
- A second disk removed or reordered, so the recorded partition is no longer there.
- Boot files genuinely missing from the system partition.
What the screen says, and what it means
The message names a file and invites you to conclude the file is broken: it reports \Windows\system32\winload.exe with status 0xC000000E and the explanation that the application or operating system couldn't be loaded because a required file is missing or contains errors. On a UEFI machine the file named is winload.efi instead.
Microsoft's stated cause is narrower and more useful than that wording suggests: the issue occurs when a device that doesn't exist is specified in the Boot Configuration Data. In other words the loader is usually sitting exactly where it should be. What is wrong is the record telling Windows where to look.
That reframing matters because it changes what you do. Replacing or repairing winload is not the fix. Correcting or rebuilding the boot configuration is.
What tends to cause it
The Boot Configuration Data records a specific device and partition. Anything that changes which partitions exist, or their order, can leave that record pointing at nothing: cloning a drive, restoring from an image, migrating to a larger SSD, adding or removing a second disk, or repartitioning.
So the first question is what changed just before it started. If you removed a drive, plugging it back in can restore the machine to bootable in seconds — worth trying before any repair, because it costs nothing and it confirms the diagnosis at the same time.
This is also the ordinary outcome of a clone that copied the partitions but not the boot configuration's understanding of them. That is not a failed clone so much as an incomplete one, and it is repaired rather than redone.
Repairing it on a normal PC
Microsoft's dedicated article for this code is written for Azure virtual machines, and its steps involve detaching the OS disk and attaching it to a second VM. Those do not apply to a laptop, so the practical route is the boot loader phase methods from Microsoft's Windows startup issues article, which cover the same repair from the recovery environment.
Start the machine from installation media for your version of Windows, select Next, then Repair your computer, then Troubleshoot, then Startup Repair. Microsoft describes that tool as automatically fixing many common issues, and it writes what it did to %windir%\System32\LogFiles\Srt\Srttrail.txt, which is worth reading if it reports failure.
If Startup Repair does not resolve it, open a Command Prompt and run Bootrec /ScanOS to scan for installed systems, then restart. If that does not fix it, Microsoft's sequence is bcdedit /export c:\bcdbackup, then attrib c:\boot\bcd -r -s -h, then ren c:\boot\bcd bcd.old, then bootrec /rebuildbcd — export first, so the old store can be restored if the rebuild goes badly.
If rebuilding does not help
A rebuild that completes but changes nothing suggests the problem is not only the boot configuration. Microsoft's next methods in the same article cover replacing bootmgr by copying it to the System Reserved partition, and restoring the system registry hive when Windows cannot load it into memory.
One caveat is worth knowing before you rely on the hive route: since Windows 10 version 1803, Windows no longer automatically backs up the system registry to the RegBack folder. Microsoft made that change deliberately to reduce disk footprint and recommends a system restore point instead, so a RegBack folder full of zero-byte files is expected rather than a symptom.
If the disk itself does not appear in diskpart, stop repairing the boot configuration — a device that is not visible cannot be pointed at correctly, and the problem is the drive, its cable or the controller.
Sources and review notes
Checked on . The meaning and cause come from Microsoft's article for this code, which is written for Azure VMs — its disk-attach steps do not apply to a physical PC, and are deliberately not repeated here. The repair route is from Microsoft's Windows startup issues article. The advice to reconnect a removed drive first is editorial. Glitchary is independent of Microsoft.