Solved Win 11 boots sucessfully, can't find its own BCD store it has used during boot

So I got this peculiar issue:

Had pretty clean Win11 install and about a week after the installation, I've added another SSD to the other m.2 slot which conntains an old install of Win10 that's been running on the older laptop. I've never booted into the old 10 install always ran exclusively 11.

Today, I found out I apparently don't have Windows recovery enabled/set up in the BCD store. But while attempting to set it up I ran into strange behaviour that has ultimately led me to the conclusion that Windows 11 just ... started using the BCD on the old Windows 10 drive. I got this asumption because the bcdedit was showing and editing BCD store that was on the other drive. And there were boot entries for both Windows systems. (Apparently especially Windows 11 can sometimes do weird stuff with BCD when installing major updates)


As I want to separate them back out I tried ... everything. I disabled the old drive in Win11, tried changing the name of the EFI folder on the Win10 ESP, I tried recreating boot entries on the Win11 ESP, in the UEFI NVRAM...

Now the only result I've ever gotten out of this is that Windows 11 now has apparently absolutely zero idea which BCD it has used during boot which makes this extra frustating to deal with. Because it boots somehow without a hitch yet after bootup has no idea where to look for the BCD which it utilized during boot. (Or rather can't access it yet still won't tell me where exactly it's looking for it)

So my question is - How can I find out which BCD is the Windows 11 currently booting with? And ideally - how can I manually specify which BCD to use after bootmgfw.efi execution?


Just to add: Both drives are GPT with standard Windows ESP UEFI partition layout.


Thankful for any helpful suggestions~!

It is very difficult to understand this. Post images of disk partitions.

please post a screenshot of disk managament.

if you unblock this zip, extract it and then run getbootdevice_x64.exe then post a screenhot of what it says, like this:

I've noticed windows for some time now has had an issue where if you have multiple drives connected during a fresh install, there's a 50/50 shot it puts the boot record on another drive.

Right now my C:\ drive windows ssd is disk4... but it put the boot record on Disk0 which is a spin drive used for storage.

Hi, Screenshots incoming... My apologies if it's hard to understand by my former description. Hope this will clear it up a bit for you.

I disabled the old drive in Win11

Click to expand...

what does that mean ?

how can I manually specify which BCD to use after bootmgfw.efi execution?

Click to expand...

It will look for \EFI\Microsoft\Boot\bcd

you can set the efi entries from within windows with tools such as free version of diskgenius

SIW2 said:

what does that mean ?

Click to expand...

Tried disabling it by bringing it to an "offline" state, you can do that in the diskmgmt or in the diskgenius as well. Later I also tried disabling it in the devmgmt. That way it won't even appear in the diskmgmt at all. The idea was to possibly make the drive inaccessible in as early boot stage as I could without disassembling the laptop to physically take it out.

Msprg said:

tried changing the name of the EFI folder on the Win10 ESP

Click to expand...

This also as imo it would potentially make bcd stored in there inaccessible so that the system would use the one from its own ESP.

SIW2 said:

you can set the efi entries from within windows with tools such as free version of diskgenius

Click to expand...

Thanks for the suggestion but that's not really the problem, at least I believe so. I tried booting via all the entry points such as bootmgfw.efi, bootmgr.efi and bootx64.efi. Nothing really changed all booted sucessfully yet windows's system BCD store remained inaccessible / was nowhere to be found.

Tried disabling it by bringing it to an "offline" state, you can do that in the diskmgmt or in the diskgenius as well. Later I also tried disabling it in the devmgmt. That way it won't even appear in the diskmgmt at all. The idea was to possibly make the drive inaccessible in as early boot stage as I could without disassembling the laptop to physically take it out.

Click to expand...

you would need to disable the disk in bios settings.

try diskgenius and see what it reveals about which efi boot file is in use.

getbootdevice shows that win11 states FirmwareBootDevice "\Device\Harddisk1\Partition1"

so it appears to be using \EFI\Microsoft\Boot\bootmgfw.efi on disk1

if so, then the issue could be bcdedit getting confused. Do you have any other instances of the efi folder, on an ntfs partition perhaps ?

SIW2 said:

It will look for \EFI\Microsoft\Boot\bcd

Click to expand...

Always on the same ESP as is the efi executable? Even if so, it still doesn't explain why Windows, once actually online (running) can't find / access it. Any way to find out where is win11, at that point, looking for it? Because it isn't even mounted under the HKLM.

SIW2 said:

try diskgenius and see what it reveals about which efi boot file is in use.

Click to expand...

