Some days things just go in a different direction than you expect. In today’s troubleshooting exercise, I had to figure out why a PC wasn’t booting as expected to a new UEFI boot entry created using the UEFIv2 module that I created sometime back. When I looked at the UEFI boot entries, I could see that instead of pointing to the 4th partition on the disk it was pointing to the 5th, but it had the correct partition signature for the 4th partition. How can that be? To answer that question requires digging a little deeper. Here’s what the partition structure looks like on a typical Windows install, from a PowerShell perspective:

OK, so there are four partitions, and the first one is normally where you would place the boot files for a UEFI boot entry. So where does this 5th partition come into play? Easy: if that boot partition (formatted FAT32, since that’s the only thing UEFI can boot from) doesn’t have enough space to hold the boot files, you need to create a new partition to hold those files. And that’s what was happening here, the C: drive (partition 3) was being shrunk by 1GB and then a new partition was created in its place to hold the boot files. To do that, you first need to shrink an existing volume to create some free space, really easy to do using the “Resize-Partition” cmdlet:

Then, you can create and format a new volume from the newly-available free space using “New-Partition” and then format that as a new volume using “Format-Volume”:

The interesting part is then the new output from Get-Partition:

Notice how the new partition, which is the 4th sequentially on the disk (partition index), has a partition number of 5, because that was the next available number? That caused problems with the “Add-UEFIBootEntry” cmdlet because it expected the partition number and the partition index to be the same — and if you would reboot Windows at this point and run “Get-Partition” again, it would be, the new partition would then be #4 with index 4.

So how do you avoid this without that extra reboot? Well, the simplest way is by modifying the Add-UEFIBootEntry cmdlet to have a new parameter so that you can specify both the partition number (to find the partition object, needed to get the partition signature, size, offset, etc. — all the details that are needed by a boot entry) and the partition index (needed to specify where its at on the disk, the partition number in the UEFI spec). With that in place, I can tell it what exactly I want:

Then we get the property entry pointing to the 4th partition on the disk:

And that partition signature matches the GUID of the partition (“47feea26-*”):

Task complete. I published a new version of UEFIv2 to the PowerShell Gallery in case you ever want to do a similar manipulation. (Probably unlikely, but hey, you never know.)