Does Windows boot through EFI System Partition or through another partition ?

I have a Windows 11 system complete with all UEFI CA 2023 certificates and with VBS and SkuSiPolicy.P7b file.

When I checked my system with @garlin 's check script, I always got no updates needed till today.

When I checked again today, I saw that my system had missing SkuSiPolicy.P7b file. Upon knowing this, I wanted to learn why SkuSiPolicy file was missing. It was not missing till today.

I mounted EFI system partition and looked into EFI\Microsoft\Boot folder in EFI system partition. There was a SkuSiPolicy file there. So why did the check script tell me SkuSiPolicy file was missing.

Upon looking further, I found out that there was a hidden EFI folder in C: Windows partition. EFI folder had a Microsoft folder inside it. Microsoft folder had a boot folder inside it. I looked into boot folder and there was no SkuSiPolicy file in it. I copied a SkuSiPolicy file from Windows\System32\SecureBootUpdates folder and pasted it in boot folder. I rechecked my system with check script. Everything came out fine. No missing SkuSiPolicy file. So I came to the conclusion that my Windows 11 boots to a hidden EFI folder in C: Windows partition.

This all happened, I believe, when I ran "bcdboot /bcdclean full" command in Windows Recovery environment. I did this because there were many entries in UEFI firmware which I believed redundant.

Unfortunately, bcdboot /bcdclean did not clean anything, I guess, in the UEFI firmware but made my system boot in a weird way.

Or the command removed a necessary entry in UEFI firmware that made my system boot legally through EFI system partition rather than through a folder in Windows partition.

To boot, UEFI checks the BCD store for a valid boot file entry, which points to a volume on a local or removable disk, or expects to receive a file from network boot.

This disk file must be stored on a FAT32 volume, because MS doesn't license NTFS and it would be too expensive to implement inside a limited BIOS size. When Windows creates the EFI, it also labels the partition type as GPT - System.

UEFI -> boot order option -> looks for EFI partition on named device -> looks for bootmgfw.efi, and falls back to bootx64.efi when bootmgfw.efi is missing

My check script has to believe what BCD store says, because a system could have multiple Windows drives (each with their own EFI volumes), or you've cloned or move the EFI volume from one disk to another. For booting purposes, we need to understand what the UEFI thinks is correct. And that goes back to the BCD store.

Like any non-Secure Boot problem, if you mess up the BCD store then stuff breaks. My script is not going to search through all possible FAT32 partitions looking for something that resembles a valid EFI and report it. On some systems, the EFI partition detection logic is bad but I have a pending fix to be released on Monday.

Thanks for the explanation. So the boot order is correct, as I understand. There is only one EFI system partition. I had two a couple of days back because this was a dual-boot system. A SATA drive with Windows 11 on it and an M.2 NVMe drive with Windows 11 on it. Then I disabled M.2 drive in BIOS leaving only a SATA Windows 11 drive. There are three other SATA drives for data storage. But they are all formatted as NTFS. No FAT32 partition on any of them.

For future reference, you absolutely need the two partitions with RED dots, to boot Windows.





When there are multiple drives involved, all others except the one you're installing Windows on, should be disconnected.
If they aren't, the Windows installer may put the EFI partition on another drive.

garlin said:

On some systems, the EFI partition detection logic is bad but I have a pending fix to be released on Monday.

Click to expand...

Does that explain the issue I was having with the latest Check_UEFI-CA2023.ps1 check script?

Ghot said:

For future reference, you absolutely need the two partitions with RED dots, to boot Windows.

View attachment 171118



When there are multiple drives involved, all others except the one you're installing Windows on, should be disconnected.
If they aren't, the Windows installer may put the EFI partition on another drive.

Click to expand...

Thanks. There is only one EFI system partition. No other drives contain FAT32 partition, EFI or else.

suatcini54 said:

There is only one EFI system partition. No other drives contain FAT32 partition, EFI or else.

Click to expand...

Good show. Now you're safe from the Installer God.

gunrunnerjohn said:

Does that explain the issue I was having with the latest Check_UEFI-CA2023.ps1 check script?

Click to expand...

Yes. I've been going through different methods of determining the EFI's location. They all work on single drive setups, but dual-boot or cloned drive setups could result in the script not locating the EFI volume. Nothing else really changed, except for the location code.

The reason for this hassle is I'm very concerned about false positives, where you update the wrong EFI that's not actually the one the UEFI cares about.

garlin said:

Yes. I've been going through different methods of determining the EFI's location. They all work on single drive setups, but dual-boot or cloned drive setups could result in the script not locating the EFI volume. Nothing else really changed, except for the location code.

The reason for this hassle is I'm very concerned about false positives, where you update the wrong EFI that's not actually the one the UEFI cares about.

Click to expand...

Well, certainly updating the wrong thing is probably worse than throwing an error and not updating anything! I can't argue with erring on the safe side here.