Why Windows Keeps Showing “Choose an Operating System” After an Update

If your screen shows a stop code, Automatic Repair, or no usable display at all, start with Not Every Blue Screen Is a BSOD. Those failures belong to different startup layers and this specific BCD repair may not apply.

Sometimes that is correct. A real dual-boot computer should show more than one operating system. But if the menu appeared immediately after a failed Windows update—and one choice is blank, unnamed, broken, or obviously temporary—the second “operating system” may be nothing more than a phantom Boot Configuration Data entry.

That was the real problem on the Windows 11 machine behind this article. The working Windows installation was intact. A rolled-back update had left another loader pointing into $Windows.~BT, Windows Setup's temporary workspace. Removing that one stale entry fixed the recurring menu.

The important part was not the delete command. It was proving which entry was safe to delete first.

What actually happened

The computer began having trouble after a Windows update. Recovery work included undoing pending update actions from a recovery environment, and Windows eventually started again. That looked like success—until every restart returned to Choose an operating system.

The menu showed the real Windows 11 installation and an extra choice that did not belong. Repairing update state had not removed it. The problem also survived enough reboots to rule out a one-time setup handoff.

The first instinct was to treat the entire Windows boot system as damaged. That would have led toward increasingly broad repairs: rebuilding boot files, changing EFI partitions, or recreating the BCD store. Those operations can be appropriate when Windows genuinely cannot boot, but they were much larger than this problem required.

The decisive evidence came from BCDEdit. The real Windows loader pointed to the normal Windows directory and boot loader. The extra loader pointed into $Windows.~BT.

Microsoft documents $Windows.~BT\Sources\Panther and $Windows.~BT\Sources\Rollback as locations used during Windows Setup and rollback. In other words, $Windows.~BT was not a mysterious second Windows installation. It was upgrade machinery. Microsoft's Windows upgrade log documentation

In this case, the most defensible explanation was that Windows Setup created a temporary loader for part of the upgrade or rollback process and failed to remove its BCD entry afterward. That is an inference from this machine's evidence and the timing of the failure—not a claim that every failed update behaves this way.

BCD is the menu, not the operating system

Boot Configuration Data is a database of boot applications and their settings. Windows Boot Manager reads it before Windows itself starts. Microsoft describes BCDEdit as the primary command-line tool for viewing and changing that store. Microsoft BCDEdit overview

A BCD entry is therefore an instruction about how to start something. It is not proof that another complete copy of Windows exists.

That distinction explains the phantom menu. Windows Boot Manager was faithfully displaying two instructions. One instruction started the real installation. The other referred to temporary setup files left over from the failed update.

Deleting random folders would not correct the menu because the menu entry lives in BCD. Rebuilding the entire BCD store would be excessive because most of the store was still correct.

Inspect the evidence before changing anything

Open Windows PowerShell as Administrator and run:

bcdedit /enum all /v

Microsoft says /enum all lists all BCD entries and /v displays full identifiers rather than friendly aliases. Administrative privileges are required even to view the store. Microsoft BCDEdit /enum documentation

Then inspect the boot manager and current loader directly:

bcdedit /enum "{bootmgr}" /v
bcdedit /enum "{current}" /v

PowerShell requires braces-containing identifiers to be quoted. Only a few fields matter here:

• identifier: the GUID used to address that exact BCD object.
• default: the loader Boot Manager starts when its timer expires.
• displayorder: the entries shown on the operating-system choice screen.
• device / osdevice: the volume or image containing the loader and Windows files.
• path: the boot-loader executable.
• systemroot: the Windows directory that loader expects.
• description: the reader-facing name, which may be unhelpful or blank on a damaged temporary entry.

A normal UEFI Windows loader commonly resembles this simplified pattern:

identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.efi
description             Windows 11
osdevice                partition=C:
systemroot              \Windows

The suspicious entry on this machine followed a different pattern:

identifier              {a-long-guid}
device                  ...\$WINDOWS.~BT\...
description             [temporary, blank, or setup-related]

That example is intentionally simplified; it is not a reconstructed transcript of the original screen. The conclusion came from the combination of facts:

1. The normal entry successfully started Windows. The installed operating system itself still worked.
2. It was current and default. Boot Manager already identified the loader Windows was using.
3. The second GUID was in displayorder. That directly explained the extra menu choice.
4. The second entry referenced $Windows.~BT. It pointed to Windows Setup machinery, not another ordinary installation.
5. Setup had rolled back. Windows was not actively running the upgrade when the entry was removed.

When this is not the right fix

Stop if any of the following is true:

• You intentionally run two operating systems.
• The questionable entry is {current}, the boot manager's default, or the only entry that successfully starts Windows.
• The entry points to another real Windows, Linux, recovery, diagnostic, VHD, or technician configuration.
• There is no $Windows.~BT reference and the only evidence is that two descriptions look alike.
• Windows Setup is currently installing, rolling back, or waiting to complete a restart.
• You do not have the BitLocker recovery key available.
• You cannot identify the exact GUID you intend to remove.

Duplicate targets can be intentional. Descriptions can be wrong. Drive letters can change in recovery environments. This is why a tool that promises to “remove duplicate boot entries automatically” is more dangerous than it sounds.

For a basic, clearly understood duplicate, Microsoft recommends System Configuration (msconfig.exe) as the safer interface. BCDEdit is appropriate when the evidence requires fields MSConfig does not show, but Microsoft warns that incorrect BCD changes can make a computer inoperable. Microsoft's boot-entry guidance

The manual fix

Once the stale GUID is proven—and only then—export the live BCD store:

bcdedit /export "$env:USERPROFILE\Desktop\bcd-before-phantom-entry.bcd"

Do not continue if the export fails. Remove the exact stale loader, with its real identifier quoted:

bcdedit /delete "{the-stale-entry-guid}"

Microsoft distinguishes removing an item from displayorder, which merely hides it from the menu, from /delete, which removes that boot-loader object from both the menu and the BCD store. Microsoft's remove-versus-delete explanation

Then verify the store rather than assuming the command worked:

bcdedit /enum all /v

The normal loader should remain current and default. The deleted GUID should be gone. Restart once and confirm that Windows goes directly to the intended installation.

Using an existing copy of the inspector

If you already have the alpha, review its script and open Windows PowerShell as Administrator:

Get-AuthenticodeSignature .\PhantomBootEntryInspector.ps1
Get-FileHash .\PhantomBootEntryInspector.ps1 -Algorithm SHA256
Unblock-File .\PhantomBootEntryInspector.ps1
.\PhantomBootEntryInspector.ps1

Unblock-File removes the internet-zone marker from that one reviewed file. It does not digitally sign it and does not weaken the computer's machine-wide PowerShell policy. Microsoft explicitly says to review a downloaded file and its source before unblocking it. Microsoft Unblock-File documentation

To repair the one entry after the tool has classified it as a high-confidence candidate:

.\PhantomBootEntryInspector.ps1 -RemoveIdentifier "{the-stale-entry-guid}"

The script performs a fresh inspection before repair. If any guard fails, it refuses the deletion.

Why is the PowerShell script unsigned?

Because signing does not happen automatically.

A PowerShell script is a plain-text file. Writing it, uploading it to GitHub, serving it over HTTPS, or calculating a checksum does not give it an Authenticode signature. Signing requires a code-signing certificate and control of that certificate's private key.

We could create a free self-signed certificate, but that would help only on computers where someone manually installs and trusts it. Microsoft says self-signed certificates are for testing and are not appropriate for scripts distributed to other users. Asking readers to trust an unknown root certificate would create a larger security problem than the warning it removes. Microsoft PowerShell signing guidance

To sign the public release properly, TechXplored needs a publisher identity validated by a public certificate authority or a managed service such as Microsoft Artifact Signing. The finished .ps1 and .psm1 files are then hashed and signed with the protected private key, normally with a trusted timestamp. PowerShell's Set-AuthenticodeSignature command performs the file-signing step. Microsoft Set-AuthenticodeSignature documentation

A valid signature proves that the bytes have not changed since the certificate holder signed them and lets Windows identify the signer. It does not prove that the code is safe or bug-free. Public source, narrow permissions, reproducible tests, hashes, and code review still matter.

Until that trusted signing identity exists, the honest label is unsigned alpha—not a fake self-signed badge and not a buried -ExecutionPolicy Bypass shortcut.

What the repair actually proved

Removing the one $Windows.~BT loader ended the recurring operating-system chooser while leaving the real Windows 11 loader untouched. That does not establish a universal Windows bug. It establishes a narrower and more useful lesson:

When an update fails and Windows starts presenting an operating-system choice that did not exist before, do not begin by rebuilding everything. Inspect what Boot Manager has been told to display. The operating system may be fine. The phantom may be nothing more than an obsolete instruction that Windows Setup forgot to take with it.