Repair a dual-boot Windows entry that points to the wrong partition or `winload.efi`

On a computer with two Windows 10/11 installations, each Windows Boot Loader object must identify the partition containing that installation. If one loader’s device or osdevice value points to the other Windows partition, a stale partition, or a device that no longer exists, selecting it can boot the wrong Windows installation, return to the boot menu, or stop at a Recovery screen naming \Windows\System32\winload.efi.

The important distinction is between Windows Boot Manager, which displays and selects menu entries, and each Windows Boot Loader object, which identifies one installation. For a normal UEFI Windows loader, device identifies the volume containing the boot application, osdevice identifies the volume containing the Windows system root, path is normally \Windows\System32\winload.efi, and systemroot is normally \Windows.

This writeup is intentionally limited to UEFI/GPT installations. Before making a repair, the Windows disk must be shown as GPT, the loader must use the UEFI path, and the EFI System Partition (ESP) that firmware actually uses must be proven. A FAT32 partition or a BCD file on its own is only a candidate. BIOS/MBR installations normally use winload.exe; they are excluded from this procedure and must not be forced to use winload.efi or UEFI-only BCDBoot options.

Searchable Windows error codes and exact messages

Search the complete status, full message, file path, and the menu entry that was selected. The same status can result from a missing disk, corrupt BCD, cloned partition identifiers, or a genuinely damaged winload.efi.

Use this procedure when two Windows 10/11 installations are intentionally present and readable on a confirmed UEFI/GPT system, at least one can start or WinRE can read both, and BCD enumeration shows that one Windows Boot Loader object points to the wrong Windows partition, an obsolete partition, or an unknown device. It also applies when the correct installation exists but its boot-menu entry is missing and can be safely recreated in the proven firmware-used ESP with UEFI BCDBoot.

Do not use this procedure on a BIOS/MBR installation, when firmware mode and partition style do not agree, when the firmware-used ESP cannot be proven, when the physical disk is missing or unstable, winload.efi is actually absent or signature-invalid on the correct partition, the problem is solely a missing UEFI NVRAM Windows Boot Manager entry, the installations were cloned with conflicting disk or partition identifiers, Linux GRUB is the only boot manager being displayed, or one Windows installation is mid-upgrade or rollback. A single-installation BCD failure should use the corresponding single-installation boot-file writeup.

The exact Windows build and the event that created the wrong loader may remain unknown. The UEFI/GPT boot architecture, which partitions contain the two Windows installations, which ESP firmware actually uses, which loader GUID belongs to each installation, and whether winload.efi exists on the intended volume may not remain unknown.

• A working Windows installation or Windows Recovery Environment
• Administrator access
• UEFI firmware boot and a GPT Windows disk confirmed before repair
• Both intended Windows partitions consistently readable
• The disk and partition layout detected with DiskPart
• The firmware-used ESP proven, not merely inferred from FAT32 format or a System label
• The active BCD store exported or copied before changes
• The GUID of the exact loader being repaired
• A distinct description for each intentionally retained Windows entry
• Command Prompt rather than PowerShell, unless GUIDs are quoted in PowerShell

Do not delete any loader. First record the Recovery screen, the menu entry selected, and which Windows installation actually starts. If either Windows installation is running Setup, applying an update, or rolling back an update, allow that process to finish or use its documented recovery path before normalizing the dual-boot menu.

1. Record the complete Recovery screen, including status, file path, and the description of the boot-menu entry that was selected.

2. Enter a working Windows installation or open Command Prompt from WinRE.

3. Detect the disk and partition layout:

   diskpart
   list disk
   list volume
   

4. On each disk that contains Windows, inspect its partitions without changing them:

   select disk <number>
   list partition
   detail disk
   

5. In DiskPart, identify:

   • Each large NTFS volume that may contain a Windows directory
   • The * in the GPT column for every Windows disk in list disk
   • Each small FAT32 System partition that is a candidate ESP
   • Any second candidate ESP on the same or another disk

   If the Windows disk is not GPT, stop. This UEFI/GPT procedure does not apply.

