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 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.
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?
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.
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
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>
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 Thu, 21 May 2026 08:34:05 +0100, Andy Burns wrote:
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>
I haven't done a dual boot in a very long time. The last was openSUSE/ Windows 7. I found I very seldom booted to 7. I do have several computers
so Linux or Windows only is no problem.
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:
---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.
---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 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 :-)
| Sysop: | Scott Duensing |
|---|---|
| Location: | Freeburg, IL, USA, Earth |
| Users: | 5 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 494354:32:54 |
| Calls: | 5 |
| Messages: | 20,594 |