Clear a stale one-time `bootsequence` or multiboot state that makes Windows appear to boot twice

Windows Boot Manager can contain both a persistent menu order and a separate one-time boot sequence. bootsequence tells Boot Manager which loader or boot application to use on the next boot only. It is used by features such as Advanced startup, Windows Setup, recovery, diagnostics, and management tools. After it is consumed, Boot Manager is supposed to return to its persistent displayorder and default behavior.

If an obsolete one-time target remains, points to a setup/recovery entry that immediately restarts, or is repeatedly recreated, the computer can appear to boot twice: Windows Boot Manager starts one target, that target restarts or returns, and Boot Manager then starts the normal Windows loader. A stale persistent duplicate in displayorder, or a forced displaybootmenu flag, can produce a similar-looking menu without involving bootsequence.

This writeup separates those BCD elements. It does not assume every two-stage startup is a Windows BCD problem. Some systems perform two firmware POST cycles for memory training or firmware recovery, and Windows updates can legitimately restart several times.

Searchable Windows error codes and exact messages

There is no Windows status code whose definition is stale bootsequence. When all targets are valid, no numeric code may appear.

These codes describe the target that failed. They do not prove why Boot Manager selected it or that bootsequence is stale.

Use this procedure when Windows Boot Manager or Choose an operating system visibly appears, at least one Windows installation can boot or WinRE can access the active BCD store, and enumeration shows an unwanted bootsequence, duplicate displayorder entry, or explicit displaybootmenu flag. The strongest case is a visible bootsequence GUID whose target matches the first unwanted stage and whose removal stops the repeat behavior.

Do not use this procedure when the machine performs two manufacturer-logo/firmware POST cycles before Windows Boot Manager, a blue-screen stop causes the restart, power is lost, firmware is updating, memory training is occurring, Windows Setup is actively installing or rolling back, or no Windows Boot Manager stage can be observed. Duplicate UEFI firmware entries without a duplicate Windows menu are a separate firmware-entry condition.

The exact application that originally created a stale one-time entry may remain unknown after a one-time cleanup. Whether the duplicate stage is firmware or Windows Boot Manager, whether bootsequence exists, which GUIDs it names, which loader is valid, and whether Windows Setup or recovery still needs the entry may not remain unknown.

• A working Windows installation or WinRE access to the active BCD store
• Administrator access
• A complete BCD enumeration and backup before any edit
• At least one loader GUID proven to start the intended Windows installation
• Confirmation that no update, upgrade, reset, or recovery operation is still active
• Two restart tests and one cold-start test after the repair
• Command Prompt rather than PowerShell, unless every GUID containing braces is quoted

Observe one complete startup before editing. Record where the apparent second boot occurs: firmware logo, Windows Boot Manager, Windows logo/spinning dots, Recovery, Setup, or desktop. A short phone video can preserve the sequence and exact text. Do not delete any BCD object merely because its description looks temporary.

If the screen says Working on updates, Installing, Undoing changes, Attempting repairs, or names Windows Setup, stop and let that operation finish or use its specific recovery procedure. Temporary loaders are normal during those operations.

1. Boot the usable Windows installation and open an elevated Command Prompt.

2. Create a backup folder, save readable enumerations, and export the system store:

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

3. Enumerate the Windows Boot Manager object:

   bcdedit /enum {bootmgr} /v
   

4. Record these fields exactly as shown:

   • default
   • displayorder
   • bootsequence, if present
   • timeout
   • displaybootmenu, if present
   • resumeobject, if present

5. Enumerate all Windows loaders and resume objects:

   bcdedit /enum osloader /v
   bcdedit /enum resume /v
   

6. If firmware-level duplication is also suspected, enumerate firmware separately:

   bcdedit /enum firmware /v
   

7. Use the following distinctions:

   BCD element	What it controls	What it does not control
   bootsequence	A one-time list/order for the next Windows Boot Manager invocation	The normal persistent menu after that one-time sequence is consumed
   displayorder	The persistent list and order of boot entries displayed to the user	Which entry is automatically selected after the wait
   default	The loader selected when the wait expires	The order in which entries are displayed
   timeout	Seconds before Boot Manager selects default	Whether a bad loader object is valid
   displaybootmenu	Can force the Boot Manager prompt to display	The validity of each loader
   resumeobject	Associates a Windows loader with its Windows Resume Application for hibernation	Persistent menu order, one-time selection, or the default OS
   {fwbootmgr}	UEFI firmware’s application order	Windows Boot Manager’s internal OS-loader menu

8. If bootsequence is present, enumerate every GUID it contains:

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

9. Determine what each target is:

   • A valid intended Windows Boot Loader
   • Windows Recovery Environment
   • Windows Setup or rollback loader
   • Windows Memory Diagnostic
   • A stale object whose device is unknown or absent

10. Do not remove an entry solely because it is a recovery or setup object. Confirm that no operation still requires it and that it matches the unwanted first stage.