6. Assign temporary letters first to the Windows volumes that need inspection and do not already have one:

   select volume <number>
   assign letter=W
   

   Use a different available letter for the second Windows partition. Do not assign S: to an ESP merely because it is FAT32. In the examples below, W: means the verified Windows installation being repaired and S: means the proven firmware-used ESP. They are placeholders, not assumptions.

7. Exit DiskPart:

   exit
   

8. Confirm each Windows installation by inspecting its own directory:

   dir W:\Windows
   dir W:\Windows\System32\winload.efi
   

   Repeat with the other detected Windows volume. Do not use a volume merely because it contains a folder named Boot; the intended volume must contain a coherent Windows directory.

9. Prove which ESP firmware uses before editing an offline store or supplying /s to BCDBoot:

   • From a running UEFI Windows installation, use an unused letter and let Windows mount its system ESP:

     mountvol S: /s
     dir S:\EFI\Microsoft\Boot\BCD
     bcdedit /enum firmware /v
     

     A successful mountvol /s, a matching Windows Boot Manager firmware entry, and the expected Microsoft boot path establish the repair target for the running system.

   • From WinRE, enumerate firmware with bcdedit /enum firmware /v and correlate the Windows Boot Manager entry's device/path with a candidate ESP before assigning S:. Inspect candidates read-only. The presence of \EFI\Microsoft\Boot\BCD on a partition is not proof by itself.

   • If multiple ESPs remain plausible, the firmware entry cannot be correlated, or mountvol /s selects a different ESP than expected, stop. Do not guess which store firmware starts.

10. If working inside an installed Windows session, create the backup and enumeration:

md C:\BootRepairBackup
bcdedit /enum all /v > C:\BootRepairBackup\BCD-before-wrong-loader.txt
bcdedit /enum firmware /v > C:\BootRepairBackup\Firmware-before-wrong-loader.txt
bcdedit /export C:\BootRepairBackup\BCD-before-wrong-loader

11. If working in WinRE, assign S: only to the proven firmware-used ESP. Then enumerate its store explicitly:

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

    If the file does not exist at that path, stop and re-establish which ESP firmware uses. Do not create a new store on the first FAT32 partition found.

12. Copy the offline store before modifying it. Store the backup on the verified Windows volume or separate media:

    md W:\BootRepairBackup
    copy S:\EFI\Microsoft\Boot\BCD W:\BootRepairBackup\BCD-before-wrong-loader
    

13. For every Windows Boot Loader object, record:

    • identifier
    • description
    • device
    • path
    • osdevice
    • systemroot
    • resumeobject

14. Map each loader GUID to the Windows partition it is supposed to start. The descriptions may be identical, so do not use the description alone.

15. Confirm the mismatch. The diagnosis is strong when the selected loader’s device or osdevice identifies the other Windows partition or an unknown/nonexistent device while W:\Windows\System32\winload.efi exists on the intended partition.

16. Interpret adjacent findings:

    • If winload.efi is missing on the correct partition, stop and repair the file/component source.
    • If the disk or partition disappears between scans, stop and diagnose storage.
    • If two cloned partitions carry conflicting identifiers, stop and resolve the clone identity before editing loader fields.
    • If more than one ESP exists and the firmware-used store cannot be proven, stop. Writing a correct entry into an unused ESP changes nothing and can create further confusion.

Branch A — Correct one existing loader from a working Windows installation

Use this branch when one Windows installation starts and the exact incorrect loader GUID and intended Windows volume are proven.

1. Confirm that the BCD export in section 7 completed successfully.

2. Replace {<loader-GUID>} below with the exact identifier, including braces, and replace W: with the detected intended Windows volume:

   bcdedit /set {<loader-GUID>} device partition=W:
   bcdedit /set {<loader-GUID>} osdevice partition=W:
   bcdedit /set {<loader-GUID>} path \Windows\System32\winload.efi
   bcdedit /set {<loader-GUID>} systemroot \Windows
   

3. Give the repaired entry a distinct description that identifies the intended installation without relying solely on a transient drive letter:

   bcdedit /set {<loader-GUID>} description "Windows 11 - Secondary installation"
   

   Use the actual version and a meaningful disk or purpose label.

4. Do not manually copy the working installation’s resumeobject into this loader. Each Windows installation normally has its own Windows Resume Application object.

5. Re-enumerate the repaired object:

   bcdedit /enum {<loader-GUID>} /v
   

6. Verify all four location fields before restarting.

7. Set a temporary menu timeout long enough to select the repaired entry during testing:

   bcdedit /timeout 15
   

8. Restart and select the repaired entry once.

9. In the Windows installation that starts, confirm its identity with winver, its expected files, and its expected applications. Do not assume the repair succeeded merely because a Windows desktop appeared.

Branch B — Correct the loader in the offline UEFI BCD store

Use this branch when neither entry can be safely edited from a running installation but both Windows partitions and the proven firmware-used ESP are readable in WinRE.

1. Confirm that S: is the proven firmware-used ESP, W: is the intended Windows partition, and the BCD file was copied as shown in section 7.

2. Enumerate the exact loader again:

   bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum {<loader-GUID>} /v
   

3. Set the four location values:

   bcdedit /store S:\EFI\Microsoft\Boot\BCD /set {<loader-GUID>} device partition=W:
   bcdedit /store S:\EFI\Microsoft\Boot\BCD /set {<loader-GUID>} osdevice partition=W:
   bcdedit /store S:\EFI\Microsoft\Boot\BCD /set {<loader-GUID>} path \Windows\System32\winload.efi
   bcdedit /store S:\EFI\Microsoft\Boot\BCD /set {<loader-GUID>} systemroot \Windows
   

4. Set a distinct description if the two entries are indistinguishable:

   bcdedit /store S:\EFI\Microsoft\Boot\BCD /set {<loader-GUID>} description "Windows 11 - Secondary installation"
   

5. Re-enumerate the loader and the boot manager:

   bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum {<loader-GUID>} /v
   bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum {bootmgr} /v
   

6. Confirm that the repaired GUID appears in displayorder. If it does not, add it last without replacing the other valid entries:

   bcdedit /store S:\EFI\Microsoft\Boot\BCD /displayorder {<loader-GUID>} /addlast
   

7. Restart and test the repaired entry.

Branch C — Recreate or refresh a missing/incoherent Windows entry with BCDBoot

Use BCDBoot when the intended installation is readable but has no usable loader object, or when its entry is internally inconsistent beyond the four demonstrated location values. Do not use /c; it intentionally discards preserved settings and is unnecessary here.

1. From a running UEFI/GPT Windows session, confirm the target Windows directory and the firmware-used ESP established in section 7. Stop if either is uncertain.

2. Preserve the existing default Windows entry and UEFI firmware order while adding or refreshing the target installation:

   bcdboot W:\Windows /f UEFI /d /p /v
   

   /p is used here only because this article has already confirmed UEFI; it preserves the existing position of Windows Boot Manager in the UEFI firmware order. Do not copy this command to a BIOS/MBR system.

3. Enumerate all loaders:

   bcdedit /enum osloader /v
   

4. Identify the entry whose location corresponds to W:\Windows. Give it a distinct description.

5. If working in WinRE and the exact firmware-used ESP is proven, copy the boot files to that ESP:

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

   On UEFI, specifying /s prevents BCDBoot from creating a new NVRAM entry. This branch assumes the existing Windows Boot Manager NVRAM entry already reaches this ESP. If it does not, stop and use the missing-UEFI-entry procedure instead.

6. Re-enumerate the offline store after BCDBoot and identify any newly created loader GUID before changing menu order.

Branch D — Normalize the menu after both Windows installations boot

Do this only after each retained entry has booted its intended installation. First record the complete current displayorder; every verified retained GUID must remain in it.

1. Set the preferred default:

   bcdedit /default {<preferred-loader-GUID>}
   

2. Move the preferred loader to the beginning without replacing any third or later retained entry:

   bcdedit /displayorder {<preferred-loader-GUID>} /addfirst
   

   If another verified loader needs to be moved to the end, preserve all others with:

   bcdedit /displayorder {<loader-to-move-GUID>} /addlast
   

   A replacement command that lists several GUIDs is safe only when it includes every verified retained menu entry. Never issue a two-GUID replacement on a menu that also contains a third retained loader.

3. Set the desired timeout:

   bcdedit /timeout 10
   

4. If an old broken entry remains, hide it from the menu first rather than deleting it:

   bcdedit /displayorder {<old-bad-GUID>} /remove
   

5. Restart and boot each retained entry twice.

6. Only after the old GUID is proven unused may it be deleted from the store:

   bcdedit /delete {<old-bad-GUID>}
   

• The repaired menu entry boots the intended Windows installation: The location values were the cause.
• It boots the other installation again: Recheck the GUID-to-partition map and possible clone identifier conflicts. Do not keep changing letters blindly.
• The code changes to 0xc0000428: The correct partition may now be selected, exposing a real signature or version problem.
• The code changes to 0xc0000098 and names a file: Verify the exact file against the installed build; do not return to BCD edits automatically.
• BCDBoot creates a second correct entry: Test it, then hide the old entry. Do not delete either until both are mapped.
• BCDBoot writes to a different ESP: Stop and determine which ESP the firmware actually starts.
• One Windows installation has no separate resume object: The installation may still cold-boot, but hibernation for that installation requires a separate verification or hibernation-file reset from within that Windows instance.
• The disk becomes unavailable: Leave BCD unchanged and diagnose storage/controller access.

• Do not delete {bootmgr}, {fwbootmgr}, {current}, {default}, {memdiag}, recovery objects, or resume objects based on their descriptions.
• Do not assume WinRE assigned the Windows partitions the same letters they use when running.
• Do not copy one installation’s resumeobject to the other.
• Do not run bootrec /rebuildbcd merely because one loader points to the wrong volume.
• Do not use BCDBoot /c unless a separate procedure has proven that a fresh store is required.
• Do not format an ESP, change partition types, or mark partitions active for this condition.
• Do not force winload.efi onto a BIOS/MBR installation that correctly uses winload.exe.
• Do not delete an old entry before both intended Windows installations have passed repeated boot tests.
• Do not use the menu description alone to decide which GUID is valid.

From the same working Windows environment in which the export was created, restore the system BCD store with:

bcdedit /import C:\BootRepairBackup\BCD-before-wrong-loader

Import replaces the current system-store entries with the exported backup. Restart and verify the original menu.

For an offline repair, boot to WinRE, redetect the Windows and ESP letters, and copy the saved BCD file back:

copy /y W:\BootRepairBackup\BCD-before-wrong-loader S:\EFI\Microsoft\Boot\BCD

If only one field was changed and the original values are known from BCD-before-wrong-loader.txt, restore the original device, osdevice, path, systemroot, default, and display order individually. Do not invent a rollback value from another computer.

If BCDBoot created a new entry, the conservative rollback is to remove that new GUID from displayorder first. Delete it only after the original entry is restored and tested.

• Each retained menu entry starts its intended Windows installation twice.
• bcdedit /enum osloader /v maps each GUID to the correct detected partition.
• Each UEFI loader uses \Windows\System32\winload.efi and systemroot \Windows.
• The preferred default loads after the configured timeout.
• Menu descriptions are distinct and accurate.
• No 0xc000000e, 0xc000000f, 0xc0000225, or winload.efi Recovery screen appears.
• Restart and cold shutdown/power-on both work for each installation.
• Hibernation is tested separately from inside each installation if it is used.
• The ESP and Windows partitions remain unchanged apart from the intended BCD/boot-file update.

Confidence is high when the failing loader GUID demonstrably points to the wrong partition, the intended partition contains a coherent Windows installation and winload.efi, and correcting that one object makes the intended installation boot. Confidence is moderate when BCDBoot recreates a missing entry but the original corruption mechanism is unknown. Stop when UEFI/GPT cannot be confirmed, the firmware-used ESP cannot be established, multiple ESPs remain ambiguous, cloned disks have conflicting identifiers, a disk disappears, the correct winload.efi is missing or signature-invalid, an installation is mid-upgrade, or repeated BCD corrections continue to resolve to the wrong cloned partition.