My Computer
At a glance
Windows 7
- OS
- Windows 7
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Thank for going to all this trouble but I've just tried the new script, I've still got the ERROR: Failed to read UEFI Secure Boot settingsI will give you a different copy of the update script which bypasses the error (cannot read Secure Boot status). You are the 2nd person who's reported this problem with an older BIOS.
Choosing best option did select the 2023 cert.What does "Check_UEFI-CA2023.ps1 -BootMedia" report when the Macrium USB is plugged in?
Are you specifying the Signing Certificate under Options?
https://kbx.macrium.com/macrium-reflect-x/creating-rescue-media#Options
View attachment 164129
I don't know how good the "Choose the best option" logic is (whether it's detecting you can't use CA 2011).
Windows PowerShellChoosing best option did select the 2023 cert.
I suspect you have one of the "problem" firmwares which is too old, and can't be handled by a PowerShell script. Please reset the certs back to factory defaults. Because this is a really old PC, I would disable Secure Boot and leaving it alone. Don't want to risk making your PC unbootable.Thank for going to all this trouble but I've just tried the new script, I've still got the ERROR: Failed to read UEFI Secure Boot settings
PS C:\Users\Martin> C:\Users\Martin\Downloads\SecureBoot-CA-2023-Updates\Check_UEFI-CA2023.ps1 -bootmedia
Secure Boot: OFF
Virtualization Based Security: ON
BitLocker on (C:) OFF
Skipping an invalid Microsoft.SecureBoot.Commands.UEFIEnvironmentVariable X509 certificate.
Skipping an invalid Microsoft.SecureBoot.Commands.UEFIEnvironmentVariable X509 certificate.
That's not good. Somewhere you have a malformed cert or signature hash inserted in one of the UEFI variables.UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Skipping an invalid Microsoft.SecureBoot.Commands.UEFIEnvironmentVariable X509 certificate.
Windows BootMgr SVN 7.0
That's not good. Somewhere you have a malformed cert or signature hash inserted in one of the UEFI variables.
Can you run the cjee21 script for comparison? If you can't boot the Macrium drive, I'm leaning towards some form of UEFI corruption instead of a scripting error. You may have to perform a factory reset, and repeat the update process to get out of this.
I suspect you have one of the "problem" firmwares which is too old, and can't be handled by a PowerShell script. Please reset the certs back to factory defaults. Because this is a really old PC, I would disable Secure Boot and leaving it alone. Don't want to risk making your PC unbootable.
Windows will eventually complain about your lack of updated certs, but will continue to work with Secure Boot disabled.
technically, that [a "customized" SHA256] might make sense as the Secure Boot signature does not apply to all the PE data in the first place, so one could defeat the DBX by altering one of these sections, as they wouldn't invalidate the signature, but would change the hash from the DBX, [...] HOW HARD WOULD IT HAVE BEEN TO DESIGN A NEW PE CONTAINER EXTENSION [...]?
I also found this from MS, which explains the SkuSiPolicy.p7b context in depth. Summarizing it's one of the mitigations deployed to prevent a VBS rollback.


I believe the older version of the policy file was filled with EFI signature hashes (essentially duplicating DBX's block list), and it's switched to a smaller policy based on the SVN.SkuSiPolicy version is stored in bios/ firmware NVRAM, latest now is 3.0.0.13. SkuSiPolicy has become a lot smaller and now seems to be a revocation tool for the OS loaders winload.efi and winresume.efi only. Once copied in the correct place or updated there to a newer version the version info in NVRAM gets either updated if newer version or newly written into the NVRAM at next reboot.
162107 Dec 3 2023 23H2/SKUSiPolicy.P7b
55616 Sep 5 2024 24H2/SKUSiPolicy.P7b
6544 Sep 15 12:40 25h2/SKUSiPolicy.P7b
So in order to resolve the problem with some Insider builds not having a correct succession of higher versioned SkuSiPolicy's, the solution is:If SB is disabled and there's SkuSiPolicy version information in NVRAM but the file itself is deleted / no longer in UEFI parttition the NVRAM information is deleted next boot.
mountvol S: /s
del S:\EFI\Microsoft\Boot\SkuSiPolicy.p7b
mountvol S: /s
copy C:\Windows\System32\SecureBootUpdates\SkuSiPolicy.p7b S:\EFI\Microsoft\Boot\SkuSiPolicy.p7b
Normally if you have BitLocker on drive C:, suspend it for at least two reboots:Bitlocker is used on other 49 devices. I guess that "suspend" will be enough before these things.
Or do you recommend a full disabling of Bitlocker?
Suspend-BitLocker -MountPoint "C:" -RebootCount 2
I'm thinking about changing my check script's advice to install SkuSiPolicy.I ended up doing a new WinSetupFromUSB pendrive with the new "working" (it can boot with SB on) Windows Recovery disk, the new "working" v8.1.8631 RE Macrium Rescue media, and old RE and PE Macrium isos (including a v8.1.8631 PE) that were only booting with SB off. After deleting SkuSiPolicy.p7b from my system's ESP they all boot fine with Secure Boot enabled.
Recommended settings (to enable memory integrity without UEFI Lock):
To enable VBS without UEFI lock (value 0):
To enable VBS with UEFI lock (value 1):
To enable memory integrity without UEFI lock (value 0):
To enable memory integrity with UEFI lock (value 1):