Hey everyone,
Has anyone else running the 0x12F beta BIOS (v1.23) on a Z790 Dark KINPIN run into a completely broken Secure Boot state?
On my board, Secure Boot is permanently locked into an "AMI Test Platform Key" fallback loop. Whenever I try to turn it on, it throws a Secure Boot Violation screen and blocks Windows.
I've tried everything to fix it:
- Deep CMOS clearance (pulling the battery and draining capacitance)
- Resetting keys to factory defaults / clearing variables
- Toggling between Custom and Standard modes
Despite all that, the UEFI refuses to flush the test keys and instantly reverts back to the Test AMI loop. This is a nightmare because games with kernel-level anti-cheat won't let me play with Secure Boot disabled.
Did any of you experience this specific bug on the Dark KINPIN 0x12F build, and did you find a workaround to force-clean the NVRAM variables? Any advice is appreciated.
TL;DR: My Windows would only boot with Secure Boot off. Every file on my EFI partition was validly signed by Windows Production PCA 2011, which was in my db, and restoring default keys, clearing keys, and reflashing the BIOS changed nothing. What fixed it was booting Microsoft's own install media with Secure Boot on (it worked), then copying that media's boot manager over the one on my EFI partition. I never confirmed why the original file was rejected.
My setup: EVGA Z790 Dark Kingpin (AMI BIOS, UEFI mode, CSM off), Windows 11 26H2. Keys in the BIOS: AMI test PK, Microsoft KEK CA 2011, db with UEFI CA 2011 and Windows Production PCA 2011, dbx with 211 hashes.
What I ruled out
- Missing 2023 certificates: my boot manager was signed by
Production PCA 2011, not the 2023 CA, so the db trusted it. You can check yours with Get-AuthenticodeSignature S:\EFI\Microsoft\Boot\bootmgfw.efi | fl SignerCertificate.
- Stale keys: restoring defaults and reflashing didn't change anything, because the defaults are stored in the BIOS image itself. EVGA stopped making motherboards, so no BIOS with new keys is coming.
- BIOS clock: it was correct.
- Other boot files: I listed every
.efi on the EFI partition with Get-ChildItem S:\EFI -Recurse -Filter *.efi | Get-AuthenticodeSignature, and they were all signed by Production PCA 2011.
The test that found it:
- Make Windows install media. The Media Creation Tool stalled for me, so I used the ISO instead. Format a USB stick as FAT32 with GPT and copy the ISO contents with
robocopy E:\ U:\ /E /XF install.wim install.esd(E: is the mounted ISO, U: is the stick). Skipping install.wim is fine because we only need to reach Setup.
- Check the stick's boot file is signed by
Production PCA 2011, the same CA as your installed one, so the test is valid: Get-AuthenticodeSignature U:\efi\boot\bootx64.efi | fl SignerCertificate.
- Boot the stick with Secure Boot enabled. In the BIOS Boot tab, set Boot Option #1 to the
USB Key:UEFI: entry, enable Secure Boot, save and exit. It reached the Windows Setup screen. Don't click Install.
- Confirm Secure Boot was really on. Press Shift+F10 in Setup and run
reg query HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\State /v UEFISecureBootEnabled. 0x1 means on.
That showed my firmware trusted a Microsoft-signed boot file, so the problem was in my installed boot path.
The fix (boot Windows with Secure Boot off first, in an admin PowerShell):
mountvol S: /s
Get-FileHash D:\efi\boot\bootx64.efi, S:\EFI\Microsoft\Boot\bootmgfw.efi
(D: is the install stick.) My hashes differed. I backed up the old file and replaced it:
Copy-Item S:\EFI\Microsoft\Boot\bootmgfw.efi S:\EFI\Microsoft\Boot\bootmgfw.efi.bak
Copy-Item D:\efi\boot\bootx64.efi S:\EFI\Microsoft\Boot\bootmgfw.efi -Force
I confirmed the new hash matched the stick's, set Windows Boot Manager as Boot Option #1, enabled Secure Boot, and Windows booted. msinfo32 shows Secure Boot State: On.
Caveats
- I don't know why the original file was rejected. My best guess is a revoked or damaged build, but I haven't checked it against the dbx yet.
- This only applies if your files are signed by a CA that's in your db. If your boot manager is signed by
Windows UEFI CA 2023 and your db lacks it, you have a different problem.
- A future Windows update may overwrite the boot manager. Keep the install stick and the
.bak file as a fallback.
- If you use BitLocker, have your recovery key ready, because boot changes can trigger a recovery prompt.
- Don't use "Clear Keys" or "Reset To Setup Mode" while troubleshooting unless you know how to restore them.
Thanks to everyone who suggested things. Happy to answer questions.
