Choose an operating system: remove a phantom boot or extra boot entry

The Windows boot menu displays a duplicate boot entry, an extra Windows installation, an old setup or upgrade entry (sometimes associated with leftover $Windows.~BT setup files), or an installation that no longer exists. One entry may start Windows correctly while another fails, returns to recovery, or points to an obsolete installation.

Searchable Windows error codes and exact messages

There is no dedicated Windows error code for a duplicate or obsolete boot-menu entry. The primary searchable screen text is Choose an operating system. If the obsolete entry is selected, that entry can fail with one of these Windows Recovery codes:

Useful exact-message searches include Choose an operating system duplicate entry, The Boot Configuration Data file is missing some required information, A required device isn't connected or can't be accessed, and The Boot Configuration Data file doesn't contain valid information for an operating system. These codes describe why the selected entry failed; none of them alone proves that the correct repair is to delete an entry.

Use this procedure when Windows displays Choose an operating system.

Do not use this procedure when the entire BCD store is unreadable or the unwanted choice appears only in the motherboard's firmware boot-device menu. A firmware-menu duplicate requires confirming the UEFI NVRAM entry separately.

The Windows build, the date the entry was created, and whether it came from an upgrade, clone, or removed installation may remain unknown. The exact entry identifier may not remain unknown; it must be proven before deletion.

• A Windows entry that still boots successfully
• An administrator Command Prompt
• A location on the Windows volume for the BCD backup

Start the known-good Windows entry. Open Start, type cmd, right-click Command Prompt, and select Run as administrator. Use Command Prompt rather than PowerShell so the examples behave exactly as written.

The following repair commands are for an administrator Command Prompt in the known-good installed Windows system. If you are booted from USB or WinRE (X:\Windows\System32), stop before following them: the default BCD store may belong to the recovery media. A technician must identify the disk and BCD store that firmware actually boots, back up that exact store, and use explicit /store commands. /export and /import apply to the system store, so they are not an interchangeable backup/restore method for an arbitrary offline store.

1. Export the current system BCD store:

   md C:\BootRepairBackup
   bcdedit /export C:\BootRepairBackup\BCD-before-entry-removal
   

2. Confirm that the export completed successfully. If it did not, stop.

3. Enumerate the boot manager and every loader entry:

   bcdedit /enum all /v
   

4. Locate the Windows Boot Loader blocks. For each block, record:

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

5. Identify the current working loader:

   bcdedit /enum {current} /v
   

6. Compare its identifier and paths with the suspected obsolete entry. Never delete {current}, {default}, {bootmgr}, {fwbootmgr}, {memdiag}, or a recovery entry merely because its description looks unfamiliar.

7. If the suspected entry points to a partition or Windows directory that still exists, stop and determine whether it is an intentional second installation.

Confirm a $Windows.~BT Setup/SafeOS candidate

Inspect Windows Setup blocks as well as Windows Boot Loader blocks. In a captured SafeOS case, device and osdevice referenced a RAM disk under $Windows.~BT\Sources\SafeOS\winre.wim, and the same identifier appeared in Windows Boot Manager's displayorder. The loader path alone was \windows\system32\winload.efi; that field by itself would not identify the setup image.

For your computer, verify all of the following before treating the candidate as obsolete:

• The exact candidate GUID appears in the unwanted Windows boot-menu choice, and a different, positively identified installed-Windows loader boots successfully.
• Setup or rollback is complete; no update or recovery operation requires the candidate.
• The candidate is not the working loader, a valid recovery target, a resume object, or an intentional second installation. Inspect Boot Manager's default, displayorder, and bootsequence, and the working loader's recoverysequence.
• A successful backup exists for the same BCD store that will be changed.

Do not copy a GUID or drive letter from someone else's case. If any reference or the active store is ambiguous, stop for manual review.

1. Copy the complete identifier of the proven stale Windows Boot Loader entry, including braces.

2. Delete only that entry:

   bcdedit /delete {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
   

3. Re-enumerate the boot manager:

   bcdedit /enum {bootmgr} /v
   

4. Re-enumerate Windows loaders:

   bcdedit /enum osloader /v
   

5. Confirm that the obsolete identifier is gone and the working loader remains.

6. Restart the computer and allow the remaining Windows entry to boot normally.

7. Restart a second time to confirm the result was not a one-time boot-sequence effect.

Firmware-menu branch

If the duplicate appears in the motherboard's one-time boot menu rather than the Windows menu:

1. Return to the administrator Command Prompt.

2. Run:

   bcdedit /enum firmware /v
   

3. Compare each firmware application's path and device. A valid Windows entry normally points to the Windows EFI boot manager. Do not delete the firmware boot manager object itself.

4. Delete a firmware entry only when its device no longer exists or its path is conclusively obsolete. If that cannot be proven, leave it in place.

Setup/SafeOS variant

The same single-entry removal applies to a Windows Setup entry only after the additional checks above prove it is obsolete. Preserve the complete /enum all /v output before and after; /enum osloader alone is not a sufficient inventory of Setup and recovery objects. If the candidate is the current default or remains a required one-time or recovery target, stop rather than deleting it. Use FIX-038 to investigate a one-time boot sequence separately.

• The boot menu now contains only the valid Windows entry: Resolution succeeded.
• The deleted choice returns after reboot: Firmware, an update, or another boot-management program is recreating it. Stop and identify the recreating component.
• The intended entry was removed but Windows still runs: Immediately use the rollback below before restarting again.
• BCDEdit reports that the identifier is not valid: Re-run /enum all /v and copy the exact GUID. Do not substitute a description.

• Do not delete entries based only on their displayed names.

• Do not run bcdedit /delete {bootmgr} or bcdedit /delete {fwbootmgr}.

• Do not erase the complete BCD store to remove one menu choice.

• Do not use msconfig to delete an entry until its underlying path has been verified.

• Do not delete $Windows.~BT, a WIM image, a partition, or an entire EFI directory to remove a menu entry.

• Do not hide the symptom only by setting the timeout to zero.

• Do not treat an unfamiliar Windows Setup label as permission to remove that entry.

If Windows remains running and the wrong entry was deleted, restore the exported store:

bcdedit /import C:\BootRepairBackup\BCD-before-entry-removal

Restart and verify the original menu. If Windows no longer starts, enter Windows Recovery Environment and use the separate BCD-repair procedure in FIX-004.

• The intended Windows entry starts successfully twice.

• bcdedit /enum osloader /v contains the expected loader.

• Intentional recovery and dual-boot entries remain intact.

• The obsolete entry does not reappear.

• Recheck /enum all /v and Boot Manager's displayorder, default, and bootsequence; the working Windows and recovery references must remain valid.

• If the menu returns after another upgrade attempt, investigate the setup failure and newly created entry. Do not repeatedly delete unexamined entries.

Proceed only when the unwanted entry and the working installation are positively identified, the backup is valid, and no active setup/recovery workflow depends on the entry. There is no measured success percentage for this procedure. Stop when those conditions are not met.

Evidence and limits

• Existing source SRC-0701: a Computer Forum discussion reports an unwanted Windows 11 choice after an upgrade failed and reverted to Windows 10. In reply #5, the original poster confirms direct desktop startup after the suggested MSConfig menu-entry removal. The exact BCD path, repeated reboot results, and BCDEdit removal are not documented. The thread's boot.ini advice is not used here.
• Additional upgrade-remnant case: a Microsoft Q&A discussion reports staged NewOS entries following a failed upgrade. The reporter says the entries returned when Normal startup was restored. This supports the symptom and recurrence warning, not a durable repair or the SafeOS WIM variant. Community answers are not Microsoft defect confirmation.
• SafeOS variant: a reviewed case photograph shows a Windows Setup RAM-disk entry referencing the SafeOS image in the boot display order. A successful repair and reboot were not recorded in the available case material. No laboratory success is claimed.
• Microsoft BCDEdit documentation documents the command mechanisms. It does not identify which entry is safe to remove on an individual computer.