11. If bootsequence is absent, do not label it stale. Inspect displayorder, default, timeout, and displaybootmenu instead.

12. If only one valid loader appears in displayorder but the menu is still forced, look for:

    displaybootmenu        Yes
    

13. If two nearly identical Windows entries exist, compare their GUIDs, device, osdevice, path, and systemroot. A duplicate description is not proof that either entry is invalid.

14. If working only from WinRE, detect the layout rather than assuming drive letters:

    diskpart
    list disk
    list volume
    

    Treat every FAT32 System partition as a candidate, not proof. Enumerate firmware with bcdedit /enum firmware /v and correlate the Windows Boot Manager entry's device/path with the ESP firmware actually starts. Assign S: only after that correlation, exit DiskPart, and inspect:

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

    Copy the store to the verified Windows or backup volume before editing it. If more than one ESP remains plausible or the firmware entry cannot be correlated to one candidate, stop; do not edit an arbitrarily chosen BCD store.

Branch A — Remove an unwanted one-time bootsequence

Use this branch only when bootsequence is visible under {bootmgr}, its GUIDs were enumerated, and the target is no longer required.

1. Record the full original bootsequence line in the backup notes.

2. Remove one unwanted GUID from the one-time sequence:

   bcdedit /bootsequence {<unwanted-GUID>} /remove
   

3. If more than one unwanted GUID is listed, repeat the command separately for each GUID.

4. When the final GUID is removed, BCDEdit removes the bootsequence value from Boot Manager.

5. Verify the result immediately:

   bcdedit /enum {bootmgr} /v
   

6. Confirm that default, displayorder, and timeout were not changed.

7. Restart once and observe the full sequence.

8. After Windows starts, enumerate Boot Manager again:

   bcdedit /enum {bootmgr} /v
   

9. Restart a second time and check again. A healthy one-time sequence should not return unless another component recreates it.

Branch B — Remove a stale entry from the persistent menu without deleting it

Use this branch when bootsequence is absent but displayorder contains a duplicate or obsolete loader whose identity has been proven.

1. Confirm the GUID of the working default loader:

   bcdedit /enum {default} /v
   

2. Remove the stale GUID from the visible menu while retaining the object in the BCD store:

   bcdedit /displayorder {<stale-GUID>} /remove
   

3. Set the intended default if necessary:

   bcdedit /default {<good-GUID>}
   

4. Move the preferred valid installation to the beginning without replacing any other verified retained entry:

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

   If another retained loader needs to be moved to the end, use:

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

   Do not issue a two-GUID replacement if a third verified loader is retained. A full replacement is safe only when every retained GUID is listed.

5. Set a temporary test timeout:

   bcdedit /timeout 10
   

6. Restart twice and test every retained loader.

7. Delete the hidden stale object only after it is proven unused and both retained entries work:

   bcdedit /delete {<stale-GUID>}
   

8. If there is any doubt, leave the unused object hidden. A hidden BCD object is less dangerous than deleting a recovery or alternate loader that is still needed.

Branch C — Stop a forced boot menu when only one intended loader exists

Use this branch when there is one intended loader, no active one-time sequence, and {bootmgr} explicitly contains displaybootmenu Yes.

1. Remove the explicit force-menu value:

   bcdedit /deletevalue {bootmgr} displaybootmenu
   

2. Set a short nonzero timeout for the first tests:

   bcdedit /timeout 5
   

3. Re-enumerate Boot Manager:

   bcdedit /enum {bootmgr} /v
   

4. Restart twice. If the menu no longer appears and Windows boots correctly, reduce the timeout further only if desired.

5. On a real dual-boot machine, retain enough timeout to select the second installation. Do not hide the menu merely to mask an invalid default loader.

Branch D — Clear the exact value in an offline UEFI store

Use this branch only when Windows cannot start but WinRE can prove the firmware-used ESP and at least one valid loader.

1. In WinRE, detect the Windows volumes and correlate the firmware Windows Boot Manager entry to one ESP as described in section 7. The examples use verified S: for the firmware-used ESP and W: for the Windows/backup volume. Stop if multiple ESPs remain ambiguous.

2. Copy the store:

   md W:\BootRepairBackup
   copy S:\EFI\Microsoft\Boot\BCD W:\BootRepairBackup\BCD-before-stale-sequence
   

3. Enumerate Boot Manager and every sequence target from that store:

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

4. Remove the exact unwanted entry from the one-time sequence:

   bcdedit /store S:\EFI\Microsoft\Boot\BCD /bootsequence {<unwanted-GUID>} /remove
   

5. If the offline command does not support /bootsequence against that store, remove the bootsequence element only after all its GUIDs have been recorded and proven unnecessary:

   bcdedit /store S:\EFI\Microsoft\Boot\BCD /deletevalue {bootmgr} bootsequence
   

