Event details
0x0002 means that a DBX update is pending It should get installed automatically by the scheduled task and then the value should return to 0x0000. When your machine reached the value 0x5946, it probably means that it used to be 0x0002 before the last secure boot update has been applied. The last DBX update was issued in October 2025, so either the DBX update has been sitting there unable to be installed for so long, or you recently reset your Secure Boot keys in the firmware.
I would suggest to only set individual bits and see if the scheduled task freezes when you try to do so.
0x0002 Apply DBX update.
0x0040 Apply DB update (Windows CA)
0x5800 Apply rest of the DB updates (Third-Party CA, Option ROM CA) - only if old certificate present. Will go to 0x4000 once done
0x0004 Apply KEK update
0x0100 Update the boot manager (on EFI partition) if all neede certificates are there
After everything that can be has been applied, set the value back to 0 (the scheduled task should then run without issues) and set HighConfidenceOptOut to 1 so that it will not update your Secure Boot keys automatically as part of monthly cumulative updates any longer.
In case 0x0040 freezes as well, could you try (if you feel confident) putting
"C:\Windows\Boot\EFI\SecureBootRecovery.efi" as \Efi\Boot\Bootx64.efi onto a bootable (Fat32 formatted) USB drive and boot from it? That should apply this single update as well, but it will do so from outside of Windows, so that drivers cannot interfere with it.
If you want to, share your results (which updates worked and which froze, and whether it works from SecureBootRecovery).
Out of curiosity:
- What is the value of BucketHash and ConfidenceLevel in
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing registry? The first is a hash of your mainboard model and firmware version and is used for controlled rollout only to known machines. The second is what Microsoft thinks how confident it is that the update will succeed. I would assume the latter being High since you got the update as part of LCU without manually fiddling.
- Do you have any telemetry enabled on your machine?
- Are there any third-party security products (antivirus, firewall) installed on your machine?
- Do you use games that use Anti-Cheat software or any other software that integrates as a low-level driver?
Thanks.
This description of the values should be documented on Microsoft Learn pages!
I tried to set 0x0040 and run the task after reboot, but still the same freeze.
As already said last month, I suspect the UEFI is simply badly implemented in regard to SecureBoot. It was one of the very first mainboard with SecureBoot in 2013/14...
So I think this mainboard simply do NOT allow any change in the SecureBoot settings. In the bios itself, there is also no other option than "reset key" to default .
As for Servicing values in Windows re:
BucketHash is
90d5affce870e9b93ad23b45571bb389302ade84cbf4da5253d6d709ed043739
- ConfidenceLevel is empty
- UEFICA2023Error and ErrorEvent are 0
- UEFICA2023Status InProgess
- WindowsUEFICA2023Capable is 2
And other parameters:
- Telemetry let to the "Require" setting, I suppose the SecureBoot stuff should be part of it.
- No third party antivirus, only the Microsoft stack. The machine still has win10 22h2 with ESU / March 2026 update
- No gaming on this old machine, so no Anti-Cheat software AFAIK
- Hypervisor activated and virtual box installed
The description of the values IS actually well documented here:
https://support.microsoft.com/en-us/topic/secure-boot-troubleshooting-guide-5d1bf6b4-7972-455a-a421-0184f1e1ed7d#bkmk_availableupdates_bits_used_for_certificate_servicing
That's 6 of the 11 documented values, and there are (at least) 3 undocumented flags as well... And there is no official place that documents them all :-(
This is odd, while this hash appears in the 2026-03 version of "C:\Windows\System32\SecureBootUpdates\BucketConfidenceData.cab" as High Confidence (this explains why the machine tried to attempt to install the update), it is entirely missing from the detailed lists at
https://github.com/microsoft/secureboot_objects/tree/main/HighConfidenceBuckets which are supposed to match the lists in this update.
Arden_White perhaps you can shed some light on
- how it can happen that a hash ended up in the High Confidence list despite machines that match this hash are obviously unable to install even only one of the certificates
- why there is a discrepancy between those two lists
PS: I posted this message earlier, received an error and could not find it. So I'm now posting it again. Sorry for the dupe in case it went through anyway.
Arden_White Same question about bucket hash 336bd28f3ef8c3557c593e27f92022b628b3e01bdc4682839adc14945e3449b2
Also in High Confidence list as of 2026-03 update, but not in the GitHub repo. And also somebody reported that they were able to install the Windows UEFI 2023 certificate to DB successfully, but the scheduled task froze their computer afterwards (when adding the other certs to DB) reproducibly.
Also, are there any safeguards that would detect the freezing of the task and skipping it in the future for machines whose bucket hash is in the High Confidence list? If yes, they must have failed here.