Solved garlin's PowerShell scripts for updating Secure Boot CA 2023

garlin said:

OK. I threw in more{ where $_.DriveLetter -match '[A-Z]' }so non-matches should be excluded.

Click to expand...

Nope. Same combination of error. Saw this message for the first 'Skipping USB Drive H: "VTOYEFI"'

Quandary said:

Nope. Same combination of error. Saw this message for the first 'Skipping USB Drive H: "VTOYEFI"'

Click to expand...

I'm teaching the script to ignore Ventoy drives for two simple reasons:

1. Ventoy uses its own GRUB bootloader, so there's no point in me trying to analyze it.
2. Ventoy allows you to drop any random set of ISO files, in any folder under \ventoy. Since there isn't a fixed naming convention, there's no point trying to hunt down a randomly named Windows ISO.

Try this magic query:

garlin said:

I'm teaching the script to ignore Ventoy drives for two simple reasons:

1. Ventoy uses its own GRUB bootloader, so there's no point in me trying to analyze it.
2. Ventoy allows you to drop any random set of ISO files, in any folder under \ventoy. Since there isn't a fixed naming convention, there's no point trying to hunt down a randomly named Windows ISO.

Try this magic query:

Code:

Get-CimInstance -ClassName Win32_LogicalDisk | where { $_.FileSystem -and ($_.Description -match 'Removable|CD-ROM') -or ($_.Description -match 'Fixed' -and $_.FileSystem -match 'FAT') }

Click to expand...

Ventoy is not the issue, its the Hasleo that raises the error.

The above magic quesry produced this with Hasleo
DeviceID DriveType ProviderName VolumeName Size FreeSpace
-------- --------- ------------ ---------- ---- ---------
F: 2 HASLEOBS 31583109120 30560075776

and this with Ventoy
DeviceID DriveType ProviderName VolumeName Size FreeSpace
-------- --------- ------------ ---------- ---- ---------
G: 2 Ventoy 30991024128 3305439232
H: 2 VTOYEFI 33277440 4493312

Last test version for the weekend. I switched to the new magic.

garlin said:

Last test version for the weekend. I switched to the new magic.

Click to expand...

This one still finds the GPT Fat32 USB SSD, but gives an error if it's the only USB storge device.

t2s50 said:

This one still finds the GPT Fat32 USB SSD, but gives an error if it's the only USB storge device.

Click to expand...

I can't repro this error, but here's a different sanity filter.

garlin said:

I can't repro this error, but here's a different sanity filter.

Click to expand...

Great. This one nailed it, no more errors.

When I attach my two bootable media (recovery USB drive and install USB stick) together with my USB hub, I get this with the script from post 3466:

PS C:\Users\admin\Downloads\SecureBoot-CA-2023-Updates.v2026.08.17> .\Check-Bootmedia.bat -Verbose
PowerShell 7.6.5
Windows 11 25H2 (26200.9168)

Secure Boot: ON
Virtualization Based Security: ON

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023

UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Microsoft Option ROM UEFI CA 2023
Microsoft UEFI CA 2023
Windows UEFI CA 2023

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 9.0

EFI Files
---------
SkuSiPolicy.p7b is CURRENT.
\\.\HarddiskVolume1\EFI\Microsoft\Boot\SkuSiPolicy.p7b
Version: 3.0.0.17

FileRule MinimumFileVersion MaximumFileVersion
-------- ------------------ ------------------
ID_FILEATTRIB_F_0044 0.0.0.0 10.0.14393.9399
ID_FILEATTRIB_F_0042 10.0.14400.0 10.0.17763.9099
ID_FILEATTRIB_F_0040 10.0.18000.0 10.0.19041.7639
ID_FILEATTRIB_F_0041 10.0.19100.0 10.0.20348.5479
ID_FILEATTRIB_F_0046 10.0.20400.0 10.0.22621.7494
ID_FILEATTRIB_F_0049 10.0.23000.0 10.0.26100.9140
ID_FILEATTRIB_F_0045 10.0.26100.32000 10.0.26100.33249
ID_FILEATTRIB_F_0048 10.0.26172.0 10.0.26172.33249
ID_FILEATTRIB_F_0047 10.0.27000.0 10.0.28000.2684
ID_FILEATTRIB_F_0043 10.0.29426.0 65535.65535.65535.65535