6. Re-enumerate the store before restarting:

   bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum {bootmgr} /v
   

7. Do not edit firmware order, format the ESP, or rebuild all boot files for this isolated value.

Branch E — bootsequence returns after every restart

1. Preserve the before-and-after BCD enumerations with timestamps.

2. Confirm that the exact same bootsequence and GUID return, not merely the normal displayorder line.

3. Check whether Windows Update, Setup, Advanced startup, a recovery utility, disk-imaging software, or an endpoint-management product initiated the restart.

4. Do not create a startup task that deletes bootsequence on every boot. That can break legitimate recovery, feature-update, and servicing operations.

5. Stop repeated edits and identify or repair the component recreating the value. The BCD value is now an effect, not the root cause.

• Removing bootsequence stops the first unwanted stage: The stale one-time selection was the cause.
• bootsequence disappears naturally after one successful boot: That is expected one-time behavior; no permanent cleanup is required.
• No bootsequence exists but a duplicate menu remains: Correct displayorder, the duplicate loader, or displaybootmenu instead.
• The menu disappears after deleting displaybootmenu: A forced menu, not an invalid loader, caused the delay.
• An invalid target shows 0xc000000e, 0xc000000f, or 0xc0000225: Preserve the code and repair or remove that exact loader only after confirming whether it is still needed.
• The first stage is Windows Setup or Recovery and an operation is pending: Restore the BCD backup if it was changed, then use the setup/recovery-specific procedure.
• The system still performs two firmware POST cycles: BCD is not controlling that stage.
• The value reappears: Find the component writing it; do not keep clearing it automatically.

• Do not delete {bootmgr}, {fwbootmgr}, {current}, {default}, {memdiag}, or an unknown recovery/resume object.
• Do not delete every entry whose description contains Recovery, Setup, or Windows.
• Do not treat bootsequence, displayorder, default, timeout, and resumeobject as interchangeable.
• Do not remove resumeobject to fix an ordinary boot menu; it is for hibernation resume.
• Do not set timeout 0 before proving that the default loader works.
• Do not hide the menu on an intentional dual-boot system without preserving a way to select the second installation.
• Do not clear a temporary loader while Windows Setup, Reset, Recovery, or an update is active.
• Do not edit UEFI firmware order when the demonstrated problem is inside Windows Boot Manager.
• Do not repeatedly force the computer off to test the result.
• Do not create an automated script that deletes one-time boot values at every startup.

If the cleanup removed the wrong value and a rollback is genuinely required, the safest general rollback is the complete export made immediately before the edit. From the same running Windows environment that created it, run:

bcdedit /import C:\BootRepairBackup\BCD-before-stale-sequence

Import replaces the current system-store entries with the saved entries, including the recorded one-time sequence. Use it only when returning the complete store to its known before-state is appropriate.

Recreate the removed one-time sequence only when its targets have been proven to belong to a legitimate, unfinished Windows Setup, Reset, or Recovery operation and that operation must resume. Use the exact recorded order:

bcdedit /bootsequence {<first-original-GUID>} {<second-original-GUID>}

That targeted rollback intentionally schedules the proven Setup/Recovery targets for the next boot only. For an obsolete, unexplained, or already completed target, do not recreate it; leave the stale sequence absent or restore the complete backup if a full rollback is necessary.

To restore an offline BCD copy, boot to WinRE, redetect the Windows volume, re-prove which ESP firmware uses, and run:

copy /y W:\BootRepairBackup\BCD-before-stale-sequence S:\EFI\Microsoft\Boot\BCD

If only displayorder, default, or timeout was changed, restore the exact original values from BCD-before-stale-sequence.txt rather than importing the entire store.

• bcdedit /enum {bootmgr} /v contains no unintended bootsequence.
• The intended displayorder, default, and timeout remain present.
• displaybootmenu is absent unless it is intentionally required.
• Two consecutive Restarts reach the intended Windows installation without the unwanted first stage.
• One full shutdown and cold power-on also succeeds.
• Every intentionally retained dual-boot entry still starts its correct installation.
• The BCD value remains absent after both restarts.
• Hibernation still works if it is used; no resumeobject was changed.
• Firmware POST behavior is unchanged, confirming that only the Windows Boot Manager layer was modified.
• No new 0xc000000e, 0xc000000f, 0xc0000225, or Recovery screen appears.

Confidence is high when an unwanted bootsequence is visible, its target matches the first unwanted boot stage, and removing it stops the behavior across two restarts and a cold start. Confidence is moderate when the problem is instead a proven duplicate displayorder entry or forced displaybootmenu flag. Stop if Windows Setup, an update, Reset, or Recovery is active; the machine double-POSTs before Windows Boot Manager; a crash or power loss causes the restart; no valid loader is proven; the firmware-used ESP cannot be identified or multiple ESPs remain ambiguous; or another component recreates bootsequence after every boot.