Imagine following all the Micro$oft rule$, setting up your computer,
creating a Micro$oft account and configuraing your computer to be "safe"
with UEFI and "Secure Boot".
Except the certificate expires in June 2026 and it won't boot after that.
If your computer has no entitlement, it cannot get the updated certificate and you are shit out of luck.
Anything 2023 forward supposedly is okay and will get updates. Before
that? Tough.
What if it doesn't? All your boots are belong to us data recovery
companies.
On 5/18/2026 9:30 PM, anon wrote:
Imagine following all the Micro$oft rule$, setting up your computer,
creating a Micro$oft account and configuraing your computer to be "safe"
with UEFI and "Secure Boot".
Except the certificate expires in June 2026 and it won't boot after that.
If your computer has no entitlement, it cannot get the updated
certificate
and you are shit out of luck.
Anything 2023 forward supposedly is okay and will get updates.ÿ Before
that?ÿ Tough.
What if it doesn't?ÿ All your boots are belong to us data recovery
companies.
If this is true then there will be lawsuits.ÿÿ Many lawsuits.
Lynn
Imagine following all the Micro$oft rule$, setting up your computer, >creating a Micro$oft account and configuraing your computer to be "safe" >with UEFI and "Secure Boot".
Except the certificate expires in June 2026 and it won't boot after that.
If your computer has no entitlement, it cannot get the updated certificate >and you are shit out of luck.
Anything 2023 forward supposedly is okay and will get updates. Before
that? Tough.
What if it doesn't? All your boots are belong to us data recovery
companies.
I asked CoPilot
I don't use Secured Boot...
Act now: Secure Boot certificates expire in June 2026 - Windows IT Pro Blog <https://techcommunity.microsoft.com/blog/windows-itpro-blog/act-now-secure-boot-certificates-expire-in-june-2026/4426856>
I don't use Secured Boot...
Act now: Secure Boot certificates expire in June 2026 - Windows IT Pro Blog <https://techcommunity.microsoft.com/blog/windows-itpro-blog/act-now-secure-boot-certificates-expire-in-june-2026/4426856>
On Tue, 19 May 2026 11:44:14 +0100, Philip Herlihy wrote:
I asked CoPilot
<sigh>
Is it possible to disable Secure Boot and still keep Secure Boot installed Windows bootable?
"act now" and do what exactly?
"act now" and do what exactly?
For website, you just need to renew the certificate, which is stamped
with a new expiration date. :)
Philip's reply included all the relevant information.
AI/Copilot as the source/content is not the issue - it was accurate.
On Tue, 19 May 2026 13:48:30 +0800, Mr. Man-wai Chang wrote:
I don't use Secured Boot...
Act now: Secure Boot certificates expire in June 2026 - Windows IT Pro Blog >> <https://techcommunity.microsoft.com/blog/windows-itpro-blog/act-now-secure-boot-certificates-expire-in-june-2026/4426856>
Is it possible to disable Secure Boot and still keep Secure Boot installed Windows bootable?
On Tue, 19 May 2026 22:48:36 +0800, Mr. Man-wai Chang wrote:
"act now" and do what exactly?
For website, you just need to renew the certificate, which is stamped
with a new expiration date. :)
According to Le Chat (AI) Windows Updates will take care of it, but I
don't know if it's hallucinating or telling the truth.
On Tue, 19 May 2026 11:44:14 +0100, Philip Herlihy wrote:
I asked CoPilot
<sigh>
One 18 page document on Secure Boot, lists as one objective
that the device not be bricked. The device is allowed to retry
the defective transaction [snicker], or to try to boot from
another boot device [snicker], but that's kinda the definition
of insanity. There's no reason to believe (on average)
that for the machine, life is a box of chocolates. There might
easily only be one boot device, and a failure to move forward
is effectively brickage.
On Tue, 19 May 2026 10:31:05 -0400, ....winston wrote:
Philip's reply included all the relevant information.
AI/Copilot as the source/content is not the issue - it was accurate.
Well, I'm not going through a whole AI produced word salad. KISS and all that...
On 5/19/2026 11:02 AM, Paul wrote:
One 18 page document on Secure Boot, lists as one objective
that the device not be bricked. The device is allowed to retry
the defective transaction [snicker], or to try to boot from
another boot device [snicker], but that's kinda the definition
of insanity. There's no reason to believe (on average)
that for the machine, life is a box of chocolates. There might
easily only be one boot device, and a failure to move forward
is effectively brickage.
So this morning I again checked the event viewer and the secure boot
update still is failing. So I went back to the HP site and checked
again for a new BIOS. It reports I am on the latest version, nothing to
see here.
Do you think they are trying to address this issue across HP computers,
or are we all gonna be screwed one morning?
On Tue, 5/19/2026 8:40 AM, s|b wrote:
On Tue, 19 May 2026 11:44:14 +0100, Philip Herlihy wrote:
I asked CoPilot
<sigh>
One 18 page document on Secure Boot, lists as one objective
that the device not be bricked. The device is allowed to retry
the defective transaction [snicker], or to try to boot from
another boot device [snicker], but that's kinda the definition
of insanity. There's no reason to believe (on average)
that for the machine, life is a box of chocolates. There might
easily only be one boot device, and a failure to move forward
is effectively brickage.
Do you think they are trying to address this issue across HP computers,
or are we all gonna be screwed one morning?
sticks <wolverine01@charter.net> wrote:
On 5/19/2026 11:02 AM, Paul wrote:
One 18 page document on Secure Boot, lists as one objective
that the device not be bricked. The device is allowed to retry
the defective transaction [snicker], or to try to boot from
another boot device [snicker], but that's kinda the definition
of insanity. There's no reason to believe (on average)
that for the machine, life is a box of chocolates. There might
easily only be one boot device, and a failure to move forward
is effectively brickage.
So this morning I again checked the event viewer and the secure boot
update still is failing. So I went back to the HP site and checked
again for a new BIOS. It reports I am on the latest version, nothing to
see here.
Do you think they are trying to address this issue across HP computers,
or are we all gonna be screwed one morning?
As to the HP BIOS issue: I have an HP laptop with a rather old BIOS
("AMI F.07, 04/07/2023" according to System Information) and the 'Secure boot' part of 'Device security' of 'Windows Security' says I'm fine:
"<power icon with green tick-mark> Secure boot
Secure Boot is on and all required certificate
updates have been applied. No further
certificate changes are needed."
What does it say for you?
As to "are we all gonna be screwed one morning?", see my upcoming
response to Paul.
On 19/05/2026 17:30, sticks wrote:
Do you think they are trying to address this issue across HP computers,
or are we all gonna be screwed one morning?
This problem can be solved by purchasing a new HP or DELL machine, especially since it has been causing many people considerable sleep disruption! on these newsgroups not to mention blog writers.
sticks <wolverine01@charter.net> wrote:
On 5/19/2026 11:02 AM, Paul wrote:
One 18 page document on Secure Boot, lists as one objective
that the device not be bricked. The device is allowed to retry
the defective transaction [snicker], or to try to boot from
another boot device [snicker], but that's kinda the definition
of insanity. There's no reason to believe (on average)
that for the machine, life is a box of chocolates. There might
easily only be one boot device, and a failure to move forward
is effectively brickage.
So this morning I again checked the event viewer and the secure boot
update still is failing. So I went back to the HP site and checked
again for a new BIOS. It reports I am on the latest version, nothing to
see here.
Do you think they are trying to address this issue across HP computers,
or are we all gonna be screwed one morning?
As to the HP BIOS issue: I have an HP laptop with a rather old BIOS
("AMI F.07, 04/07/2023" according to System Information) and the 'Secure boot' part of 'Device security' of 'Windows Security' says I'm fine:
"<power icon with green tick-mark> Secure boot
Secure Boot is on and all required certificate
updates have been applied. No further
certificate changes are needed."
What does it say for you?
Searching on this seems to show it is unable to write correctly to the blocklist of untrusted boot files.ÿ Suggests changing some bios secure
boot key settings, and then running SFC /scannow.ÿ That all not too difficult and I think I might just try it out on this machine to see if
it makes any difference.
On 5/19/2026 4:07 PM, sticks wrote:
Searching on this seems to show it is unable to write correctly to the
blocklist of untrusted boot files.ÿ Suggests changing some bios secure
boot key settings, and then running SFC /scannow.ÿ That all not too
difficult and I think I might just try it out on this machine to see
if it makes any difference.
I went in and looked and the bios on this HP box does not have the
option available to change anything on the secure boot tab other than turning it off.ÿ The only thing I saw was on the security tab, there is
an option "restore security settings to factory defaults."ÿ I didn't do that.
It said TPM would be cleared as an example.ÿ Wonder if it would change
any settings on secure boot?
I asked CoPilot the following question:
**Prompt[snip]
I understand that Windows 10 computers will need their secure boot certificates updated soon. I've checked all the computers I have
running Windows 10 (all enrolled in Extended Security Updates) and all
are already updated. But if a friend has a Windows 10 computer which is
not enrolled in ESU, and they do nothing, will their computer suddenly
cease to boot? And if so, what can they do about it?
**Response**
Bottom line:
* The PC will not suddenly fail to boot
* Unsupported Windows 10 systems will gradually fall behind
* The real issue is long-term security, not immediate usability
On 5/19/2026 12:52 PM, Frank Slootweg wrote:
sticks <wolverine01@charter.net> wrote:
On 5/19/2026 11:02 AM, Paul wrote:
One 18 page document on Secure Boot, lists as one objective
that the device not be bricked. The device is allowed to retry
the defective transaction [snicker], or to try to boot from
another boot device [snicker], but that's kinda the definition
of insanity. There's no reason to believe (on average)
that for the machine, life is a box of chocolates. There might
easily only be one boot device, and a failure to move forward
is effectively brickage.
So this morning I again checked the event viewer and the secure boot
update still is failing.ÿ So I went back to the HP site and checked
again for a new BIOS.ÿ It reports I am on the latest version, nothing to >>> see here.
Do you think they are trying to address this issue across HP computers,
or are we all gonna be screwed one morning?
ÿÿ As to the HP BIOS issue: I have an HP laptop with a rather old BIOS
("AMI F.07, 04/07/2023" according to System Information) and the 'Secure
boot' part of 'Device security' of 'Windows Security' says I'm fine:
"<power icon with green tick-mark> Secure boot
ÿ Secure Boot is on and all required certificate
ÿ updates have been applied. No further
ÿ certificate changes are needed."
ÿÿ What does it say for you?
Well that is interesting.ÿ It says the same things for me.
I went back just now and looked and about 6 hours ago I got the same TPM-WMI Error in event viewer with the red exclamation point "The Secure Boot update failed to update SBAT with error Unknown HResult Error code:0x800700c1
Searching on this seems to show it is unable to write correctly to the blocklist of untrusted boot files.ÿ Suggests changing some bios secure boot key settings, and then running SFC /scannow.ÿ That all not too difficult and I think I might just try it out on this machine to see if it makes any difference.
It appears to me all this means that yeah it'll work and startup, you just don't get all the right things for it to check for malicious actors.
Thanks
On 5/19/2026 4:43 PM, sticks wrote:
On 5/19/2026 4:07 PM, sticks wrote:
Searching on this seems to show it is unable to write correctly to
the blocklist of untrusted boot files.ÿ Suggests changing some bios
secure boot key settings, and then running SFC /scannow.ÿ That all
not too difficult and I think I might just try it out on this machine
to see if it makes any difference.
I went in and looked and the bios on this HP box does not have the
option available to change anything on the secure boot tab other than
turning it off.ÿ The only thing I saw was on the security tab, there
is an option "restore security settings to factory defaults."ÿ I
didn't do that.
It said TPM would be cleared as an example.ÿ Wonder if it would change
any settings on secure boot?
Well I'll be damned.ÿ I then did a SFC /scannow and it did find some
errors and fixed them.ÿ Rebooted.ÿ Went into the event viewer and
instead of the FPM-WMI error it had 4 entries.ÿ A pre-attestation check,
a confirmation it is expected to pass attestation, TBS device identifier
has been generated, and finally "The TPM was successfully provisioned
and is now ready for use."
We'll see if it error faults again.
On Tue, 19 May 2026 11:44:14 +0100, Philip Herlihy wrote:
I asked CoPilot the following question:[snip]
**Prompt
I understand that Windows 10 computers will need their secure boot
certificates updated soon. I've checked all the computers I have
running Windows 10 (all enrolled in Extended Security Updates) and all
are already updated. But if a friend has a Windows 10 computer which is
not enrolled in ESU, and they do nothing, will their computer suddenly
cease to boot? And if so, what can they do about it?
**Response**
Bottom line:
* The PC will not suddenly fail to boot
* Unsupported Windows 10 systems will gradually fall behind
* The real issue is long-term security, not immediate usability
We know there's about a 10% chance that any given answer is wrong.
What we don't know, and can't know, is whether any given response,
including this one, is one of the 90% correct or the 10%
hallucinations (which, after all, sounds better than "lies").
On 05/19/2026 12:20 AM, Lynn McGuire wrote:
On 5/18/2026 9:30 PM, anon wrote:
Imagine following all the Micro$oft rule$, setting up your computer,
creating a Micro$oft account and configuraing your computer to be "safe" >>> with UEFI and "Secure Boot".
Except the certificate expires in June 2026 and it won't boot after
that.
If your computer has no entitlement, it cannot get the updated
certificate
and you are shit out of luck.
Anything 2023 forward supposedly is okay and will get updates.ÿ Before
that?ÿ Tough.
What if it doesn't?ÿ All your boots are belong to us data recovery
companies.
If this is true then there will be lawsuits.ÿÿ Many lawsuits.
Lynn
Most misunderstand the impact of not updating or not having the option
to update with the 2023 certs(to replace the expiring 2011 certs)
Unless prepared, physical devices and VMs will:
Lose the ability to install Secure Boot security updates after June 2026.
Not trust third-party software signed with new certificates after June
2026.
Not receive security fixes for Windows Boot Manager by October 2026.
</qp>
It's important to understand where the term 'boot' actually applies.
On 5/19/2026 1:08 AM, ....winston wrote:
On 05/19/2026 12:20 AM, Lynn McGuire wrote:
On 5/18/2026 9:30 PM, anon wrote:
Imagine following all the Micro$oft rule$, setting up your computer,
creating a Micro$oft account and configuraing your computer to be "safe" >>>> with UEFI and "Secure Boot".
Except the certificate expires in June 2026 and it won't boot after that. >>>>
If your computer has no entitlement, it cannot get the updated certificate >>>> and you are shit out of luck.
Anything 2023 forward supposedly is okay and will get updates.ÿ Before >>>> that?ÿ Tough.
What if it doesn't?ÿ All your boots are belong to us data recovery
companies.
If this is true then there will be lawsuits.ÿÿ Many lawsuits.
Lynn
Most misunderstand the impact of not updating or not having the option to update with the 2023 certs(to replace the expiring 2011 certs)
<qp>
Unless prepared, physical devices and VMs will:
Lose the ability to install Secure Boot security updates after June 2026.
Not trust third-party software signed with new certificates after June 2026. >> Not receive security fixes for Windows Boot Manager by October 2026.
</qp>
It's important to understand where the term 'boot' actually applies.
Thanks !
Lynn
On 5/19/2026 4:43 PM, sticks wrote:
On 5/19/2026 4:07 PM, sticks wrote:
Searching on this seems to show it is unable to write correctly to
the blocklist of untrusted boot files.ÿ Suggests changing some bios
secure boot key settings, and then running SFC /scannow.ÿ That all
not too difficult and I think I might just try it out on this machine
to see if it makes any difference.
I went in and looked and the bios on this HP box does not have the
option available to change anything on the secure boot tab other than
turning it off.ÿ The only thing I saw was on the security tab, there
is an option "restore security settings to factory defaults."ÿ I
didn't do that.
It said TPM would be cleared as an example.ÿ Wonder if it would change
any settings on secure boot?
Well I'll be damned.ÿ I then did a SFC /scannow and it did find some
errors and fixed them.ÿ Rebooted.ÿ Went into the event viewer and
instead of the FPM-WMI error it had 4 entries.ÿ A pre-attestation check,
a confirmation it is expected to pass attestation, TBS device identifier
has been generated, and finally "The TPM was successfully provisioned
and is now ready for use."
We'll see if it error faults again.
winston was not the only one who found what was said (a) useful (b) easy
to read. If you are determined to find otherwise, that's not our problem.
On 5/19/2026 5:00 PM, sticks wrote:[...]
Well I'll be damned.? I then did a SFC /scannow and it did find some errors and fixed them.? Rebooted.? Went into the event viewer and
instead of the FPM-WMI error it had 4 entries.? A pre-attestation check,
a confirmation it is expected to pass attestation, TBS device identifier has been generated, and finally "The TPM was successfully provisioned
and is now ready for use."
We'll see if it error faults again.
All for naught. Back again this morning. Disappointing
Log Name: System
Source: Microsoft-Windows-TPM-WMI
Date: 5/20/2026 6:53:06 AM
Event ID: 1796
Description: The Secure Boot update failed to update SBAT with error Unknown HResult Error code: 0x800700c1.
sticks <wolverine01@charter.net> wrote:
On 5/19/2026 5:00 PM, sticks wrote:[...]
Well I'll be damned.ÿ I then did a SFC /scannow and it did find some
errors and fixed them.ÿ Rebooted.ÿ Went into the event viewer and
instead of the FPM-WMI error it had 4 entries.ÿ A pre-attestation check, >>> a confirmation it is expected to pass attestation, TBS device identifier >>> has been generated, and finally "The TPM was successfully provisioned
and is now ready for use."
We'll see if it error faults again.
All for naught. Back again this morning. Disappointing
Log Name: System
Source: Microsoft-Windows-TPM-WMI
Date: 5/20/2026 6:53:06 AM
Event ID: 1796
Description: The Secure Boot update failed to update SBAT with error
Unknown HResult Error code: 0x800700c1.
If it's any consolation, I also get this error, twice a day, since at least 15/01/2026.
The error comes with a "For more information, please see..." link [1],
but that only mentions Event ID 1795, not 1796. However the 'Change log'
of the document implies that 1796 *is* documented. Microsoft moves in mysterious ways! :-(
I think that this 'Error' is nothing to worry about.
IMO, if we got a dollar for every 'Error' in our Event Viewer logs, we would make Elon look like a pauper! :-)
[1] 'Secure Boot DB and DBX variable update events' <https://support.microsoft.com/en-gb/topic/secure-boot-db-and-dbx-variable-update-events-37e47cf8-608b-4a87-8175-bdead630eb69>
On 5/20/2026 8:50 AM, Frank Slootweg wrote:
sticks <wolverine01@charter.net> wrote:
On 5/19/2026 5:00 PM, sticks wrote:[...]
Well I'll be damned.ÿ I then did a SFC /scannow and it did find some
errors and fixed them.ÿ Rebooted.ÿ Went into the event viewer and
instead of the FPM-WMI error it had 4 entries.ÿ A pre-attestation
check,
a confirmation it is expected to pass attestation, TBS device
identifier
has been generated, and finally "The TPM was successfully provisioned
and is now ready for use."
We'll see if it error faults again.
All for naught.ÿ Back again this morning.ÿ Disappointing
Log Name:ÿÿÿÿÿ System
Source:ÿÿÿÿÿÿÿ Microsoft-Windows-TPM-WMI
Date:ÿÿÿÿÿÿÿÿÿ 5/20/2026 6:53:06 AM
Event ID:ÿÿÿÿÿ 1796
Description:ÿ The Secure Boot update failed to update SBAT with error
Unknown HResult Error code: 0x800700c1.
ÿÿ If it's any consolation, I also get this error, twice a day, since at
least 15/01/2026.
ÿÿ The error comes with a "For more information, please see..." link [1],
but that only mentions Event ID 1795, not 1796. However the 'Change log'
of the document implies that 1796 *is* documented. Microsoft moves in
mysterious ways! :-(
ÿÿ I think that this 'Error' is nothing to worry about.
ÿÿ IMO, if we got a dollar for every 'Error' in our Event Viewer logs, we
would make Elon look like a pauper! :-)
[1] 'Secure Boot DB and DBX variable update events'
<https://support.microsoft.com/en-gb/topic/secure-boot-db-and-dbx-
variable-update-events-37e47cf8-608b-4a87-8175-bdead630eb69>
I know I can't do much more myself, and am not too worried about it. However, it does annoy me that the secure boot process is evidently
missing some of the available data because of the update failure.ÿ I
find it difficult to believe HP cannot figure out a way to fix this error.
Run this a Powershell admin window
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
ÿ- If the above command returns ?true,? then your PC is using the new certificate
If it returns true or false, the EventViewer error is normal.
ÿa. can't update(thus fails) if already present or not installed
On 5/20/2026 8:50 AM, Frank Slootweg wrote:
sticks <wolverine01@charter.net> wrote:
On 5/19/2026 5:00 PM, sticks wrote:[...]
Well I'll be damned.ÿ I then did a SFC /scannow and it did find some
errors and fixed them.ÿ Rebooted.ÿ Went into the event viewer and
instead of the FPM-WMI error it had 4 entries.ÿ A pre-attestation check, >>>> a confirmation it is expected to pass attestation, TBS device identifier >>>> has been generated, and finally "The TPM was successfully provisioned
and is now ready for use."
We'll see if it error faults again.
All for naught.ÿ Back again this morning.ÿ Disappointing
Log Name:ÿÿÿÿÿ System
Source:ÿÿÿÿÿÿÿ Microsoft-Windows-TPM-WMI
Date:ÿÿÿÿÿÿÿÿÿ 5/20/2026 6:53:06 AM
Event ID:ÿÿÿÿÿ 1796
Description:ÿ The Secure Boot update failed to update SBAT with error
Unknown HResult Error code: 0x800700c1.
ÿÿ If it's any consolation, I also get this error, twice a day, since at
least 15/01/2026.
ÿÿ The error comes with a "For more information, please see..." link [1],
but that only mentions Event ID 1795, not 1796. However the 'Change log'
of the document implies that 1796 *is* documented. Microsoft moves in
mysterious ways! :-(
ÿÿ I think that this 'Error' is nothing to worry about.
ÿÿ ÿÿ IMO, if we got a dollar for every 'Error' in our Event Viewer logs, we >> would make Elon look like a pauper! :-)
[1] 'Secure Boot DB and DBX variable update events'
<https://support.microsoft.com/en-gb/topic/secure-boot-db-and-dbx-variable-update-events-37e47cf8-608b-4a87-8175-bdead630eb69>
I know I can't do much more myself, and am not too worried about it. However, it does annoy me that the secure boot process is evidently missing some of the available data because of the update failure.ÿ I find it difficult to believe HP cannot figure out a way to fix this error.
---snip---I know I can't do much more myself, and am not too worried about it. However, it does annoy me that the secure boot process is evidently missing some of the available data because of the update failure.ÿ I find it difficult to believe HP cannot figure out a way to fix this error.
In my other post, I pasted this. This is a side effect of having
run Linux on your machine. Perhaps by some means, Microsoft notices
GRUB2 was used to launch Windows, and Microsoft wants to play the SBAT game.
On 5/20/2026 5:05 PM, Paul wrote:
I know I can't do much more myself, and am not too worried about it. However, it does annoy me that the secure boot process is evidently missing some of the available data because of the update failure.ÿ I find it difficult to believe HP cannot figure out a way to fix this error.
In my other post, I pasted this. This is a side effect of having---snip---
run Linux on your machine. Perhaps by some means, Microsoft notices
GRUB2 was used to launch Windows, and Microsoft wants to play the SBAT game.
Most of that was over my head, Paul.ÿ FWIW, I have never even tried Linux.
On 05/20/2026 10:11 AM, sticks wrote:
On 5/20/2026 8:50 AM, Frank Slootweg wrote:Run this a Powershell admin window
sticks <wolverine01@charter.net> wrote:
On 5/19/2026 5:00 PM, sticks wrote:[...]
Well I'll be damned.ÿ I then did a SFC /scannow and it did find some >>>>> errors and fixed them.ÿ Rebooted.ÿ Went into the event viewer and
instead of the FPM-WMI error it had 4 entries.ÿ A pre-attestation check, >>>>> a confirmation it is expected to pass attestation, TBS device identifier >>>>> has been generated, and finally "The TPM was successfully provisioned >>>>> and is now ready for use."
We'll see if it error faults again.
All for naught.ÿ Back again this morning.ÿ Disappointing
Log Name:ÿÿÿÿÿ System
Source:ÿÿÿÿÿÿÿ Microsoft-Windows-TPM-WMI
Date:ÿÿÿÿÿÿÿÿÿ 5/20/2026 6:53:06 AM
Event ID:ÿÿÿÿÿ 1796
Description:ÿ The Secure Boot update failed to update SBAT with error
Unknown HResult Error code: 0x800700c1.
ÿÿ If it's any consolation, I also get this error, twice a day, since at >>> least 15/01/2026.
ÿÿ The error comes with a "For more information, please see..." link [1], >>> but that only mentions Event ID 1795, not 1796. However the 'Change log' >>> of the document implies that 1796 *is* documented. Microsoft moves in
mysterious ways! :-(
ÿÿ I think that this 'Error' is nothing to worry about.
ÿÿ IMO, if we got a dollar for every 'Error' in our Event Viewer logs, we >>> would make Elon look like a pauper! :-)
[1] 'Secure Boot DB and DBX variable update events'
<https://support.microsoft.com/en-gb/topic/secure-boot-db-and-dbx- variable-update-events-37e47cf8-608b-4a87-8175-bdead630eb69>
I know I can't do much more myself, and am not too worried about it. However, it does annoy me that the secure boot process is evidently missing some of the available data because of the update failure.ÿ I find it difficult to believe HP cannot figure out a way to fix this error.
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
ÿ- If the above command returns ?true,? then your PC is using the new certificate
If it returns true or false, the EventViewer error is normal.
ÿa. can't update(thus fails) if already present or not installed
On Wed, 5/20/2026 7:31 PM, sticks wrote:
On 5/20/2026 5:05 PM, Paul wrote:
---snip---I know I can't do much more myself, and am not too worried about it. However, it does annoy me that the secure boot process is evidently missing some of the available data because of the update failure.ÿ I find it difficult to believe HP cannot figure out a way to fix this error.
In my other post, I pasted this. This is a side effect of having
run Linux on your machine. Perhaps by some means, Microsoft notices
GRUB2 was used to launch Windows, and Microsoft wants to play the SBAT game.
Most of that was over my head, Paul.ÿ FWIW, I have never even tried Linux.
We still have the issue, of why HP machines seem to have this problem.
None of my machines are HP, and I have an SBAT on the machine across the way, and not one on this machine. Perhaps Microsoft is applying this to all
of them, I cannot be certain.
On Tue, 19 May 2026 11:44:14 +0100, Philip Herlihy wrote:
I asked CoPilot
<sigh>
Paul wrote:
Secure Boot Advanced Targeting, is an attempt to
improve the efficiency of the contents of the dbx database. Microsoft
has to "care" about the buggy or not-buggy state of GRUB2, in order
to keep Windows secure
How many people know what's going on under the waterline?ÿ I make no claims to understand it, but since the era of virtualisation on PCs I've avoided dual boot.
<https://github.com/rhboot/shim/blob/main/SBAT.md>
On 5/20/2026 7:12 PM, Paul wrote:
On Wed, 5/20/2026 7:31 PM, sticks wrote:
On 5/20/2026 5:05 PM, Paul wrote:We still have the issue, of why HP machines seem to have this problem.
---snip---I know I can't do much more myself, and am not too worried about it. However, it does annoy me that the secure boot process is evidently missing some of the available data because of the update failure.ÿ I find it difficult to believe HP cannot figure out a way to fix this error.
In my other post, I pasted this. This is a side effect of having
run Linux on your machine. Perhaps by some means, Microsoft notices
GRUB2 was used to launch Windows, and Microsoft wants to play the SBAT game.
Most of that was over my head, Paul.ÿ FWIW, I have never even tried Linux. >>
None of my machines are HP, and I have an SBAT on the machine across the way,
and not one on this machine. Perhaps Microsoft is applying this to all
of them, I cannot be certain.
---snip---
thanks for the details.ÿ BTW, the laptop of my wife's that also has this error is also a HP machine.
On Wed, 5/20/2026 9:16 PM, sticks wrote:
On 5/20/2026 7:12 PM, Paul wrote:
On Wed, 5/20/2026 7:31 PM, sticks wrote:
On 5/20/2026 5:05 PM, Paul wrote:We still have the issue, of why HP machines seem to have this problem.
---snip---I know I can't do much more myself, and am not too worried about it. However, it does annoy me that the secure boot process is evidently missing some of the available data because of the update failure.ÿ I find it difficult to believe HP cannot figure out a way to fix this error.
In my other post, I pasted this. This is a side effect of having
run Linux on your machine. Perhaps by some means, Microsoft notices
GRUB2 was used to launch Windows, and Microsoft wants to play the SBAT game.
Most of that was over my head, Paul.ÿ FWIW, I have never even tried Linux. >>>
None of my machines are HP, and I have an SBAT on the machine across the way,
and not one on this machine. Perhaps Microsoft is applying this to all
of them, I cannot be certain.
---snip---
thanks for the details.ÿ BTW, the laptop of my wife's that also has this error is also a HP machine.
OK, I ran the question past CoPilot. Regarding the tar&feather of HP/Insyde, you are
likely to find slightly older machines that have not had the firmware updated,
can also fall through the cracks. My Asus motherboard (ROG STRIX B550-F GAMING WIFI II),
they did not seem to release an update when the others released their Black Lotus update,
yet that same motherboard is being re-released to help sell DDR4 systems and older processors,
as of a week or two ago...
****************** CoPilot Answer: SBAT question ****************************
Here is the direct, technically precise answer you?re looking for -
grounded in what SBAT *actually is*, how Windows handles it, where it is stored,
and why your HP/Insyde firmware is throwing **0x800700c1 (ERROR_BAD_EXE_FORMAT)**
during the SBAT update attempt.
---
## **1. Where SBAT data is *supposed* to live**
The four SBAT lines you see in the Registry:
sbat,1,2024010900
shim,4
grub,3
grub.debian,4
are **not** the final storage location.
They are **staging data** that Windows prepares before attempting to write SBAT into UEFI.
### **The actual target storage location is a UEFI authenticated variable:**
### **`SbatLevel`**
- Namespace: **EFI_GLOBAL_VARIABLE** (or vendor-specific namespace depending on firmware)
- Type: **EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS**
This is the same class of variable used for:
- `db` (allowed signatures)
- `dbx` (revoked signatures)
- `KEK`
- `PK`
SBAT is *not* stored in the DBX.
It is stored in its own dedicated authenticated variable, **SbatLevel**, defined by the Linux shim maintainers.
**Windows simply mirrors the Linux SBAT mechanism** and writes the same variable into UEFI.
---
## **2. Does UEFI firmware understand SBAT?**
### **Yes - but only if the OEM firmware implements SBAT support.**
SBAT is *not* part of the UEFI specification.
It is an **extension invented by the Linux shim project**, and firmware vendors must add support voluntarily.
### **What SBAT support requires in firmware**
The firmware must:
1. Recognize the SbatLevel authenticated variable.
2. Parse the CSV-like SBAT entries.
3. Compare the SBAT levels of bootloaders (shim, grub, etc.) against the stored SbatLevel.
4. Enforce revocation if the bootloader?s SBAT generation is too old.
### **Your HP 17t?cn400 (Insyde BIOS) almost certainly does *not* fully support SBAT.** <=== device ID not in my question!
This is consistent with:
- Missing HP support pages
- Missing BIOS updates
- Event ID 1796 / 1801
- Error **0x800700c1** during variable update
- The fact that PCA2023 succeeded but SBAT did not
---
## **3. Why Windows is trying to install SBAT**
Microsoft added SBAT support to Windows in 2024-2025 to:
- Reduce DBX bloat
- Block insecure Linux bootloaders
- Align with the Linux ecosystem
Windows now attempts to write SBAT into firmware **even on systems that never had Linux installed**.
This is exactly why Microsoft had to publish workarounds - the firmware ecosystem is not ready.
---
## **4. Why your SBAT update is failing with 0x800700c1**
### **0x800700c1 = ERROR_BAD_EXE_FORMAT**
This error is thrown when:
- The firmware rejects the authenticated variable payload
- The firmware does not recognize the variable format
- The firmware cannot parse the SBAT CSV
- The firmware does not support SBAT at all
- The firmware rejects the signature on the update capsule
### **Most likely cause on your HP/Insyde system**
Your firmware **does not implement SBAT support**, so when Windows attempts to write
the SbatLevel authenticated variable, the firmware returns:
- "Invalid format"
- "Unsupported variable"
- "Malformed authenticated payload"
Windows surfaces this as **0x800700c1**.
This is consistent with other HP and Intel systems reporting the same error.
---
## **5. Why the Registry shows SBAT data even though firmware rejected it** Windows stages SBAT data in:
HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT
This is **not** the authoritative store.
It is only the *input* for the Secure-Boot-Update scheduled task.
The firmware is the authoritative store.
If the firmware rejects the update, the Registry still shows the staged SBAT data, but:
- `UpdateStatus` remains non?zero
- Event ID 1796 continues
- Event ID 1801 continues
- No SbatLevel variable is written to UEFI
---
## **6. Why PCA2023 succeeded but SBAT did not**
PCA2023 updates:
- PK
- KEK
- db
- dbx
These are **standard UEFI variables** supported by all Secure Boot firmware.
SBAT is **not** standard UEFI.
Your firmware supports PCA2023 but **does not support SBAT**, so:
- PCA2023 --> success
- SBAT --> 0x800700c1 failure
This is exactly the pattern seen across many HP and Intel systems.
---
## **7. Summary - direct answers to your questions**
### **Q: What is the target storage location of the four SBAT lines?**
**A: The UEFI authenticated variable `SbatLevel` in NVRAM.**
Not the Registry, not DBX.
### **Q: Does the UEFI BIOS recognize SBAT encoding?**
**A: Only if the OEM implemented SBAT support.**
Your HP/Insyde firmware almost certainly did not.
### **Q: Why is the update failing with 0x800700c1?**
**A: The firmware is rejecting the SBAT authenticated variable as an unsupported or invalid format.**
This is a firmware limitation, not a Windows error.
---
## **8. The real root cause**
Your HP 17t?cn400 (Insyde F.13) firmware **does not support SBAT**, and Windows cannot force it to.
This is why:
- SBAT variable cannot be written
- Event 1796 persists
- Event 1801 persists
- UpdateStatus remains non-zero
- 0x800700c1 appears
This is a firmware defect or omission ? not a Windows configuration issue. ****************** End: CoPilot Answer ****************************
Paul
My Laptop had Win7 and a couple of Linuxs on it.[]
What a joke.
At this point all it looks like I can do to eliminate the error
and possible bricking (seems unlikely per Frank) is to keep checking
on a bios update.
On 2026/5/22 10:45:3, Daniel70 wrote:
[]
My Laptop had Win7 and a couple of Linuxs on it.[]
My spidey sense says the plural should be Linuces (pronounced Lie noo seez).
My spidey sense could be wrong :-)
https://en.wiktionary.org/wiki/Linuxes
This is the computer Linus used, at the start. At the moment,
I believe they are removing 486 support from the kernel.
By the way, that's enough memory for 1% of a Firefox tab.
On 05/20/2026 10:11 AM, sticks wrote:
On 5/20/2026 8:50 AM, Frank Slootweg wrote:Run this a Powershell admin window
sticks <wolverine01@charter.net> wrote:
On 5/19/2026 5:00 PM, sticks wrote:[...]
Well I'll be damned.ÿ I then did a SFC /scannow and it did find some >>>>> errors and fixed them.ÿ Rebooted.ÿ Went into the event viewer and
instead of the FPM-WMI error it had 4 entries.ÿ A pre-attestation
check,
a confirmation it is expected to pass attestation, TBS device
identifier
has been generated, and finally "The TPM was successfully provisioned >>>>> and is now ready for use."
We'll see if it error faults again.
All for naught.ÿ Back again this morning.ÿ Disappointing
Log Name:ÿÿÿÿÿ System
Source:ÿÿÿÿÿÿÿ Microsoft-Windows-TPM-WMI
Date:ÿÿÿÿÿÿÿÿÿ 5/20/2026 6:53:06 AM
Event ID:ÿÿÿÿÿ 1796
Description:ÿ The Secure Boot update failed to update SBAT with error
Unknown HResult Error code: 0x800700c1.
ÿÿ If it's any consolation, I also get this error, twice a day, since at >>> least 15/01/2026.
ÿÿ The error comes with a "For more information, please see..." link
[1],
but that only mentions Event ID 1795, not 1796. However the 'Change log' >>> of the document implies that 1796 *is* documented. Microsoft moves in
mysterious ways! :-(
ÿÿ I think that this 'Error' is nothing to worry about.
ÿÿ IMO, if we got a dollar for every 'Error' in our Event Viewer
logs, we
would make Elon look like a pauper! :-)
[1] 'Secure Boot DB and DBX variable update events'
<https://support.microsoft.com/en-gb/topic/secure-boot-db-and-dbx-
variable-update-events-37e47cf8-608b-4a87-8175-bdead630eb69>
I know I can't do much more myself, and am not too worried about it.
However, it does annoy me that the secure boot process is evidently
missing some of the available data because of the update failure.ÿ I
find it difficult to believe HP cannot figure out a way to fix this
error.
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
ÿ- If the above command returns ?true,? then your PC is using the new certificate
If it returns true or false, the EventViewer error is normal.
ÿa. can't update(thus fails) if already present or not installed
On 5/20/2026 10:11 AM, ....winston wrote:
On 05/20/2026 10:11 AM, sticks wrote:
On 5/20/2026 8:50 AM, Frank Slootweg wrote:Run this a Powershell admin window
sticks <wolverine01@charter.net> wrote:
On 5/19/2026 5:00 PM, sticks wrote:[...]
Well I'll be damned.ÿ I then did a SFC /scannow and it did find some >>>>>> errors and fixed them.ÿ Rebooted.ÿ Went into the event viewer and
instead of the FPM-WMI error it had 4 entries.ÿ A pre-attestation check, >>>>>> a confirmation it is expected to pass attestation, TBS device identifier >>>>>> has been generated, and finally "The TPM was successfully provisioned >>>>>> and is now ready for use."
We'll see if it error faults again.
All for naught.ÿ Back again this morning.ÿ Disappointing
Log Name:ÿÿÿÿÿ System
Source:ÿÿÿÿÿÿÿ Microsoft-Windows-TPM-WMI
Date:ÿÿÿÿÿÿÿÿÿ 5/20/2026 6:53:06 AM
Event ID:ÿÿÿÿÿ 1796
Description:ÿ The Secure Boot update failed to update SBAT with error >>>>> Unknown HResult Error code: 0x800700c1.
ÿÿ If it's any consolation, I also get this error, twice a day, since at >>>> least 15/01/2026.
ÿÿ The error comes with a "For more information, please see..." link [1], >>>> but that only mentions Event ID 1795, not 1796. However the 'Change log' >>>> of the document implies that 1796 *is* documented. Microsoft moves in
mysterious ways! :-(
ÿÿ I think that this 'Error' is nothing to worry about.
ÿÿ IMO, if we got a dollar for every 'Error' in our Event Viewer logs, we >>>> would make Elon look like a pauper! :-)
[1] 'Secure Boot DB and DBX variable update events'
<https://support.microsoft.com/en-gb/topic/secure-boot-db-and-dbx- variable-update-events-37e47cf8-608b-4a87-8175-bdead630eb69>
I know I can't do much more myself, and am not too worried about it. However, it does annoy me that the secure boot process is evidently missing some of the available data because of the update failure.ÿ I find it difficult to believe HP cannot figure out a way to fix this error.
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
ÿÿ- If the above command returns ?true,? then your PC is using the new certificate
If it returns true or false, the EventViewer error is normal.
ÿÿa. can't update(thus fails) if already present or not installed
Thought I'd follow up on this.ÿ Both HP desktops have finally gotten an available bios update.ÿ After install, both return true to winston's powershell
command, and both still have the same TPM-WMI error in the event log.ÿ still seems a weird way to do things...
On Wed, 6/10/2026 7:23 PM, sticks wrote:
On 5/20/2026 10:11 AM, ....winston wrote:
On 05/20/2026 10:11 AM, sticks wrote:
On 5/20/2026 8:50 AM, Frank Slootweg wrote:Run this a Powershell admin window
sticks <wolverine01@charter.net> wrote:
On 5/19/2026 5:00 PM, sticks wrote:[...]
Well I'll be damned.ÿ I then did a SFC /scannow and it did find some >>>>>>> errors and fixed them.ÿ Rebooted.ÿ Went into the event viewer and >>>>>>> instead of the FPM-WMI error it had 4 entries.ÿ A pre-attestation check,
a confirmation it is expected to pass attestation, TBS device identifier
has been generated, and finally "The TPM was successfully provisioned >>>>>>> and is now ready for use."
We'll see if it error faults again.
All for naught.ÿ Back again this morning.ÿ Disappointing
Log Name:ÿÿÿÿÿ System
Source:ÿÿÿÿÿÿÿ Microsoft-Windows-TPM-WMI
Date:ÿÿÿÿÿÿÿÿÿ 5/20/2026 6:53:06 AM
Event ID:ÿÿÿÿÿ 1796
Description:ÿ The Secure Boot update failed to update SBAT with error >>>>>> Unknown HResult Error code: 0x800700c1.
ÿÿ If it's any consolation, I also get this error, twice a day, since at >>>>> least 15/01/2026.
ÿÿ The error comes with a "For more information, please see..." link [1],
but that only mentions Event ID 1795, not 1796. However the 'Change log' >>>>> of the document implies that 1796 *is* documented. Microsoft moves in >>>>> mysterious ways! :-(
ÿÿ I think that this 'Error' is nothing to worry about.
ÿÿ IMO, if we got a dollar for every 'Error' in our Event Viewer logs, we
would make Elon look like a pauper! :-)
[1] 'Secure Boot DB and DBX variable update events'
<https://support.microsoft.com/en-gb/topic/secure-boot-db-and-dbx- variable-update-events-37e47cf8-608b-4a87-8175-bdead630eb69>
I know I can't do much more myself, and am not too worried about it. However, it does annoy me that the secure boot process is evidently missing some of the available data because of the update failure.ÿ I find it difficult to believe HP cannot figure out a way to fix this error.
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
ÿÿ- If the above command returns ?true,? then your PC is using the new certificate
If it returns true or false, the EventViewer error is normal.
ÿÿa. can't update(thus fails) if already present or not installed
Thought I'd follow up on this.ÿ Both HP desktops have finally gotten an
available bios update.ÿ After install, both return true to winston's powershell
command, and both still have the same TPM-WMI error in the event log.ÿ still >> seems a weird way to do things...
Agree on the weird part.
Tried to use a Linux today, on the Secure Boot machine, and I didn't know there was a new scheme for running a video card. There is some trick to
load a firmware into a video card, to act as the driver. This is Not Supported
on my video card, so that explains why the HD monitor was running at 1024x768.
I had to remove around 20 packages from the package manager, ones
that use the "new method", reboot, then use the Driver Manager, and it selected some legacy driver that does not use that method. and then
the HD screen was running at 1920x1080 again.
It seems some video card company <cough>, is angling for us to have to
buy some of those "cheep $400 video cards" :-) Just to have continued driver support.
I would certainly want a rich man to be able to afford another
leather jacket for presentations. The problem with schemes along
these lines, is it is going to make some laptop owners "very angry".
Thank goodness for innovation. "Where-ever it strikes".
Paul
Back on topic.
@Paul and @sticks
There are other powershell commands in admin mode that can be run for additional information on installation/updating 2023 certs.
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -match "2023"} | Select subject
For this Secure Boot enabled device(Win10 Pro ESU) with a 4th Gen
i7-4770 chip(yes, quite old) on a Asus Z87 Sabertooth mobo, last UEFI/
Bios March 2017) the results for the above commands are:
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name DB | Where-
Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name KEK | Where- Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
Fyi...for those interested in an explanation of DB and KEK certs
"DB (Allowed Signature Database): The list of certificates and trusted software the PC is allowed to run. The new 2023 DB certificates are used
to sign modern Windows boot components."
"KEK (Key Exchange Key): Often called the "master authority." The KEK
gives Microsoft (and your hardware manufacturer) the permission to
update your DB and DBX (revocation) lists without requiring a full
manual BIOS flash".
On 06/10/2026 7:58 PM, Paul wrote:
On Wed, 6/10/2026 7:23 PM, sticks wrote:
On 5/20/2026 10:11 AM, ....winston wrote:
On 05/20/2026 10:11 AM, sticks wrote:
On 5/20/2026 8:50 AM, Frank Slootweg wrote:Run this a Powershell admin window
sticks <wolverine01@charter.net> wrote:
On 5/19/2026 5:00 PM, sticks wrote:[...]
Well I'll be damned.ÿ I then did a SFC /scannow and it did find some >>>>>>>> errors and fixed them.ÿ Rebooted.ÿ Went into the event viewer and >>>>>>>> instead of the FPM-WMI error it had 4 entries.ÿ A pre-attestation check,
a confirmation it is expected to pass attestation, TBS device identifier
has been generated, and finally "The TPM was successfully provisioned >>>>>>>> and is now ready for use."
We'll see if it error faults again.
All for naught.ÿ Back again this morning.ÿ Disappointing
Log Name:ÿÿÿÿÿ System
Source:ÿÿÿÿÿÿÿ Microsoft-Windows-TPM-WMI
Date:ÿÿÿÿÿÿÿÿÿ 5/20/2026 6:53:06 AM
Event ID:ÿÿÿÿÿ 1796
Description:ÿ The Secure Boot update failed to update SBAT with error >>>>>>> Unknown HResult Error code: 0x800700c1.
ÿÿÿ If it's any consolation, I also get this error, twice a day, since at
least 15/01/2026.
ÿÿÿ The error comes with a "For more information, please see..." link [1],
but that only mentions Event ID 1795, not 1796. However the 'Change log' >>>>>> of the document implies that 1796 *is* documented. Microsoft moves in >>>>>> mysterious ways! :-(
ÿÿÿ I think that this 'Error' is nothing to worry about.
ÿÿÿ IMO, if we got a dollar for every 'Error' in our Event Viewer logs, we
would make Elon look like a pauper! :-)
[1] 'Secure Boot DB and DBX variable update events'
<https://support.microsoft.com/en-gb/topic/secure-boot-db-and-dbx- variable-update-events-37e47cf8-608b-4a87-8175-bdead630eb69>
I know I can't do much more myself, and am not too worried about it. However, it does annoy me that the secure boot process is evidently missing some of the available data because of the update failure.ÿ I find it difficult to believe HP cannot figure out a way to fix this error.
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
ÿÿÿ- If the above command returns ?true,? then your PC is using the new certificate
If it returns true or false, the EventViewer error is normal.
ÿÿÿa. can't update(thus fails) if already present or not installed
Thought I'd follow up on this.ÿ Both HP desktops have finally gotten an
available bios update.ÿ After install, both return true to winston's powershell
command, and both still have the same TPM-WMI error in the event log.ÿ still
seems a weird way to do things...
Agree on the weird part.
Tried to use a Linux today, on the Secure Boot machine, and I didn't know
there was a new scheme for running a video card. There is some trick to
load a firmware into a video card, to act as the driver. This is Not Supported
on my video card, so that explains why the HD monitor was running at 1024x768.
I had to remove around 20 packages from the package manager, ones
that use the "new method", reboot, then use the Driver Manager, and it
selected some legacy driver that does not use that method. and then
the HD screen was running at 1920x1080 again.
It seems some video card company <cough>, is angling for us to have to
buy some of those "cheep $400 video cards" :-) Just to have continued driver support.
I would certainly want a rich man to be able to afford another
leather jacket for presentations. The problem with schemes along
these lines, is it is going to make some laptop owners "very angry".
Thank goodness for innovation. "Where-ever it strikes".
ÿÿÿ Paul
Doesn't sound like a Secure Boot issue.
How old is that Secure Boot machine that 'tried to use' Linux?
How old is its video card.
Back on topic.
@Paul and @sticks
There are other powershell commands in admin mode that can be run for additional information on installation/updating 2023 certs.
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -match "2023"} | Select subject
For this Secure Boot enabled device(Win10 Pro ESU) with a 4th Gen i7-4770 chip(yes, quite old) on a Asus Z87 Sabertooth mobo, last UEFI/Bios March 2017) the results for the above commands are:
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
Fyi...for those interested in an explanation of DB and KEK certs
"DB (Allowed Signature Database): The list of certificates and trusted software the PC is allowed to run. The new 2023 DB certificates are used to sign modern Windows boot components."
"KEK (Key Exchange Key): Often called the "master authority." The KEK gives Microsoft (and your hardware manufacturer) the permission to update your DB and DBX (revocation) lists without requiring a full manual BIOS flash".
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -match "2023"} | Select subject
[MSI] MPG B550 Gaming Plus (MS-7C56) \
Infineon TPM 2.0 \
Ryzen 7 5700G 8C 16T CPU \
BIOS version 7/13/2024 AMI 1i0 \
DDR4 RAM (four sticks) \
\___ Both have been used for Secure Boot test.
[ASUS] ROG STRIX B550-F Gaming Wifi II / Secure Boot is now turned off on both.
fTPM (no header for a physical TPM 2.0) / They're PCA2023. One has failed a media Secure Boot
Ryzen 9 5950X 16C 32T CPU / where the media was still signed with PCA2011 and
BIOS version 1/4/2026 AMI 3636 / at a guess, that is revoked.
DDR4 RAM (four sticks) /
[Asus] P9X79 <=== used for testing non-Secure-Boot behaviors
no TPM at all (UEFI/CSM BIOS)
4930K 6C 12T (HEDT, 42 PCIe lanes) This machine has W10 and W11 and can test what
BIOS Version 12/24/2013 AMI 4608 miserable performance others might see. It has
DDR3 RAM (eight sticks) a mixture of HDD and SSDs for test. Mouse click to response, takes 1 second.
On 6/11/2026 9:19 PM, ....winston wrote:
Back on topic.
@Paul and @sticks
There are other powershell commands in admin mode that can be run for
additional information on installation/updating 2023 certs.
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -match
"2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -
match "2023"} | Select subject
For this Secure Boot enabled device(Win10 Pro ESU) with a 4th Gen
i7-4770 chip(yes, quite old) on a Asus Z87 Sabertooth mobo, last UEFI/
Bios March 2017) the results for the above commands are:
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name DB | Where-
Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name KEK | Where-
Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
Fyi...for those interested in an explanation of DB and KEK certs
"DB (Allowed Signature Database): The list of certificates and trusted
software the PC is allowed to run. The new 2023 DB certificates are
used to sign modern Windows boot components."
"KEK (Key Exchange Key): Often called the "master authority." The KEK
gives Microsoft (and your hardware manufacturer) the permission to
update your DB and DBX (revocation) lists without requiring a full
manual BIOS flash".
For the first command I only get your first entry, the second command I
get the same as yours.ÿ That ok?
On 06/12/2026 12:42 AM, Paul wrote:
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -match "2023"} | Select subject
[MSI] MPG B550 Gaming Plus (MS-7C56)ÿÿÿ \
Infineon TPM 2.0ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ \
Ryzen 7 5700G 8C 16T CPUÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ \
BIOS version 7/13/2024ÿ AMI 1i0ÿÿÿÿÿÿÿÿÿÿÿ \
DDR4 RAM (four sticks)ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ \
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ \___ Both have been used for Secure Boot test.
[ASUS] ROG STRIX B550-F Gaming Wifi IIÿÿÿÿÿÿ /ÿÿÿ Secure Boot is now turned off on both.
fTPM (no header for a physical TPM 2.0)ÿÿÿÿ /ÿÿÿÿ They're PCA2023. One has failed a media Secure Boot
Ryzen 9 5950X 16C 32T CPUÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ /ÿÿÿÿÿ where the media was still signed with PCA2011 and
BIOS version 1/4/2026ÿ AMI 3636ÿÿÿÿÿÿÿÿÿÿ /ÿÿÿÿÿÿ at a guess, that is revoked.
DDR4 RAM (four sticks)ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ /
[Asus] P9X79ÿ <=== used for testing non-Secure-Boot behaviors
no TPM at allÿ (UEFI/CSM BIOS)
4930K 6C 12Tÿÿ (HEDT, 42 PCIe lanes)ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ This machine has W10 and W11 and can test what
BIOS Version 12/24/2013ÿ AMI 4608ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ miserable performance others might see. It has
DDR3 RAM (eight sticks)ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ a mixture of HDD and SSDs for test. Mouse click to response, takes 1 second.
Did you run the get-securebootuefi on any of these devices or other devices(no virtual machines, but only devices with Windows 10 ESU or Win11 25H2 as the installed to metal o/s)?
If so, what were the results?
On Sat, 6/13/2026 9:16 PM, ....winston wrote:
On 06/12/2026 12:42 AM, Paul wrote:
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -match "2023"} | Select subject
[MSI] MPG B550 Gaming Plus (MS-7C56)ÿÿÿ \
Infineon TPM 2.0ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ \
Ryzen 7 5700G 8C 16T CPUÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ \
BIOS version 7/13/2024ÿ AMI 1i0ÿÿÿÿÿÿÿÿÿÿÿ \
DDR4 RAM (four sticks)ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ \
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ \___ Both have been used for Secure Boot test.
[ASUS] ROG STRIX B550-F Gaming Wifi IIÿÿÿÿÿÿ /ÿÿÿ Secure Boot is now turned off on both.
fTPM (no header for a physical TPM 2.0)ÿÿÿÿ /ÿÿÿÿ They're PCA2023. One has failed a media Secure Boot
Ryzen 9 5950X 16C 32T CPUÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ /ÿÿÿÿÿ where the media was still signed with PCA2011 and
BIOS version 1/4/2026ÿ AMI 3636ÿÿÿÿÿÿÿÿÿÿ /ÿÿÿÿÿÿ at a guess, that is revoked.
DDR4 RAM (four sticks)ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ /
[Asus] P9X79ÿ <=== used for testing non-Secure-Boot behaviors
no TPM at allÿ (UEFI/CSM BIOS)
4930K 6C 12Tÿÿ (HEDT, 42 PCIe lanes)ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ This machine has W10 and W11 and can test what
BIOS Version 12/24/2013ÿ AMI 4608ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ miserable performance others might see. It has
DDR3 RAM (eight sticks)ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ a mixture of HDD and SSDs for test. Mouse click to response, takes 1 second.
Did you run the get-securebootuefi on any of these devices or other devices(no virtual machines, but only devices with Windows 10 ESU or Win11 25H2 as the installed to metal o/s)?
If so, what were the results?
OK, so lets do that. First I have to turn Secure Boot back on.
This will be on the 5950X. Then I can select the Win10 on the same
machine, and see what is cooking over there.
First Win11.
msinfo32 (as administrator)
BIOS Mode: UEFI
Secure Boot State: ON
PCR7 Configuration: Binding Possible
Device Security
Secure Boot - Looks like a power button circle, with the tick at the top, and green
checkmark on the side. Text reads:
"Secure Boot is on and all required certificate updates have been applied.
No further certificate changes are needed." [SBAT status being ignored]
Yes, this is an Administrator Terminal, but currently, either "value" can show
up for the current working directory, for either terminal type.
PS C:\Users\bullwinkle> get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\Users\bullwinkle> get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
# Updates were stuck on the W11, due to (apparently) the recovery partition size.
# I Resized it using a Macrium backup and restore/resize without breaking it.
PS C:\Users\bullwinkle> reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration Information:
Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition5\Recovery\WindowsRE
Boot Configuration Data (BCD) identifier: 8f4fa731-3780-11ef-8ce3-b963a4dceb9a
Recovery image location:
Recovery image index: 0
Custom image location:
Custom image index: 0
Windows RE Version: 10.0.26100.8455
DISKPART> list part
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 100 MB 1024 KB
Partition 2 Reserved 16 MB 101 MB
Partition 3 Primary 108 GB 117 MB
Partition 5 Recovery 2068 MB 108 GB <=== Win11 is using its Recovery Partition
Partition 4 Primary 127 GB 110 GB <=== Win10 is using C: for the purpose "Access is Denied"
Winver on box reads as: 26200.8655
Oh, and the box logs in without using a password (local account) :-) Don't ask me how that happened, I haven't a clue.
*******
Now, we'll hop over to the Win10 side, and see what it says. The Win10 does not
have a Recovery partition. I hope it doesn't break anything. Doing a backup before heading over...
msinfo32 (as administrator)
BIOS Mode: UEFI
Secure Boot State: ON
PCR7 Configuration: Binding Possible
Device Security
Secure Boot - Looks like a power button circle, with the tick at the top, and green
checkmark on the side. Text reads:
"Secure boot is on, preventing malicious software from loading
when your device starts up."
"Your device meets the requirements for standard hardware security."
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Try the new cross-platform PowerShell https://aka.ms/pscore6
PS C:\Windows\system32> get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\Windows\system32> get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
PS C:\Windows\system32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration Information:
Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE <=== this is the C: drive of W10
Boot Configuration Data (BCD) identifier: 8f4fa72c-3780-11ef-8ce3-b963a4dceb9a
Recovery image location:
Recovery image index: 0
Custom image location:
Custom image index: 0
REAGENTC.EXE: Operation Successful.
Winver reads: 19045.7417 22H2 Windows 10 Home (my only ESU_
Box login requires password.
Paul
Comment:
Afaik, both o/s need to be updated. When Secure Boot and TPM present and enabled
(and if this a a dual boot) it is using the same UEFI/BIOS)....it would indicate
anything flashed into the mobo's firmware module would be common for both os especially
since Secure boot runs at the hardware level in the devices UEFI.
On Sat, 6/13/2026 9:16 PM, ....winston wrote:
On 06/12/2026 12:42 AM, Paul wrote:
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject
-match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject
-match "2023"} | Select subject
[MSI] MPG B550 Gaming Plus (MS-7C56) \
Infineon TPM 2.0 \
Ryzen 7 5700G 8C 16T CPU \
BIOS version 7/13/2024 AMI 1i0 \
DDR4 RAM (four sticks) \
\___ Both have been used for Secure Boot test.
[ASUS] ROG STRIX B550-F Gaming Wifi II / Secure Boot is now turned
off on both.
fTPM (no header for a physical TPM 2.0) / They're PCA2023. One has
failed a media Secure Boot
Ryzen 9 5950X 16C 32T CPU / where the media was still signed with
PCA2011 and
BIOS version 1/4/2026 AMI 3636 / at a guess, that is revoked.
DDR4 RAM (four sticks) /
[Asus] P9X79 <=== used for testing non-Secure-Boot behaviors
no TPM at all (UEFI/CSM BIOS)
4930K 6C 12T (HEDT, 42 PCIe lanes) This machine has W10 and W11 and
can test what
BIOS Version 12/24/2013 AMI 4608 miserable performance others might
see. It has
DDR3 RAM (eight sticks) a mixture of HDD and SSDs for test. Mouse
click to response, takes 1 second.
Did you run the get-securebootuefi on any of these devices or other
devices(no virtual machines, but only devices with Windows 10 ESU or
Win11 25H2 as the installed to metal o/s)?
If so, what were the results?
OK, so lets do that. First I have to turn Secure Boot back on.
This will be on the 5950X. Then I can select the Win10 on the same
machine, and see what is cooking over there.
First Win11.
msinfo32 (as administrator)
BIOS Mode: UEFI
Secure Boot State: ON
PCR7 Configuration: Binding Possible
Device Security
Secure Boot - Looks like a power button circle, with the tick at
the top, and green checkmark on the side. Text reads:
"Secure Boot is on and all required certificate
updates have been applied. No further certificate
changes are needed." [SBAT status being ignored]
Yes, this is an Administrator Terminal, but currently, either "value"
can show
up for the current working directory, for either terminal type.
PS C:\Users\bullwinkle> get-securebootuefi -decoded -name DB |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\Users\bullwinkle> get-securebootuefi -decoded -name KEK |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
# Updates were stuck on the W11, due to (apparently) the recovery
partition size. # I Resized it using a Macrium backup and
restore/resize without breaking it.
PS C:\Users\bullwinkle> reagentc /info
Windows Recovery Environment (Windows RE) and system reset
configuration
Information:
Windows RE status: Enabled
Windows RE location:
\\?\GLOBALROOT\device\harddisk0\partition5\Recovery\WindowsRE Boot
Configuration Data (BCD) identifier:
8f4fa731-3780-11ef-8ce3-b963a4dceb9a Recovery image location:
Recovery image index: 0 Custom image location:
Custom image index: 0
Windows RE Version: 10.0.26100.8455
DISKPART> list part
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 100 MB 1024 KB
Partition 2 Reserved 16 MB 101 MB
Partition 3 Primary 108 GB 117 MB
Partition 5 Recovery 2068 MB 108 GB <=== Win11 is
using its Recovery Partition Partition 4 Primary 127
GB 110 GB <=== Win10 is using C: for the purpose "Access is
Denied"
Winver on box reads as: 26200.8655
Oh, and the box logs in without using a password (local account) :-)
Don't
ask me how that happened, I haven't a clue.
*******
Now, we'll hop over to the Win10 side, and see what it says. The
Win10 does not
have a Recovery partition. I hope it doesn't break anything. Doing a
backup
before heading over...
msinfo32 (as administrator)
BIOS Mode: UEFI
Secure Boot State: ON
PCR7 Configuration: Binding Possible
Device Security
Secure Boot - Looks like a power button circle, with the tick at
the top, and green checkmark on the side. Text reads:
"Secure boot is on, preventing malicious software
from loading when your device starts up."
"Your device meets the requirements for standard
hardware security."
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Try the new cross-platform PowerShell https://aka.ms/pscore6
PS C:\Windows\system32> get-securebootuefi -decoded -name DB |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
D
PS C:\Windows\system32> get-securebootuefi -decoded -name KEK |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
PS C:\Windows\system32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset
configuration
Information:
Windows RE status: Enabled
Windows RE location:
\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
<=== this is the C: drive of W10 Boot Configuration Data (BCD)
identifier: 8f4fa72c-3780-11ef-8ce3-b963a4dceb9a Recovery image
location: Recovery image index: 0 Custom image location:
Custom image index: 0
REAGENTC.EXE: Operation Successful.
Winver reads: 19045.7417 22H2 Windows 10 Home (my only ESU_
Box login requires password.
Paul
Paul wrote:
On Sat, 6/13/2026 9:16 PM, ....winston wrote:
On 06/12/2026 12:42 AM, Paul wrote:
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject
-match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject
-match "2023"} | Select subject
[MSI] MPG B550 Gaming Plus (MS-7C56) \
Infineon TPM 2.0 \
Ryzen 7 5700G 8C 16T CPU \
BIOS version 7/13/2024 AMI 1i0 \
DDR4 RAM (four sticks) \
\___ Both have been used for Secure Boot test.
[ASUS] ROG STRIX B550-F Gaming Wifi II / Secure Boot is now turned
off on both.
fTPM (no header for a physical TPM 2.0) / They're PCA2023. One has
failed a media Secure Boot
Ryzen 9 5950X 16C 32T CPU / where the media was still signed with
PCA2011 and
BIOS version 1/4/2026 AMI 3636 / at a guess, that is revoked.
DDR4 RAM (four sticks) /
[Asus] P9X79 <=== used for testing non-Secure-Boot behaviors
no TPM at all (UEFI/CSM BIOS)
4930K 6C 12T (HEDT, 42 PCIe lanes) This machine has W10 and W11 and
can test what
BIOS Version 12/24/2013 AMI 4608 miserable performance others might
see. It has
DDR3 RAM (eight sticks) a mixture of HDD and SSDs for test. Mouse
click to response, takes 1 second.
Did you run the get-securebootuefi on any of these devices or other
devices(no virtual machines, but only devices with Windows 10 ESU or
Win11 25H2 as the installed to metal o/s)?
If so, what were the results?
OK, so lets do that. First I have to turn Secure Boot back on.
This will be on the 5950X. Then I can select the Win10 on the same
machine, and see what is cooking over there.
First Win11.
msinfo32 (as administrator)
BIOS Mode: UEFI
Secure Boot State: ON
PCR7 Configuration: Binding Possible
Device Security
Secure Boot - Looks like a power button circle, with the tick at
the top, and green checkmark on the side. Text reads:
"Secure Boot is on and all required certificate
updates have been applied. No further certificate
changes are needed." [SBAT status being ignored]
Yes, this is an Administrator Terminal, but currently, either "value"
can show
up for the current working directory, for either terminal type.
PS C:\Users\bullwinkle> get-securebootuefi -decoded -name DB |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\Users\bullwinkle> get-securebootuefi -decoded -name KEK |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
# Updates were stuck on the W11, due to (apparently) the recovery
partition size. # I Resized it using a Macrium backup and
restore/resize without breaking it.
PS C:\Users\bullwinkle> reagentc /info
Windows Recovery Environment (Windows RE) and system reset
configuration
Information:
Windows RE status: Enabled
Windows RE location:
\\?\GLOBALROOT\device\harddisk0\partition5\Recovery\WindowsRE Boot
Configuration Data (BCD) identifier:
8f4fa731-3780-11ef-8ce3-b963a4dceb9a Recovery image location:
Recovery image index: 0 Custom image location:
Custom image index: 0
Windows RE Version: 10.0.26100.8455
DISKPART> list part
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 100 MB 1024 KB
Partition 2 Reserved 16 MB 101 MB
Partition 3 Primary 108 GB 117 MB
Partition 5 Recovery 2068 MB 108 GB <=== Win11 is
using its Recovery Partition Partition 4 Primary 127
GB 110 GB <=== Win10 is using C: for the purpose "Access is
Denied"
Winver on box reads as: 26200.8655
Oh, and the box logs in without using a password (local account) :-)
Don't
ask me how that happened, I haven't a clue.
*******
Now, we'll hop over to the Win10 side, and see what it says. The
Win10 does not
have a Recovery partition. I hope it doesn't break anything. Doing a
backup
before heading over...
msinfo32 (as administrator)
BIOS Mode: UEFI
Secure Boot State: ON
PCR7 Configuration: Binding Possible
Device Security
Secure Boot - Looks like a power button circle, with the tick at
the top, and green checkmark on the side. Text reads:
"Secure boot is on, preventing malicious software
from loading when your device starts up."
"Your device meets the requirements for standard
hardware security."
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Try the new cross-platform PowerShell https://aka.ms/pscore6
PS C:\Windows\system32> get-securebootuefi -decoded -name DB |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
D
PS C:\Windows\system32> get-securebootuefi -decoded -name KEK |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
PS C:\Windows\system32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset
configuration
Information:
Windows RE status: Enabled
Windows RE location:
\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
<=== this is the C: drive of W10 Boot Configuration Data (BCD)
identifier: 8f4fa72c-3780-11ef-8ce3-b963a4dceb9a Recovery image
location: Recovery image index: 0 Custom image location:
Custom image index: 0
REAGENTC.EXE: Operation Successful.
Winver reads: 19045.7417 22H2 Windows 10 Home (my only ESU_
Box login requires password.
Paul
I am runnig Window 11 Pro and I am on 8457. I can not get updated and downloaded the cumulative update to 8655 but it will not update. Checking Device Security reports all is fine with certificates, etc.
diskpart shows:
Partition 4 Recovery 755MB 113GB
Partition 5 Recovery 800MB 114GB
Do I need to try and increase the size of the Recover Partitions?
I recognize this is not a lot of info.
<Bill>
Paul wrote:
On Sat, 6/13/2026 9:16 PM, ....winston wrote:
On 06/12/2026 12:42 AM, Paul wrote:
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject
-match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject
-match "2023"} | Select subject
[MSI] MPG B550 Gaming Plus (MS-7C56) \
Infineon TPM 2.0 \
Ryzen 7 5700G 8C 16T CPU \
BIOS version 7/13/2024 AMI 1i0 \
DDR4 RAM (four sticks) \
\___ Both have been used for Secure Boot test.
[ASUS] ROG STRIX B550-F Gaming Wifi II / Secure Boot is now turned
off on both.
fTPM (no header for a physical TPM 2.0) / They're PCA2023. One has
failed a media Secure Boot
Ryzen 9 5950X 16C 32T CPU / where the media was still signed with
PCA2011 and
BIOS version 1/4/2026 AMI 3636 / at a guess, that is revoked.
DDR4 RAM (four sticks) /
[Asus] P9X79 <=== used for testing non-Secure-Boot behaviors
no TPM at all (UEFI/CSM BIOS)
4930K 6C 12T (HEDT, 42 PCIe lanes) This machine has W10 and W11 and
can test what
BIOS Version 12/24/2013 AMI 4608 miserable performance others might
see. It has
DDR3 RAM (eight sticks) a mixture of HDD and SSDs for test. Mouse
click to response, takes 1 second.
Did you run the get-securebootuefi on any of these devices or other
devices(no virtual machines, but only devices with Windows 10 ESU or
Win11 25H2 as the installed to metal o/s)?
If so, what were the results?
OK, so lets do that. First I have to turn Secure Boot back on.
This will be on the 5950X. Then I can select the Win10 on the same
machine, and see what is cooking over there.
First Win11.
msinfo32 (as administrator)
BIOS Mode: UEFI
Secure Boot State: ON
PCR7 Configuration: Binding Possible
Device Security
Secure Boot - Looks like a power button circle, with the tick at
the top, and green checkmark on the side. Text reads:
"Secure Boot is on and all required certificate
updates have been applied. No further certificate
changes are needed." [SBAT status being ignored]
Yes, this is an Administrator Terminal, but currently, either "value"
can show
up for the current working directory, for either terminal type.
PS C:\Users\bullwinkle> get-securebootuefi -decoded -name DB |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\Users\bullwinkle> get-securebootuefi -decoded -name KEK |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
# Updates were stuck on the W11, due to (apparently) the recovery
partition size. # I Resized it using a Macrium backup and
restore/resize without breaking it.
PS C:\Users\bullwinkle> reagentc /info
Windows Recovery Environment (Windows RE) and system reset
configuration
Information:
Windows RE status: Enabled
Windows RE location:
\\?\GLOBALROOT\device\harddisk0\partition5\Recovery\WindowsRE Boot
Configuration Data (BCD) identifier:
8f4fa731-3780-11ef-8ce3-b963a4dceb9a Recovery image location:
Recovery image index: 0 Custom image location:
Custom image index: 0
Windows RE Version: 10.0.26100.8455
DISKPART> list part
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 100 MB 1024 KB
Partition 2 Reserved 16 MB 101 MB
Partition 3 Primary 108 GB 117 MB
Partition 5 Recovery 2068 MB 108 GB <=== Win11 is
using its Recovery Partition Partition 4 Primary 127
GB 110 GB <=== Win10 is using C: for the purpose "Access is
Denied"
Winver on box reads as: 26200.8655
Oh, and the box logs in without using a password (local account) :-)
Don't
ask me how that happened, I haven't a clue.
*******
Now, we'll hop over to the Win10 side, and see what it says. The
Win10 does not
have a Recovery partition. I hope it doesn't break anything. Doing a
backup
before heading over...
msinfo32 (as administrator)
BIOS Mode: UEFI
Secure Boot State: ON
PCR7 Configuration: Binding Possible
Device Security
Secure Boot - Looks like a power button circle, with the tick at
the top, and green checkmark on the side. Text reads:
"Secure boot is on, preventing malicious software
from loading when your device starts up."
"Your device meets the requirements for standard
hardware security."
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Try the new cross-platform PowerShell https://aka.ms/pscore6
PS C:\Windows\system32> get-securebootuefi -decoded -name DB |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
D
PS C:\Windows\system32> get-securebootuefi -decoded -name KEK |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
PS C:\Windows\system32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset
configuration
Information:
Windows RE status: Enabled
Windows RE location:
\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
<=== this is the C: drive of W10 Boot Configuration Data (BCD)
identifier: 8f4fa72c-3780-11ef-8ce3-b963a4dceb9a Recovery image
location: Recovery image index: 0 Custom image location:
Custom image index: 0
REAGENTC.EXE: Operation Successful.
Winver reads: 19045.7417 22H2 Windows 10 Home (my only ESU_
Box login requires password.
Paul
I am runnig Window 11 Pro and I am on 8457. I can not get updated and downloaded the cumulative update to 8655 but it will not update. Checking Device Security reports all is fine with certificates, etc.
diskpart shows:
Partition 4 Recovery 755MB 113GB
Partition 5 Recovery 800MB 114GB
Do I need to try and increase the size of the Recover Partitions?
I recognize this is not a lot of info.
<Bill>
On 06/11/2026 10:26 PM, sticks wrote:
On 6/11/2026 9:19 PM, ....winston wrote:
Back on topic.
@Paul and @sticks
There are other powershell commands in admin mode that can be run for
additional information on installation/updating 2023 certs.
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -
match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -
match "2023"} | Select subject
For this Secure Boot enabled device(Win10 Pro ESU) with a 4th Gen
i7-4770 chip(yes, quite old) on a Asus Z87 Sabertooth mobo, last
UEFI/ Bios March 2017) the results for the above commands are:
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name DB | Where-
Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name KEK |
Where- Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
Fyi...for those interested in an explanation of DB and KEK certs
"DB (Allowed Signature Database): The list of certificates and
trusted software the PC is allowed to run. The new 2023 DB
certificates are used to sign modern Windows boot components."
"KEK (Key Exchange Key): Often called the "master authority." The KEK
gives Microsoft (and your hardware manufacturer) the permission to
update your DB and DBX (revocation) lists without requiring a full
manual BIOS flash".
For the first command I only get your first entry, the second command
I get the same as yours.ÿ That ok?
With respect to CN=Microsoft Option ROM UEFI CA 2023
When not present, it can have a few reasons, the two most common in
simple answer form
- not yet deployed
- can't be deployed
One could force the attempt to deploy by changing the reg key HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates dword value to 0x5944 or 0x1844, exit regedit, then go to Task Scheduler(admin mode) and run the Secure Boot scheduled task, once done restart
twice(not shutdown, restart) then recheck.
If still missing, then it's likely related to firmware limitation or missing/non-existent support from the mobo or mobo manufacturer or
another possibility - the device never had the 2011 Option ROM 2011
There is quite a bit of variation for option ROM and KEK deployment.
ÿThere are ancient 4th gen and later Intel machines(not capable of
running Win11 but running Win10 ESU) that have both Option ROM and KEK
2023 updates deployed while later devices(Intel 7th through 14th gen) running Win11 25H2 not having one or both(Option ROM, KEK 2023)
On 6/14/2026 2:56 AM, ....winston wrote:
On 06/11/2026 10:26 PM, sticks wrote:
On 6/11/2026 9:19 PM, ....winston wrote:
Back on topic.
@Paul and @sticks
There are other powershell commands in admin mode that can be run
for additional information on installation/updating 2023 certs.
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -
match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -
match "2023"} | Select subject
For this Secure Boot enabled device(Win10 Pro ESU) with a 4th Gen
i7-4770 chip(yes, quite old) on a Asus Z87 Sabertooth mobo, last
UEFI/ Bios March 2017) the results for the above commands are:
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name DB |
Where- Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name KEK |
Where- Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US >>>>
Fyi...for those interested in an explanation of DB and KEK certs
"DB (Allowed Signature Database): The list of certificates and
trusted software the PC is allowed to run. The new 2023 DB
certificates are used to sign modern Windows boot components."
"KEK (Key Exchange Key): Often called the "master authority." The
KEK gives Microsoft (and your hardware manufacturer) the permission
to update your DB and DBX (revocation) lists without requiring a
full manual BIOS flash".
For the first command I only get your first entry, the second command
I get the same as yours.ÿ That ok?
With respect to CN=Microsoft Option ROM UEFI CA 2023
When not present, it can have a few reasons, the two most common in
simple answer form
- not yet deployed
- can't be deployed
One could force the attempt to deploy by changing the reg key
HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates
dword value to 0x5944 or 0x1844, exit regedit, then go to Task
Scheduler(admin mode) and run the Secure Boot scheduled task, once
done restart twice(not shutdown, restart) then recheck.
If still missing, then it's likely related to firmware limitation or
missing/non-existent support from the mobo or mobo manufacturer or
another possibility - the device never had the 2011 Option ROM 2011
There is quite a bit of variation for option ROM and KEK deployment.
ÿÿThere are ancient 4th gen and later Intel machines(not capable of
running Win11 but running Win10 ESU) that have both Option ROM and KEK
2023 updates deployed while later devices(Intel 7th through 14th gen)
running Win11 25H2 not having one or both(Option ROM, KEK 2023)
Mine is an intel core ultra 5 225 (arrow lake) processor which I think
is 2nd gen for the arrow lake, but it shows a launch date of Q1 2025 so
I assume these ultra processors would be considered a later device and
this is normal.
On 06/16/2026 9:05 AM, sticks wrote:
On 6/14/2026 2:56 AM, ....winston wrote:
On 06/11/2026 10:26 PM, sticks wrote:
On 6/11/2026 9:19 PM, ....winston wrote:
Back on topic.
@Paul and @sticks
There are other powershell commands in admin mode that can be run
for additional information on installation/updating 2023 certs.
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -
match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -
match "2023"} | Select subject
For this Secure Boot enabled device(Win10 Pro ESU) with a 4th Gen
i7-4770 chip(yes, quite old) on a Asus Z87 Sabertooth mobo, last
UEFI/ Bios March 2017) the results for the above commands are:
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name DB |
Where- Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name KEK |
Where- Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US >>>>>
Fyi...for those interested in an explanation of DB and KEK certs
"DB (Allowed Signature Database): The list of certificates and
trusted software the PC is allowed to run. The new 2023 DB
certificates are used to sign modern Windows boot components."
"KEK (Key Exchange Key): Often called the "master authority." The
KEK gives Microsoft (and your hardware manufacturer) the permission >>>>> to update your DB and DBX (revocation) lists without requiring a
full manual BIOS flash".
For the first command I only get your first entry, the second
command I get the same as yours.ÿ That ok?
With respect to CN=Microsoft Option ROM UEFI CA 2023
When not present, it can have a few reasons, the two most common in
simple answer form
- not yet deployed
- can't be deployed
One could force the attempt to deploy by changing the reg key
HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates
dword value to 0x5944 or 0x1844, exit regedit, then go to Task
Scheduler(admin mode) and run the Secure Boot scheduled task, once
done restart twice(not shutdown, restart) then recheck.
If still missing, then it's likely related to firmware limitation or
missing/non-existent support from the mobo or mobo manufacturer or
another possibility - the device never had the 2011 Option ROM 2011
There is quite a bit of variation for option ROM and KEK deployment.
ÿÿThere are ancient 4th gen and later Intel machines(not capable of
running Win11 but running Win10 ESU) that have both Option ROM and
KEK 2023 updates deployed while later devices(Intel 7th through 14th
gen) running Win11 25H2 not having one or both(Option ROM, KEK 2023)
Mine is an intel core ultra 5 225 (arrow lake) processor which I think
is 2nd gen for the arrow lake, but it shows a launch date of Q1 2025
so I assume these ultra processors would be considered a later device
and this is normal.
intel core ultra 5 225 - typically not classified with numerical gen
level. Instead of '2nd gen' it was classified iirc as Series 2.
Release wise, it's performance is plus or minus around the same point
and time as-14th Gen...better than 14th gen budget chips and worse than
14th gen mid-range.
ÿ- a good choice for a large quantity end-user consumer devices
On Mon, 6/15/2026 1:22 PM, Bill Bradshaw wrote:
Paul wrote:
On Sat, 6/13/2026 9:16 PM, ....winston wrote:
On 06/12/2026 12:42 AM, Paul wrote:
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject
-match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject
-match "2023"} | Select subject
[MSI] MPG B550 Gaming Plus (MS-7C56) \
Infineon TPM 2.0 \
Ryzen 7 5700G 8C 16T CPU \
BIOS version 7/13/2024 AMI 1i0 \
DDR4 RAM (four sticks) \
\___ Both have been used for Secure Boot test.
[ASUS] ROG STRIX B550-F Gaming Wifi II / Secure Boot is now turned
off on both.
fTPM (no header for a physical TPM 2.0) / They're PCA2023. One has
failed a media Secure Boot
Ryzen 9 5950X 16C 32T CPU / where the media was still signed with
PCA2011 and
BIOS version 1/4/2026 AMI 3636 / at a guess, that is revoked.
DDR4 RAM (four sticks) /
[Asus] P9X79 <=== used for testing non-Secure-Boot behaviors
no TPM at all (UEFI/CSM BIOS)
4930K 6C 12T (HEDT, 42 PCIe lanes) This machine has W10 and W11
and can test what
BIOS Version 12/24/2013 AMI 4608 miserable performance others
might see. It has
DDR3 RAM (eight sticks) a mixture of HDD and SSDs for test. Mouse
click to response, takes 1 second.
Did you run the get-securebootuefi on any of these devices or other
devices(no virtual machines, but only devices with Windows 10 ESU
or Win11 25H2 as the installed to metal o/s)?
If so, what were the results?
OK, so lets do that. First I have to turn Secure Boot back on.
This will be on the 5950X. Then I can select the Win10 on the same
machine, and see what is cooking over there.
First Win11.
msinfo32 (as administrator)
BIOS Mode: UEFI
Secure Boot State: ON
PCR7 Configuration: Binding Possible
Device Security
Secure Boot - Looks like a power button circle, with the tick at
the top, and green checkmark on the side. Text
reads:
"Secure Boot is on and all required certificate
updates have been applied. No further certificate
changes are needed." [SBAT status being ignored]
Yes, this is an Administrator Terminal, but currently, either
"value" can show
up for the current working directory, for either terminal type.
PS C:\Users\bullwinkle> get-securebootuefi -decoded -name DB |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\Users\bullwinkle> get-securebootuefi -decoded -name KEK |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation,
C=US
# Updates were stuck on the W11, due to (apparently) the recovery
partition size. # I Resized it using a Macrium backup and
restore/resize without breaking it.
PS C:\Users\bullwinkle> reagentc /info
Windows Recovery Environment (Windows RE) and system reset
configuration
Information:
Windows RE status: Enabled
Windows RE location:
\\?\GLOBALROOT\device\harddisk0\partition5\Recovery\WindowsRE
Boot Configuration Data (BCD) identifier:
8f4fa731-3780-11ef-8ce3-b963a4dceb9a Recovery image location:
Recovery image index: 0 Custom image location:
Custom image index: 0
Windows RE Version: 10.0.26100.8455
DISKPART> list part
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 100 MB 1024 KB
Partition 2 Reserved 16 MB 101 MB
Partition 3 Primary 108 GB 117 MB
Partition 5 Recovery 2068 MB 108 GB <=== Win11 is
using its Recovery Partition Partition 4 Primary 127
GB 110 GB <=== Win10 is using C: for the purpose "Access is
Denied"
Winver on box reads as: 26200.8655
Oh, and the box logs in without using a password (local account) :-)
Don't
ask me how that happened, I haven't a clue.
*******
Now, we'll hop over to the Win10 side, and see what it says. The
Win10 does not
have a Recovery partition. I hope it doesn't break anything. Doing a
backup
before heading over...
msinfo32 (as administrator)
BIOS Mode: UEFI
Secure Boot State: ON
PCR7 Configuration: Binding Possible
Device Security
Secure Boot - Looks like a power button circle, with the tick at
the top, and green checkmark on the side. Text
reads:
"Secure boot is on, preventing malicious software
from loading when your device starts up."
"Your device meets the requirements for standard
hardware security."
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Try the new cross-platform PowerShell https://aka.ms/pscore6
PS C:\Windows\system32> get-securebootuefi -decoded -name DB |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
D
PS C:\Windows\system32> get-securebootuefi -decoded -name KEK |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation,
C=US
PS C:\Windows\system32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset
configuration
Information:
Windows RE status: Enabled
Windows RE location:
\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
<=== this is the C: drive of W10 Boot Configuration Data (BCD)
identifier: 8f4fa72c-3780-11ef-8ce3-b963a4dceb9a Recovery image
location: Recovery image index: 0 Custom image location:
Custom image index: 0
REAGENTC.EXE: Operation Successful.
Winver reads: 19045.7417 22H2 Windows 10 Home (my only ESU_
Box login requires password.
Paul
I am runnig Window 11 Pro and I am on 8457. I can not get updated
and downloaded the cumulative update to 8655 but it will not update.
Checking Device Security reports all is fine with certificates, etc.
diskpart shows:
Partition 4 Recovery 755MB 113GB
Partition 5 Recovery 800MB 114GB
Do I need to try and increase the size of the Recover Partitions?
I recognize this is not a lot of info.
<Bill>
701,193,948 19 May 2026 (Win11 2.02GB Recovery partition contents)
Used TestDisk 7.0 for a quick look 571,237,983 15-Jun-2026 (Win10
C:\Recovery\WindowsRE contents) Also via
using TestDisk 7 to get around permissions. (This Win10 is the OS
that doesn't have its own Recovery Partition.)
Neither of these seems large enough to be held up by my partition
dimensions,
unless it is the "amount of margin" the scheme uses for updates. It
doesn't
just jam in the 701 thing and see if it fits, it takes the in-coming
size, adds
a couple hundred meg and checks whether that will fit.
I made the room for the 701 one as 2.02GB, just because I wanted the
job
done and then on to the next thing.
When an update does not go in, it is held in a waiting area in the
root of C: and the folder has a dollar sign in it. This is the state
of my "already-installed" one on Win11 (it's also in the 2.02GB
Recovery partition).
C:\$WinREAgent
Rollback\
Scratch\
Backup\
winre.wim 701,193,948 19 May 2026
boot.sdi 3,170,304 14 June 2026
ReAgent.xml 1,109 14 June 2026
location.txt
[WinRE Location]
Partition offset=117890351104 <=== booby trap
equipped... (when you cannot figure out why it Disabled
itself) Relative path=\Recovery\WindowsRE OS Guid={8F4FA72F-3780-11EF-8CE3-B963A4DCEB9A}
And normally, where that is stored, it will have some
permissions to annoy you. For some reason right now, I
can get into the Backup folder without using TestDisk :-)
If your attempt to update it has failed, one of the places
it could current be waiting is C:\$WinREAgent , but it has
more hidey holes than that.
Paul
On 6/16/2026 9:35 AM, ....winston wrote:
On 06/16/2026 9:05 AM, sticks wrote:
On 6/14/2026 2:56 AM, ....winston wrote:
On 06/11/2026 10:26 PM, sticks wrote:
On 6/11/2026 9:19 PM, ....winston wrote:
Back on topic.
@Paul and @sticks
There are other powershell commands in admin mode that can be run >>>>>> for additional information on installation/updating 2023 certs.
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject - >>>>>> match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject - >>>>>> match "2023"} | Select subject
For this Secure Boot enabled device(Win10 Pro ESU) with a 4th Gen >>>>>> i7-4770 chip(yes, quite old) on a Asus Z87 Sabertooth mobo, last
UEFI/ Bios March 2017) the results for the above commands are:
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name DB |
Where- Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\WINDOWS\system32> get-securebootuefi -decoded -name KEK |
Where- Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, >>>>>> C=US
Fyi...for those interested in an explanation of DB and KEK certs
"DB (Allowed Signature Database): The list of certificates and
trusted software the PC is allowed to run. The new 2023 DB
certificates are used to sign modern Windows boot components."
"KEK (Key Exchange Key): Often called the "master authority." The >>>>>> KEK gives Microsoft (and your hardware manufacturer) the
permission to update your DB and DBX (revocation) lists without
requiring a full manual BIOS flash".
For the first command I only get your first entry, the second
command I get the same as yours.ÿ That ok?
With respect to CN=Microsoft Option ROM UEFI CA 2023
When not present, it can have a few reasons, the two most common in
simple answer form
- not yet deployed
- can't be deployed
One could force the attempt to deploy by changing the reg key
HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates
dword value to 0x5944 or 0x1844, exit regedit, then go to Task
Scheduler(admin mode) and run the Secure Boot scheduled task, once
done restart twice(not shutdown, restart) then recheck.
If still missing, then it's likely related to firmware limitation or
missing/non-existent support from the mobo or mobo manufacturer or
another possibility - the device never had the 2011 Option ROM 2011
There is quite a bit of variation for option ROM and KEK deployment.
ÿÿThere are ancient 4th gen and later Intel machines(not capable of
running Win11 but running Win10 ESU) that have both Option ROM and
KEK 2023 updates deployed while later devices(Intel 7th through 14th
gen) running Win11 25H2 not having one or both(Option ROM, KEK 2023)
Mine is an intel core ultra 5 225 (arrow lake) processor which I
think is 2nd gen for the arrow lake, but it shows a launch date of Q1
2025 so I assume these ultra processors would be considered a later
device and this is normal.
intel core ultra 5 225 - typically not classified with numerical gen
level. Instead of '2nd gen' it was classified iirc as Series 2.
Release wise, it's performance is plus or minus around the same point
and time as-14th Gen...better than 14th gen budget chips and worse
than 14th gen mid-range.
ÿÿ- a good choice for a large quantity end-user consumer devices
I'm fine with the processor for what I use this machine for.ÿ My
question though was to make sure I understand your answer above about
later devices not having those other lines on the powershell result:
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
These two lines I don't get.ÿ I only get the Windows one:
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
For the later machines this is normal, right?
Paul wrote:
On Mon, 6/15/2026 1:22 PM, Bill Bradshaw wrote:
Paul wrote:
On Sat, 6/13/2026 9:16 PM, ....winston wrote:
On 06/12/2026 12:42 AM, Paul wrote:
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject
-match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject >>>>>>> -match "2023"} | Select subject
[MSI] MPG B550 Gaming Plus (MS-7C56) \
Infineon TPM 2.0 \
Ryzen 7 5700G 8C 16T CPU \
BIOS version 7/13/2024 AMI 1i0 \
DDR4 RAM (four sticks) \
\___ Both have been used for Secure Boot test.
[ASUS] ROG STRIX B550-F Gaming Wifi II / Secure Boot is now turned >>>>>> off on both.
fTPM (no header for a physical TPM 2.0) / They're PCA2023. One has >>>>>> failed a media Secure Boot
Ryzen 9 5950X 16C 32T CPU / where the media was still signed with
PCA2011 and
BIOS version 1/4/2026 AMI 3636 / at a guess, that is revoked.
DDR4 RAM (four sticks) /
[Asus] P9X79 <=== used for testing non-Secure-Boot behaviors
no TPM at all (UEFI/CSM BIOS)
4930K 6C 12T (HEDT, 42 PCIe lanes) This machine has W10 and W11
and can test what
BIOS Version 12/24/2013 AMI 4608 miserable performance others
might see. It has
DDR3 RAM (eight sticks) a mixture of HDD and SSDs for test. Mouse
click to response, takes 1 second.
Did you run the get-securebootuefi on any of these devices or other
devices(no virtual machines, but only devices with Windows 10 ESU
or Win11 25H2 as the installed to metal o/s)?
If so, what were the results?
OK, so lets do that. First I have to turn Secure Boot back on.
This will be on the 5950X. Then I can select the Win10 on the same
machine, and see what is cooking over there.
First Win11.
msinfo32 (as administrator)
BIOS Mode: UEFI
Secure Boot State: ON
PCR7 Configuration: Binding Possible
Device Security
Secure Boot - Looks like a power button circle, with the tick at
the top, and green checkmark on the side. Text
reads:
"Secure Boot is on and all required certificate
updates have been applied. No further certificate
changes are needed." [SBAT status being ignored]
Yes, this is an Administrator Terminal, but currently, either
"value" can show
up for the current working directory, for either terminal type.
PS C:\Users\bullwinkle> get-securebootuefi -decoded -name DB |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\Users\bullwinkle> get-securebootuefi -decoded -name KEK |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation,
C=US
# Updates were stuck on the W11, due to (apparently) the recovery
partition size. # I Resized it using a Macrium backup and
restore/resize without breaking it.
PS C:\Users\bullwinkle> reagentc /info
Windows Recovery Environment (Windows RE) and system reset
configuration
Information:
Windows RE status: Enabled
Windows RE location:
\\?\GLOBALROOT\device\harddisk0\partition5\Recovery\WindowsRE
Boot Configuration Data (BCD) identifier:
8f4fa731-3780-11ef-8ce3-b963a4dceb9a Recovery image location:
Recovery image index: 0 Custom image location:
Custom image index: 0
Windows RE Version: 10.0.26100.8455
DISKPART> list part
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 100 MB 1024 KB
Partition 2 Reserved 16 MB 101 MB
Partition 3 Primary 108 GB 117 MB
Partition 5 Recovery 2068 MB 108 GB <=== Win11 is
using its Recovery Partition Partition 4 Primary 127
GB 110 GB <=== Win10 is using C: for the purpose "Access is
Denied"
Winver on box reads as: 26200.8655
Oh, and the box logs in without using a password (local account) :-)
Don't
ask me how that happened, I haven't a clue.
*******
Now, we'll hop over to the Win10 side, and see what it says. The
Win10 does not
have a Recovery partition. I hope it doesn't break anything. Doing a
backup
before heading over...
msinfo32 (as administrator)
BIOS Mode: UEFI
Secure Boot State: ON
PCR7 Configuration: Binding Possible
Device Security
Secure Boot - Looks like a power button circle, with the tick at
the top, and green checkmark on the side. Text
reads:
"Secure boot is on, preventing malicious software
from loading when your device starts up."
"Your device meets the requirements for standard
hardware security."
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Try the new cross-platform PowerShell https://aka.ms/pscore6
PS C:\Windows\system32> get-securebootuefi -decoded -name DB |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
D
PS C:\Windows\system32> get-securebootuefi -decoded -name KEK |
Where-Object {$_.Subject -match "2023"} | Select subject
Subject
-------
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation,
C=US
PS C:\Windows\system32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset
configuration
Information:
Windows RE status: Enabled
Windows RE location:
\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
<=== this is the C: drive of W10 Boot Configuration Data (BCD)
identifier: 8f4fa72c-3780-11ef-8ce3-b963a4dceb9a Recovery image
location: Recovery image index: 0 Custom image location:
Custom image index: 0
REAGENTC.EXE: Operation Successful.
Winver reads: 19045.7417 22H2 Windows 10 Home (my only ESU_
Box login requires password.
Paul
I am runnig Window 11 Pro and I am on 8457. I can not get updated
and downloaded the cumulative update to 8655 but it will not update.
Checking Device Security reports all is fine with certificates, etc.
diskpart shows:
Partition 4 Recovery 755MB 113GB
Partition 5 Recovery 800MB 114GB
Do I need to try and increase the size of the Recover Partitions?
I recognize this is not a lot of info.
<Bill>
701,193,948 19 May 2026 (Win11 2.02GB Recovery partition contents)
Used TestDisk 7.0 for a quick look 571,237,983 15-Jun-2026 (Win10
C:\Recovery\WindowsRE contents) Also via
using TestDisk 7 to get around permissions. (This Win10 is the OS
that doesn't have its own Recovery Partition.)
Neither of these seems large enough to be held up by my partition
dimensions,
unless it is the "amount of margin" the scheme uses for updates. It
doesn't
just jam in the 701 thing and see if it fits, it takes the in-coming
size, adds
a couple hundred meg and checks whether that will fit.
I made the room for the 701 one as 2.02GB, just because I wanted the
job
done and then on to the next thing.
When an update does not go in, it is held in a waiting area in the
root of C: and the folder has a dollar sign in it. This is the state
of my "already-installed" one on Win11 (it's also in the 2.02GB
Recovery partition).
C:\$WinREAgent
Rollback\
Scratch\
Backup\
winre.wim 701,193,948 19 May 2026
boot.sdi 3,170,304 14 June 2026
ReAgent.xml 1,109 14 June 2026
location.txt
[WinRE Location]
Partition offset=117890351104 <=== booby trap
equipped... (when you cannot figure out why it Disabled
itself) Relative path=\Recovery\WindowsRE OS
Guid={8F4FA72F-3780-11EF-8CE3-B963A4DCEB9A}
And normally, where that is stored, it will have some
permissions to annoy you. For some reason right now, I
can get into the Backup folder without using TestDisk :-)
If your attempt to update it has failed, one of the places
it could current be waiting is C:\$WinREAgent , but it has
more hidey holes than that.
Paul
I got the computer updated to 8655. I installed the downloaded cumulative update 5094126. Checked secure boot was on and all certificates had been applied. Shutdown and restarted the computer and ran the cumulative update 5094126 downloaded file and then checked and I was on 8655. So all is good for now. I have enlarged recovery partitions in the past so I will look at this. Fingures crossed.
<Bill>
For the later machines this is normal, right?
As note before, variation exists.
Not all devices 'get' everything...and that is 'normal'
Failure to deploy Option ROM and Microsoft UEFI certs is 'normally'/ typically caused by existing device hardware/firmware limitation.
Two approaches may offer subsequent deployment of those two certs.
ÿ1. Updating the firmware(OEM or mobo manufacture UEFI/BIOS
ÿ2. Resetting Secure Boot in the UEFI/BIOS (Restoring Factory or
Installing Default Secure Boot Keys)
ÿOne or both may provide deployment of the 2023 cert keys on next restart(after the Schedule task runs, and two restarts).
Whatever the end result...it would still be normal(the same condition
before #1/#2, after 1/2, or doing nothing)
On 6/16/2026 1:31 PM, ....winston wrote:
For the later machines this is normal, right?
As note before, variation exists.
Not all devices 'get' everything...and that is 'normal'
Failure to deploy Option ROM and Microsoft UEFI certs is 'normally'/
typically caused by existing device hardware/firmware limitation.
Two approaches may offer subsequent deployment of those two certs.
ÿÿ1. Updating the firmware(OEM or mobo manufacture UEFI/BIOS
ÿÿ2. Resetting Secure Boot in the UEFI/BIOS (Restoring Factory or
Installing Default Secure Boot Keys)
ÿÿOne or both may provide deployment of the 2023 cert keys on next
restart(after the Schedule task runs, and two restarts).
Whatever the end result...it would still be normal(the same condition
before #1/#2, after 1/2, or doing nothing)
Thank you.ÿ Only thing I will do now is just check occasionally for
another bios update.ÿ It sounds like the rest will all work out.
You're welcome...in the meantime, fix your dual, and unnecessary two Recovery partitions using diskpart or 3rd party tools.
...and ensure you have a backup or know how to obtain winre.wim.
On 6/16/2026 7:12 PM, ....winston wrote:
You're welcome...in the meantime, fix your dual, and unnecessary two
Recovery partitions using diskpart or 3rd party tools.
...and ensure you have a backup or know how to obtain winre.wim.
I think you've got me mixed up with Bill in a offshoot of this thread.
You and Paul helped me fix my winre issues awhile ago when the
difficulties first began.ÿ Jeeze, that must be a couple years back by now.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 11 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 169:03:19 |
| Calls: | 219 |
| Files: | 21,503 |
| Messages: | 83,448 |