It's the one on the KIOXIA's ESP which should be correct since that's where the W11 and it's ESP shall reside.


Also, this is what I mean when I say that the Windows doesn't know / can't get to BCD (for whatever reason)

SIW2 said:

getbootdevice shows that win11 states FirmwareBootDevice "\Device\Harddisk1\Partition1"

Click to expand...

Yes, that's correct and of no concern if I'm not missing anything obvious.

HD1 is the KIOXIA and as far sa the P1 is the 1-st (as in not indexing from 0) then that's still the apropriate ESP to boot from.

SIW2 said:

you would need to disable the disk in bios settings.

Click to expand...

I would have already tried that, If there would be such a setting but Laptop FW being Laptop FW... Not many settings to play with unfortunately. And I reaaaly doesn't want to be disassembling it yet again as I've just put it together about 3 days back.

Also, this is what I mean when I say that the Windows doesn't know / can't get to BCD

Click to expand...

I had a similar message when booting from efi file on os partition.

Although my bios is fine booting from os partition\efi\boot\boomgfw.efi and windows loads up fine, bcdedit doesn't understand it.

something seems to be confusing your bcdedit.exe

SIW2 said:

if so, then the issue could be bcdedit getting confused.

Click to expand...

SIW2 said:

something sems to be confusing your bcdedit.exe

Click to expand...

Yes, except more like the whole windows. besides bcdedit, msconfig doesn't really work, nor 3rd party such as easybcd. And as mentioned before I believe it also should be in the registry and it apparently is not.

I had a similar message when booting from efi file on os partition.

Click to expand...

Did the other sw also misbehave(d) at your end if you recall / have tried?

Did the other sw also misbehave(d) at your end if you recall

Click to expand...

It seemed ok as I remember. Though probably anything that required bcd access such as easybcd or msconfig wouldn't have liked it. Maybe I didnt look at those things.

might be worth checking your disk1 esp ID is {C12A7328-F81F-11D2-BA4B-00A0C93EC93B} and fat32 formatted.

SIW2 said:

{C12A7328-F81F-11D2-BA4B-00A0C93EC93B}

Click to expand...

AAAAAND NO, IT IS NOT!
In fact I failed to find ANY partition with such a GUID, which now makes sense given the Windows can't find it as well.
1. Where have you got that GUID from??
2. In case the GUIDs really are mismatched, I'm actually impressed it's still managing to boot up so reliably.


-----------

Msprg said:

1. Where have you got that GUID from??

Click to expand...

I really cannot figure out where did you get that ID from. And unless I figure that out, I can't really proceed.

I'm actually impressed it's still managing to boot up so reliably

Click to expand...

your efi firmware will probably search all fat32 partitions looking for the efi boot file. Some bios will also search ntfs partitions which is handy for booting from ntfs usb sticks.




you could try changing the ID, probably best done from diskgenius boot media.

maybe back up the partition table and the esp partition first which can be done form the diskgenius boot media. They are very small and can be done in a few seconds

to backup partition table, rt click the DISK and selct where to save the backup file - somewhere you can get at it later if needed.



rt click the esp partition and select clone partition to image file - select somewhere to save the image file where you can get at it if needed.




to change the partition ID:

rt click the esp partition and select Modify partition parameters >select EFI system partition in dropdown > OK >click Save All at top rt.

Then Reboot out of the diskgenius boot media and back into the disk and hope for the best.



Select esp system partition in the dropdown . Then Click OK



click Save All

Oh. You meant type GUID... Well, I say worth a shot. Worst case scenario I'll recreate the ESP. Will report back.

Alright so this is interesting... It worked for one boot - then after reboot it didn't.
I was about to remark whether it isn't a bit weird that:
1. The installation is fairly fresh yet the Type GUID got messed up already anyway, and
2. On my older install, the Type GUID is different as well, yet Windows 10 doesn't seem to have trouble finding its BCD store at all.
But as for the one reboot it has worked for, the next reboot the GUID changed again. And to something else than before. Great. At least I believe I got a pretty strong lead out of it.

Thanks for the assistance and your patience. You've been very helpful~!

Alright, so I believe it's solved then. The type GUID must be correct for Windows to find the BCD file on the ESP.

I've had to

1. Change the Type GUID,
2. Remove all UEFI NVRAM (non-native; ex.: IPv6 PXE) boot entries,
3. UEFI should recreate the necessary boot entries upon the next boot.

Since then seems Type GUID of my ESP hasn't changed. Therefore I believe I can call this the correct fix procedure for now.

Thanks to @SIW2 for helping me out with this~!
Marking as Solved.