OK. That output is kinda what I imagined. You have two System disks, and we need to determine which one has the active EFI partition.
Let me rethink how to approach this problem, since I've been trying to carefully not update the wrong partition (and have the required changes be missed on the proper partition).
I ran into the same issue again as the person you were responding to.
From what I could see, the script appeared to get stuck when resolving the ESP through the Win32_DiskPartition/Get-Partition path.
In my case, the Win32_DiskPartition query did see a GPT System partition on Disk 0, but the second query didn't line up:
Powershell:
PowerShell 7.6.1
PS C:\Users\RYSZARD> Get-CimInstance -Namespace 'Root\CIMv2' -Query 'SELECT * FROM Win32_DiskPartition' | where { $_.Type -eq 'GPT: System' }
Name NumberOfBlocks BootPartition PrimaryPartition Size Index
---- -------------- ------------- ---------------- ---- -----
Диск #0, раздел… 409600 True True 209715200 0
PS C:\Users\RYSZARD> Get-Partition -DiskNumber 0 | Where-Object { $_.Type -eq 'System' }
Get-Partition: No MSFT_Partition objects found with property 'DiskNumber' equal to '0'. Verify the value of the property and retry.
PS C:\Users\RYSZARD>
It appeared that the Win32_DiskPartition result and the Storage module/Get-Partition result were not lining up on this system.
I confirmed the ESP itself was fine by mounting it manually with mountvol /S, which exposed EFI\Microsoft\Boot and showed both bootmgfw.efi and SkuSiPolicy.p7b.
What worked for me was keeping the existing lookup logic first, but adding a fallback. If the Win32_DiskPartition/Get-Partition lookup does not return a usable ESP path, the script temporarily mounts the ESP using mountvol /S, verifies that EFI\Microsoft\Boot exists, uses that path for the check, and then unmounts the temporary drive letter afterward.
That also avoids hardcoding Disk 0 or assuming everyone’s ESP is mounted as S: or Z:.
Attached is the 'fixed' ps1 that worked in my case:
