problems with "automatic" bitlocker on fresh install of 25H2

[bitchucker]

Greetings all,

I recently installed 25H2 on a new machine from an ISO written to a USB thumb drive. during installation, i short-circuited the microsoft account creation by running the old OOB program.

after successfully installing a bunch of needed software, i removed the bootable USB windows installer and the computer would not boot. the bios could not find anything to boot from on the internal disk; in fact that device just didn't show up in the bios boot menu at all.

it would still boot if i booted the installer first and then asked it to proceed to windows. initially i thought this was a case of the MBR getting corrupted, or the EFI partition/bootloader not being installed on the internal SSD, but eventually i discovered that my C: drive had bitlocker turned on. I understand windows might do this automatically (but what is the key or password?). anyway even though i didn't know the PW or recovery key i was able to turn off bitlocker using powershell. this was in preparation to use clonezilla to back up the C: partition, and then nuke and pave the disk, start over with a fresh windows install, and then restore the old C: partition.

to my surprise, after disabling bitlocker, my computer was able to boot from the internal SSD again.

what is going on here? the command-line bitlocker management program indicated that perhaps the entire disk was not finished with encryption. strange since only 50-60GB was actually in use and i would have thought it would tear through that pretty quickly. i also find it strange that i was able to turn off encryption without knowing any keys or passwords.

it doesn't make sense to me that the bios couldn't find anything to boot, since the MBR/EFI partitions should never be encrypted (right?), just the C: partition which the boot loader would (i assume) mount using the encryption key and then pass control to the windows image there.

thanks for any insight on this.

 

[ChatGPT]

What you’re seeing actually does make sense once you separate three different things:

1. BitLocker/device encryption on C:
2. The unencrypted EFI/System partition
3. The firmware’s UEFI boot entry / boot path

The short version is:

• No, the EFI System Partition is not normally encrypted.
• Yes, Windows 11 can auto-enable device encryption/BitLocker during or right after OOBE.
• You were able to turn BitLocker off because you were already running inside Windows as an authorized admin account, so Windows could use the protector material already available to the OS/TPM.
• The weird part is probably not that BitLocker encrypted the boot files, but that the system was in an odd “device encryption initialized / protector state / UEFI boot entry” condition, and turning BitLocker off likely caused Windows to rewrite or normalize the boot configuration enough that the machine started booting directly again.

The most likely explanation​

On modern Windows 11 installs, especially on hardware with TPM + Secure Boot, Windows can start automatic device encryption even if you didn’t explicitly turn on BitLocker yourself.
That often begins in a sort of pre-protected / suspended / clear-key state before the final protector setup is completed. In practice that can look confusing because:

• the drive reports as encrypted or “encrypting”
• protection may not yet be fully enforced
• the recovery key may not yet be backed up where you expect
• the status output can show encryption still in progress, even if only part of the disk has meaningful data

So your observation that the CLI suggested encryption was not fully finished is believable. If it was using used-space-only encryption, it can still remain in a transitional state for a while, especially if setup/OOBE was interrupted, bypassed, or the machine was still doing background provisioning.

Why you could disable BitLocker without knowing a password/key​

Because you were already in Windows.
That’s the key point. BitLocker doesn’t require you to manually type the recovery key just to manage it from an elevated session if:

• the OS volume is already unlocked, and
• the TPM and existing protectors have already unlocked it for that boot session, or
• the system is still in a clear-key / suspended-like state.

So from inside a running admin session, PowerShell can absolutely let you do things like suspend or decrypt the volume without you ever knowing the 48-digit recovery key.
The recovery key is mainly needed when normal unlock fails:

• TPM measurements changed
• motherboard/firmware changes
• Secure Boot state changed
• boot files changed
• disk moved to another machine
• etc.

Why BIOS/UEFI “couldn’t find anything to boot”​

This is the part that usually points to boot entry/config weirdness, not encryption of the EFI partition.
A few possibilities:

1. The firmware only had a valid path via Windows Boot Manager, not a generic disk entry​

Many newer systems don’t really boot “the SSD” directly in UEFI mode. They boot a UEFI entry such as:

• Windows Boot Manager

which points to a file on the EFI partition, usually something like:

• \EFI\Microsoft\Boot\bootmgfw.efi

If that boot entry was missing, stale, or not being recognized, the firmware menu might make it look like the internal disk itself is “not bootable,” even though the disk and EFI partition are physically fine.

2. Booting from the installer USB gave you a fallback path​

When the Windows installer media is present, its boot environment can sometimes discover the installed Windows instance and chain into it. That can mask the fact that the internal UEFI boot entry is broken or absent.
So the USB was acting like a crutch.

3. Disabling BitLocker may have coincided with Windows repairing/reasserting boot state​

Turning off encryption can trigger a bunch of normal housekeeping:

• updating BCD
• touching the recovery environment
• rewriting boot metadata
• changing protector state
• causing a reboot with a cleaner TPM/boot measurement path

That may be why the machine suddenly became bootable again from the SSD.

What probably did not happen​

Probably not this:

“The BIOS couldn’t see the disk because BitLocker encrypted the boot partitions.”

That’s generally not how BitLocker works.
For an OS drive, the usual layout is:

• EFI System Partition — unencrypted
• MSR — special reserved partition
• Windows partition (C — encrypted
• Recovery partition — usually not the boot-critical issue here

The firmware reads EFI files from the unencrypted EFI partition. Then Windows Boot Manager hands off to the OS, and BitLocker/TPM participate in unlocking the encrypted OS volume.

About “what is the key or password?”​

If Windows auto-enabled device encryption, the protector is often one of these:

• TPM protector
• Recovery password/key
• possibly backed up to:
  • your Microsoft account
  • Entra ID / Azure AD
  • Active Directory, in managed environments

If you bypassed Microsoft account setup and used only a local account, Windows can leave the machine in a somewhat awkward state depending on build/hardware/policy:

• encrypted or partially encrypted
• but not fully “protected” the way a normal MSA/AAD-backed flow would complete

That lines up pretty well with your story.

Why encryption may have taken “too long”​

A few reasons:

• It may have been doing full-volume encryption, not just used-space-only.
• Even with used-space-only, provisioning can still remain in an intermediate status.
• Background encryption may pause/throttle during setup, battery saving, driver installs, reboots, or user activity.
• The “percentage complete” and “protection status” are related but not identical concepts.

So yes, “only 50–60 GB used” does not guarantee it would instantly settle into a clean finished state.

My best guess from your symptoms​

Most likely you had a combination of:

• automatic device encryption kicking in
• an incomplete or transitional BitLocker/device-encryption state
• a fragile/missing UEFI boot manager entry
• the USB installer providing a fallback boot path
• and decrypting the drive caused enough boot/protector reconfiguration that direct SSD boot started working again

What I would check now​

If the machine is booting normally now, I’d verify these before doing a full nuke-and-pave:

In an elevated command prompt:​

manage-bde -status
Look for:

• Conversion Status
• Percentage Encrypted
• Protection Status
• Key Protectors

Check the boot files / firmware entry:​

bcdedit /enum all
and:

mountvol S: /S
dir S:\EFI\Microsoft\Boot

That confirms the EFI partition exists and has Microsoft boot files.

Recreate boot files if you want to be sure:​

bcdboot C:\Windows /s S: /f UEFI
That often fixes exactly this class of “boots only when installer media is present” problem.

Should you still clone/nuke/reinstall?​

Not necessarily.
If:

• manage-bde -status shows decryption completed cleanly
• bcdboot succeeds
• BIOS now shows Windows Boot Manager
• and the machine survives several cold boots without the USB attached

then you may already be out of the woods.

Bottom line​

Your mental model was mostly right, with one correction:

• C: can be encrypted
• EFI/system partition should remain unencrypted
• but firmware bootability depends on the UEFI boot entry and boot files, not just whether partitions exist

So the real mystery is less “how could BitLocker encrypt the boot path?” and more:

“Did automatic device encryption plus an incomplete protector/boot provisioning state leave the system in a weird UEFI boot configuration?”

I think the answer is yes, very possibly.
If you want, I can also help you interpret the output of:

manage-bde -status
bcdedit /enum firmware
bcdedit /enum all
diskpart
list disk
list vol

If you paste those, I can tell you exactly what state the machine is in.

 

[bitchucker]

thank you @ChatGPT, to clarify i did not necessarily think that the EFI partition was encrypted but i could not think of any other reason why the BIOS could not see anything to boot. but it sounds like the act of disabling bitlocker might have fixed up the MBR/EFI partitions and restored the bootloader.

i will try those commands you suggested to test the state of the system.

 

[ChatGPT]

You’re welcome — and yes, that is a reasonable working theory.

What I’d check next​

Run these in an elevated Command Prompt:

manage-bde -status
bcdedit /enum firmware
bcdedit /enum all
mountvol S: /S
dir S:\EFI\Microsoft\Boot

What you want to see​

manage-bde -status​

Look for:

• Conversion Status: Fully Decrypted or Fully Encrypted
• Protection Status: whether protection is actually on or off
• Key Protectors: TPM, recovery password, etc.

If it still says Decryption in Progress or Encryption in Progress, that would support the “transitional state” idea.

bcdedit /enum firmware​

You want to see a Windows Boot Manager entry in firmware.
If that entry is missing, that would explain why the BIOS/UEFI menu had nothing sensible to boot.

dir S:\EFI\Microsoft\Boot​

You want to confirm the EFI files are physically present, especially things like:

bootmgfw.efi
BCD

If the firmware entry looks wrong​

You can usually rebuild the Windows boot files with:
bcdboot C:\Windows /s S: /f UEFI

Important caution​

Before changing boot configuration:

1. Back up anything important
2. Create a restore point if possible
3. Make sure you have a working Windows installer USB handy

bcdboot is generally safe, but it is still a boot repair step.

My guess at this point​

If the machine now:

• cold boots normally
• reboots normally
• shows Windows Boot Manager in firmware
• and manage-bde reports a clean state

then you probably had a temporary BitLocker/device-encryption + UEFI boot entry inconsistency, and disabling BitLocker happened to push Windows into cleaning it up.
If you want, paste the output of those commands here and I’ll help interpret them line by line.