Bootable Media
--------------

USB Drive H: "RECOVERY"
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
H:\EFI\Microsoft\Boot\bootmgfw.efi
File Version: 28000.352, SVN 9.0

Boot File [Windows UEFI CA 2023] is ALLOWED.
H:\EFI\Boot\bootx64.efi
File Version: 28000.352, SVN 9.0

boot.wim:1 (WinRE 26100.1)
Boot Manager [Windows UEFI CA 2023] is ALLOWED.
\Windows\Boot\EFI_EX\bootmgfw_EX.efi
File Version: 28000.352, SVN 9.0

\Windows\System32\winload.efi is ALLOWED.
File Version: 26100.9168


USB Drive J: "Win11_25H2_EngUS_x64_14aug2026"
Boot File [Windows UEFI CA 2023] is ALLOWED.
J:\EFI\Boot\bootx64.efi
File Version: 28000.352, SVN 9.0

boot.wim:2 (WinPE 26100.9168)
Boot Manager [Windows UEFI CA 2023] is ALLOWED.
\Windows\Boot\EFI_EX\bootmgfw_EX.efi
File Version: 28000.352, SVN 9.0

\Windows\System32\winload.efi is ALLOWED.
File Version: 26100.9168

'Repair My PC' is broken.

J:\EFI\Microsoft\Boot\boot.stl [18/05/2026 19:44] is CURRENT.

install.esd:1 (W11 25H2 26200.9168)
Boot Manager [Windows UEFI CA 2023] is ALLOWED.
\Windows\Boot\EFI_EX\bootmgfw_EX.efi
File Version: 28000.352, SVN 9.0

\Windows\System32\winload.efi is ALLOWED.
File Version: 26100.9168

Skipping over the next 6 images.


USB Drive K: "RUFUS_BOOT"
Boot File [Microsoft Corporation UEFI CA 2011] is ALLOWED.
K:\EFI\Boot\bootx64.efi
[THIRD-PARTY] EFI File


PS C:\Users\admin\Downloads\SecureBoot-CA-2023-Updates.v2026.08.17>

When I attach these USB sticks alone on the USB hub, all works well too.

However, there is one direct USB port on my computer where my USB sticks are not recognised, due to a problem with the combination of X570 motherboards and the 5800X processor. They then recommended to set the pcie to gen3 instead of 4. It was supposed to have been resolved with some bios version, but that never happened on my machine. Depending upon the combination of bios version and settings in the bios, chipset version, and windows updates, it sometimes works, and sometimes not. I also disconnected the USB-C on the front panel completely, as it only caused problems.

On top of that, considering that the USB standard was defined in a pretty vague manner, there is a lot of variation in which components work well, and which USB sticks work on which USB ports. I can clearly see these differences on my three computers.

And of course, the number of USB endpoints may play a role on some computers.

So, maybe you also run into such issues, when trying to recognise all these different USB sticks.

Lastest from post #3466 still works for me
My frankenstein USB drive now comes out under "Fixed Drives"

For the last few weeks, your project has become more of a find the USB/removable/external drive... !

garlin said:

I can't repro this error, but here's a different sanity filter.

Click to expand...

Thank you, works flawlessly for me (except for the 'you lost another sub' stick, of course)

t2s50 said:

Thank you, works flawlessly for me (except for the 'you lost another sub' stick, of course)

Click to expand...

I don't want to open a new can of worms, by checking Fixed Disk + NTFS volumes.

1. Almost no UEFI's natively boot from NTFS. So it's technically not a boot volume.

2. While I could filter out any volume that doesn't have a \sources\boot.wim, that's still risking someone crazy enough out there.

3. You can inspect the boot.wim, using the local files feature:

garlin said:

I don't want to open a new can of worms, by checking Fixed Disk + NTFS volumes.

1. Almost no UEFI's natively boot from NTFS. So it's technically not a boot volume.

2. While I could filter out any volume that doesn't have a \sources\boot.wim, that's still risking someone crazy enough out there.

3. You can inspect the boot.wim, using the local files feature:

Code:

Check_BootMedia.ps1 H:\sources\boot.wim

Click to expand...

I suspect if you try to cover every possible iteration of systems, you'll be at this for a very long time!

UPDATE: 2028-08-18

1. Multiple USB removable drives aren't detected because I didn't bother testing with two drives
2. Relocate the rest of Check_UEFI-CA2023.ps1's "REQUIRED ACTIONS" code to Run-FiniteStateMachine()
3. Add backup URL for downloading wimlib-1.14.5
4. Check if boot.wim is missing two DLL files required for "Repair My PC" to work
5. Check_BootMedia.ps1 didn't check if a temporary WIM existed, and exporting a SWM caused unchecked appends to the temp file
6. Detect Ventoy USB drives from Check_BootMedia.ps1

Mostly big changes to the Check_BootMedia.ps1 script.

Thanks to everyone's patience and endless rounds of user testing, I believe we have a solution that correctly recognizes almost everyone's USB removable drives. Fixeds drive with a FAT/FAT32/exFAT filesystem will be scanned too. Except for @t2s50's backup copy of a boot drive (because he's a NTFS rebel).

Big thanks to @Quandary and @t2s50 for providing specific test cases that help me understand what the original logic was doing wrong. Props to everyone else who ran all the test scripts in the past 3 weeks.

I've added a backup method to download wimlib from the Wayback Machine (web.archive.org), when the primary website is not responding.

@fg2001gf11F's complaint about "Repair My PC" being broken in boot.wim (not winre.wim) is checked. But only in -Verbose mode, because not everyone cares about this WinPE feature and they would probably complain this notification confuses them.

Fixed some bugs with analyzing SWM files, mostly with how the temporary file was handled.

Detect you have a Ventoy drive, but we can't do much about verifying if it's bootable since Ventoy uses 3rd-party boot files (and we cannot check the MOK from Windows). We can't really scan the ISO files since you're allowed to place any kind of ISO and there isn't a forced standard for naming ISO files. The script is mostly saying "we know this is a Ventoy drive, so don't expect anything".

But you can always scan any Windows ISO file copied to the Ventoy drive (if you treat it as a standalone file):

garlin said:

1. Multiple USB removable drives aren't detected because I didn't bother testing with two drives

Click to expand...

It detects my Win 11 install and Macrium boot drives.

Scott said:

It detects my Win 11 install and Macrium boot drives.

Click to expand...

#1 should read "[BUG] Original script didn't work BECAUSE I didn't test with two drives".

I'm using a VMware test environment, and I can't do USB device pass-thru since my physical USB hub is maxed out. Also don't have a bunch of right-sized USB thumb drives to spare for testing. I ended up having to create two virtual USB drives just to see the bug.

Thanks for the renewed script- versions!

(There was a little discrepancy when I checked the winre- image with the -winre switch - your scripts reported 5247, the version read with DISM was 7548, but after having manually updated Winre.wim I no longer can reproduce that)

garlin said:

UPDATE: 2028-08-18

Click to expand...

A Big Thank you for all your hard work. Much appreciated.

Yes thank you.

t2s50 said:

(There was a little discrepancy when I checked the winre- image with the -winre switch

Click to expand...

Not just a little discrepancy here. Different results from Check-BootMedia, reagentc, and DISM. They must all be looking at different files.

Quandary said:

Not just a little discrepancy here. Different results from Check-BootMedia, reagentc, and DISM. They must all be looking at different files.

Click to expand...

Not Dism, that's just the tool version, you need the index parameter to get the image version! My Dism is on 3636, the image itself is on 7663 (now).