Boot manager error 0xC000000F and 0xC0000225 – BCD file is missing

Fix it now

The firmware found and ran the boot manager; what failed next was loading something it needs. The file name on the error screen decides everything. Microsoft documents three quite different causes behind 0xC0000225, and rebuilding the boot store only addresses one of them.

diskpart
list volume
exit
bootrec /scanos
bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum /v

1. Read the File: line on the error screen before anything else. \Boot\BCD or \EFI\Microsoft\Boot\BCD means the boot store. \Windows\System32\winload.exe means the loader. Anything under \Windows\System32\drivers\ means a driver, and no BCD work will help.
2. Identify the Windows volume and the small FAT32 system partition with diskpart and list volume. In recovery the Windows volume is rarely C:.
3. If the screen named the store, confirm the installation is still found with bootrec /scanos, then check that device and osdevice name the real Windows partition in the bcdedit /store ... /enum /v output.
4. Rewrite the boot files against the correct volume: bcdboot X:\Windows /s S: /f UEFI, where X is the Windows volume and S is the system partition.
5. If the screen named a driver, this is a file replacement job instead: run chkdsk X: /f, then find a good copy under X:\Windows\WinSxS with dir <name>.sys /s and copy it into X:\Windows\System32\Drivers.

Startup Repair is worth one attempt before any of this. It fixes a fair share of these and costs a few minutes, and it will tell you nothing useful if it fails.

If the machine now starts, you can stop here. If not, the next section explains what the boot manager is looking for and why each of these codes appears.

Why it happens

On a UEFI machine the firmware loads the Windows boot manager from a small FAT32 partition set aside for that purpose. The boot manager reads a store of boot configuration data – a registry-format file on that same partition – which holds one entry per bootable operating system. Each entry records which volume holds the loader and where on that volume it sits. The loader then loads the kernel and the boot-start drivers.

0xC000000F is the boot manager reporting that the application or operating system could not be loaded because a required file is missing or contains errors. Microsoft’s documented causes are the boot configuration data being corrupt, the device and osdevice references in it being missing or unknown, or the binary named on the screen being absent from the disk. Note that the third of those has nothing to do with the store at all.

0xC0000225 is the one that is routinely misread. Microsoft publishes it as the status or object not being found, and lists three causes: a missing or corrupted system binary under \Windows\System32\drivers, corrupted boot configuration data or an incorrectly prepared virtual hard disk, and corruption of the registry hive at \Windows\System32\config\system. Two of the three are not BCD problems, which is why so many readers rebuild the store, watch it succeed, and get the same screen back.

0xC0000034 is narrower: the object name is not found. Where 0xC000000F says a file could not be read, this says the entry being looked up is not in the store. That is the difference between a damaged store and an intact store whose entries point somewhere the volume no longer is – which is why this one so often follows adding a drive, cloning to a new disk or resizing partitions.

Full reference

Matching the screen to the work

The UEFI rebuild, step by step

Run this from the recovery command prompt. Pick the disk and the small FAT32 system partition from what list disk and list partition show you, and substitute the real Windows volume letter in the last line.

diskpart
  list disk
  select disk 0
  list partition
  select partition 1
  assign letter=S
  exit
bcdboot C:\Windows /s S: /f UEFI

bcdboot takes the Windows directory as its source, /s as the system partition volume letter and /f as the firmware type – UEFI, BIOS or ALL. Use ALL when you are genuinely unsure which the machine is using; it writes both sets.

Repairing the entries rather than replacing the store

Microsoft’s own documented repair for an unknown device or osdevice is to edit the store rather than rebuild it. On a UEFI machine the store lives at \EFI\Microsoft\Boot\BCD on the system partition; on a legacy installation it is \Boot\BCD.

Formatting or recreating the system partition removes the boot files for every operating system on the machine, not only Windows. On a dual boot machine, or one with a vendor recovery entry, write down what is there before you touch it and expect to restore the other entries through their own tools afterwards.

When the disk is not being seen at all

• If diskpart in recovery lists no disks, no boot repair applies. Return any storage mode setting in firmware to what it was, since a change there prevents the disk being reached.
• Reseat cables or the drive module and confirm the disk appears in firmware setup.
• Run the drive vendor’s diagnostic from bootable media if the disk is detected but behaving oddly.
• Treat a disk no tool can see as a hardware failure and move to data recovery rather than boot repair.
• 0x00000053, NO_BOOT_DEVICE, sometimes appears alongside. Microsoft publishes only the name for that bug check, and notes it appears very infrequently, so read it as a label rather than as a diagnosis.

After the repair

Check the firmware boot order before you call it done. A machine that boots once from a repair and then goes back to a network boot attempt has correct boot files and a firmware entry that was never updated. Add or promote the Windows Boot Manager entry in firmware setup, and replace the CMOS battery if the machine keeps losing its settings between power cycles.

Every code this article covers

Confirm the fix worked

1. Start the machine three times from cold and confirm it reaches Windows each time without intervention.
2. bcdedit /enum from inside Windows shows the default entry naming the correct volume and loader path.
3. The firmware boot order lists Windows Boot Manager first, with no stale entries left behind.
4. If a driver file was replaced, sfc /scannow reports no integrity violations.
5. Create a recovery drive from within Windows, so the next incident is a shorter one.

Questions people ask about this