Windows Secure Boot is EXPIRING: Do This Before June 2026!
Windows Secure Boot certificates are reaching their "End of Life"
starting June 2026. If you haven't updated your UEFI CA certificates,
your PC's boot-level security is about to expire and you may have
serious problems booting up your machine.
This only applies to UEFI boot. On Windows 10 this was not necessary but
for Windows 11 this is now mandatory. Whether Microsoft updates this
before they expire remains to be seen but you can manually upgrade it by using these PowerShell/Terminal commands as Administrator:
Check if it needs updating:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
-match 'Windows UEFI CA 2023'
If it shows false then you need to change the registry:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot
/v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Then run this in Terminal/PowerShell:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Article:
<https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#bkmk_takeaction>
On 3/5/26 6:30 PM, Jack wrote:
Windows Secure Boot is EXPIRING: Do This Before June 2026!This is so old it's pathetic.ÿ 2023.ÿ I would sure hope that some standard MS patch came down the line.ÿÿ It would be a pity if millions of windows 11 users got hung out to dry.
Windows Secure Boot certificates are reaching their "End of Life"
starting June 2026. If you haven't updated your UEFI CA certificates,
your PC's boot-level security is about to expire and you may have
serious problems booting up your machine.
This only applies to UEFI boot. On Windows 10 this was not necessary but
for Windows 11 this is now mandatory. Whether Microsoft updates this
before they expire remains to be seen but you can manually upgrade it by
using these PowerShell/Terminal commands as Administrator:
Check if it needs updating:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
-match 'Windows UEFI CA 2023'
If it shows false then you need to change the registry:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot
/v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Then run this in Terminal/PowerShell:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Article:
<https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#bkmk_takeaction>
Windows Secure Boot is EXPIRING: Do This Before June 2026!
Windows Secure Boot certificates are reaching their "End of Life"
starting June 2026. If you haven't updated your UEFI CA certificates,
your PC's boot-level security is about to expire and you may have
serious problems booting up your machine.
This only applies to UEFI boot. ...
On Thu, 3/5/2026 6:24 PM, Alan K. wrote:Paul, for those of us who are unaware of how, can you pass on your expertise on how to
On 3/5/26 6:30 PM, Jack wrote:
Windows Secure Boot is EXPIRING: Do This Before June 2026!This is so old it's pathetic.ÿ 2023.ÿ I would sure hope that some standard MS patch came down the line.ÿÿ It would be a pity if millions of windows 11 users got hung out to dry.
Windows Secure Boot certificates are reaching their "End of Life"
starting June 2026. If you haven't updated your UEFI CA certificates,
your PC's boot-level security is about to expire and you may have
serious problems booting up your machine.
This only applies to UEFI boot. On Windows 10 this was not necessary but >>> for Windows 11 this is now mandatory. Whether Microsoft updates this
before they expire remains to be seen but you can manually upgrade it by >>> using these PowerShell/Terminal commands as Administrator:
Check if it needs updating:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
-match 'Windows UEFI CA 2023'
If it shows false then you need to change the registry:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot
/v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Then run this in Terminal/PowerShell:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" >>>
Article:
<https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#bkmk_takeaction>
My recommendation, is to check in the BIOS to see if you can
connect a USB stick and back up the four files with the
certificates in it. Keeping those four files, gives
you the ability to reset the certificate state if there
are problems anywhere along the line.
As for the proposition, Microsoft is concern-trolling us again,
just like the WinRE problem they would not fix for themselves.
I am "less excited" this time, at the prospect of messing
around with my stuff.
Paul
On 3/5/26 7:01 PM, Paul wrote:
On Thu, 3/5/2026 6:24 PM, Alan K. wrote:Paul, for those of us who are unaware of how, can you pass on your expertise on how to grab those four files and replace them later.ÿ As much as I'm not sure I'll need it but there's nothing like being ready anyway.
On 3/5/26 6:30 PM, Jack wrote:
Windows Secure Boot is EXPIRING: Do This Before June 2026!This is so old it's pathetic.ÿ 2023.ÿ I would sure hope that some standard MS patch came down the line.ÿÿ It would be a pity if millions of windows 11 users got hung out to dry.
Windows Secure Boot certificates are reaching their "End of Life"
starting June 2026. If you haven't updated your UEFI CA certificates,
your PC's boot-level security is about to expire and you may have
serious problems booting up your machine.
This only applies to UEFI boot. On Windows 10 this was not necessary but >>>> for Windows 11 this is now mandatory. Whether Microsoft updates this
before they expire remains to be seen but you can manually upgrade it by >>>> using these PowerShell/Terminal commands as Administrator:
Check if it needs updating:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) >>>> -match 'Windows UEFI CA 2023'
If it shows false then you need to change the registry:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot >>>> /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Then run this in Terminal/PowerShell:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" >>>>
Article:
<https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#bkmk_takeaction>
My recommendation, is to check in the BIOS to see if you can
connect a USB stick and back up the four files with the
certificates in it. Keeping those four files, gives
you the ability to reset the certificate state if there
are problems anywhere along the line.
As for the proposition, Microsoft is concern-trolling us again,
just like the WinRE problem they would not fix for themselves.
I am "less excited" this time, at the prospect of messing
around with my stuff.
ÿÿÿ Paul
Jack <Jack@invalid.invalid> wrote:
Windows Secure Boot is EXPIRING: Do This Before June 2026!
Windows Secure Boot certificates are reaching their "End of Life"
starting June 2026. If you haven't updated your UEFI CA certificates,
your PC's boot-level security is about to expire and you may have
serious problems booting up your machine.
This only applies to UEFI boot. ...
Only if you have Secure Boot enabled in the BIOS. I don't.
On Thu, 3/5/2026 10:15 PM, Alan K. wrote:[]
On 3/5/26 7:01 PM, Paul wrote:
On Thu, 3/5/2026 6:24 PM, Alan K. wrote:
On 3/5/26 6:30 PM, Jack wrote:
Windows Secure Boot is EXPIRING: Do This Before June 2026!
y butThis only applies to UEFI boot. On Windows 10 this was not necessar
sfor Windows 11 this is now mandatory. Whether Microsoft updates thi
at some standardThis is so old it's pathetic.ÿ 2023.ÿ I would sure hope th
Though I'd admit to a certain Schadenfreude!
As for the proposition, Microsoft is concern-trolling us again,
just like the WinRE problem they would not fix for themselves.
I am "less excited" this time, at the prospect of messing
around with my stuff.
uch as I'm not sure I'll need it but there's nothing like being ready anyPaul, for those of us who are unaware of how, can you pass on your exp ertise on how to grab those four files and replace them later.ÿ As m
ÿÿÿ Paul
I didn't realize, that there is an interface at BIOS level, where
you can back up the MOK, db, dbx and the other one, and the BIOS
interface tells you to "plug in a USB stick". Usually, BIOS
Why should customers have to fuck around with this stuff ?
This makes no sense to me. I like a challenge, but this
is turning into just "more of the same", and I am less
game to be treated like a trained puppy.
boot. And again, we don't want to be put into a position
where the function of the machine is compromised in any way.
*******
In legacy BIOS era, how many concerns would I have ? I would
enable my disks, and the booting was a simple handoff from
legacy BIOS, to whatever I had attached to the computer.
I had complete freedom to use my computer the way I wanted
to.
What do we have today ? Hmmm.
I've warned people in previous years, that there was a
plan afoot to remove legacy (CSM) boot from BIOS soon
(by Intel). And that is likely to be the case for
equipment purchased now. What I don't know, is whether
Secure Boot in UEFI mode, can be switched on and off
as desired or not. Or for that matter, whether any amount
of modifications are to be expected to the UEFI four file
backup thing. The signed Linux shim, is supposed to use
PCA 2023 as part of its root. And in principle, we still
have the ability to boot other things. I don't know
if any FreeBSD-like OSes are included in this or not.
But with UEFI-only machines this year, a percentage
of my DVD collection would no longer boot. Some of my
legacy collection, will boot if you enter "noacpi"
as an option. With the price of hardware though, I
doubt I will be buying any more gear, any time soon.
Paul
On 2026-03-06 02:07, VanguardLH wrote:
Jack <Jack@invalid.invalid> wrote:
Windows Secure Boot is EXPIRING: Do This Before June 2026!
Windows Secure Boot certificates are reaching their "End of Life"
starting June 2026. If you haven't updated your UEFI CA certificates,
your PC's boot-level security is about to expire and you may have
serious problems booting up your machine.
This only applies to UEFI boot. ...
Only if you have Secure Boot enabled in the BIOS.ÿ I don't.
A friend has a W10 machine that I will have to update in the summer, so I will probably hit this. And to make it more interesting, the external backup disk boots Linux.
On 2026/3/6 4:27:10, Paul wrote:
On Thu, 3/5/2026 10:15 PM, Alan K. wrote:[]
On 3/5/26 7:01 PM, Paul wrote:
On Thu, 3/5/2026 6:24 PM, Alan K. wrote:
On 3/5/26 6:30 PM, Jack wrote:
Windows Secure Boot is EXPIRING: Do This Before June 2026!
This only applies to UEFI boot. On Windows 10 this was not necessary but >>>>>> for Windows 11 this is now mandatory. Whether Microsoft updates this
Is there a way to tell from a running W10 setup (i. e. without having to
do a reboot and watch for things flashing by) whether you have UEFI or
legacy boot? (And, if UEFI, whether you have "Secure Boot enabled"
[thanks VLH]?)
[]
Windows Secure Boot is EXPIRING: Do This Before June 2026!
Windows Secure Boot certificates are reaching their "End of Life"
starting June 2026. If you haven't updated your UEFI CA certificates,
your PC's boot-level security is about to expire and you may have
serious problems booting up your machine.
This only applies to UEFI boot. On Windows 10 this was not necessary but
for Windows 11 this is now mandatory. Whether Microsoft updates this
before they expire remains to be seen but you can manually upgrade it by using these PowerShell/Terminal commands as Administrator:
Check if it needs updating:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
-match 'Windows UEFI CA 2023'
If it shows false then you need to change the registry:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot
/v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Then run this in Terminal/PowerShell:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Article:
<https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#bkmk_takeaction>
On Fri, 3/6/2026 11:26 AM, J. P. Gilliver wrote:
On 2026/3/6 4:27:10, Paul wrote:
On Thu, 3/5/2026 10:15 PM, Alan K. wrote:[]
On 3/5/26 7:01 PM, Paul wrote:
On Thu, 3/5/2026 6:24 PM, Alan K. wrote:
On 3/5/26 6:30 PM, Jack wrote:
Windows Secure Boot is EXPIRING: Do This Before June 2026!
This only applies to UEFI boot. On Windows 10 this was not necessary but
for Windows 11 this is now mandatory. Whether Microsoft updates this
Is there a way to tell from a running W10 setup (i. e. without having to
do a reboot and watch for things flashing by) whether you have UEFI or
legacy boot? (And, if UEFI, whether you have "Secure Boot enabled"
[thanks VLH]?)
[]
If you go to Settings and enter TPM, the
Device Security on mine says:
"Security Processor"
...
standard hardware security not supported
Which means, roughly, that it is not enabled at BIOS level
and used for the current boot. (The Security Processor is
operating, but the BIOS is not switched to a state where
it wants to measure anything, like measure a boot process.)
The other entry in a Settings Search is "Security Processor"
and it says
Attestation Ready
Storage Ready
and above that it indicates the TPM type and version. And that
is indicating, that if I did enable Secure Boot at BIOS level, it
should work.
The fact a TPM is detected and it is listed as an Infineon device
(one of the manufacturers of such), that indicates there is a
secure enclave for any TPM based measuring and recording to be done.
But if the BIOS does not contain code for operating the TPM
for the Secure Boot feature, that is a "lack of Attestation".
For example, on the Optiplex 780, there is a TPM present, but
there is no BIOS code to use it. On the Test Machine, there is
no TPM present and there *is* BIOS code to use it. And these
non-comformances prevent Secure Boot from happening.
If I do Start : Run : msinfo32, then look at System Summary
(there is at least one other MSFT utility to display this), it says:
BIOS Mode UEFI
Secure Boot State Off
and that's a decent summary suitable for determining whether
you're in CSM or UEFI, and if in UEFI whether Secure Boot
was used or not.
Paul
On 06/03/2026 16:26, J. P. Gilliver wrote:
Is there a way to tell from a running W10 setup (i. e. without having to
do a reboot and watch for things flashing by) whether you have UEFI or
legacy boot? (And, if UEFI, whether you have "Secure Boot enabled"
[thanks VLH]?)
[]
On Windows (10 / 11)
The quickest and most reliable ways:
Using System Information (easiest, no commands needed):
Press Win + R ? type msinfo32 ? press Enter.* UEFI ? you are booted in UEFI mode
In the System Summary section, look for the line BIOS Mode:
* Legacy ? you are booted in Legacy / BIOS mode
Look for "Secure Boot State" Line
To access the actual settings, you will need to boot up at the firmware level and make changes in the BIOS. My system has UEFI and the
certificate is fully updated, so I am not going to tamper with it.
According to Microsoft, this cannot be changed without flashing old
firmware from Dell (my current machine), which I am not going to do as
it would be too risky.
On 2026/3/6 20:29:39, Paul wrote:
Which suggests I may be susceptible to what this thread is about. Can IWindows Secure Boot is EXPIRING: Do This Before June 2026!
turn it off? (Ideally from within Windows?)
On 2026/3/6 20:29:39, Paul wrote:
On Fri, 3/6/2026 11:26 AM, J. P. Gilliver wrote:
On 2026/3/6 4:27:10, Paul wrote:
On Thu, 3/5/2026 10:15 PM, Alan K. wrote:[]
On 3/5/26 7:01 PM, Paul wrote:
On Thu, 3/5/2026 6:24 PM, Alan K. wrote:
On 3/5/26 6:30 PM, Jack wrote:
Windows Secure Boot is EXPIRING: Do This Before June 2026!
Is there a way to tell from a running W10 setup (i. e. without having to >>> do a reboot and watch for things flashing by) whether you have UEFI orThis only applies to UEFI boot. On Windows 10 this was not necessary but
for Windows 11 this is now mandatory. Whether Microsoft updates this >>>
legacy boot? (And, if UEFI, whether you have "Secure Boot enabled"
[thanks VLH]?)
[]
If you go to Settings and enter TPM, the
I get
Device security
Security processor
Security processor troubleshooting
Device Security on mine says:
"Security Processor"
...
standard hardware security not supported
If I select the middle one I get details of it, suggesting I do have
one, and it's AMD. I don't see the words standard or hardware on that
screen, though under Status, I see Attestation Not supported.
When I found those in mine (they're not adjacent lines), they're
Which means, roughly, that it is not enabled at BIOS level
and used for the current boot. (The Security Processor is
operating, but the BIOS is not switched to a state where
it wants to measure anything, like measure a boot process.)
The other entry in a Settings Search is "Security Processor"
and it says
Attestation Ready
Storage Ready
and above that it indicates the TPM type and version. And that
is indicating, that if I did enable Secure Boot at BIOS level, it
should work.
The fact a TPM is detected and it is listed as an Infineon device
(one of the manufacturers of such), that indicates there is a
secure enclave for any TPM based measuring and recording to be done.
But if the BIOS does not contain code for operating the TPM
for the Secure Boot feature, that is a "lack of Attestation".
For example, on the Optiplex 780, there is a TPM present, but
there is no BIOS code to use it. On the Test Machine, there is
no TPM present and there *is* BIOS code to use it. And these
non-comformances prevent Secure Boot from happening.
If I do Start : Run : msinfo32, then look at System Summary
(there is at least one other MSFT utility to display this), it says:
BIOS Mode UEFI
Secure Boot State Off
and that's a decent summary suitable for determining whether
you're in CSM or UEFI, and if in UEFI whether Secure Boot
was used or not.
Paul
BIOS Mode UEFI
Secure Boot State On
Which suggests I may be susceptible to what this thread is about. Can I
turn it off? (Ideally from within Windows?)
On 3/7/2026 3:49 PM, J. P. Gilliver wrote:
On 2026/3/6 20:29:39, Paul wrote:
Which suggests I may be susceptible to what this thread is about. Can IWindows Secure Boot is EXPIRING: Do This Before June 2026!
turn it off? (Ideally from within Windows?)
No need to switch Secure boot off now. You can do it when
Windows doesn't boot because of a missing valid certificate
(happened for me a few years ago). But what you should do
now is: if your system disk is encrypted, make sure you have
access to the Bitlocker key, because when you switch off
Secure Boot, Windows will boot only if you enter the
Bitlocker key. In my case it was saved in a Microsoft account,
but the phone number for that account was no longer valid
so I had to wait 4 weeks to access the account without a
SMS verification. This means, 4 weeks no access to the laptop!
On 2026/3/7 16:55:51, Herbert Kleebauer wrote:
On 3/7/2026 3:49 PM, J. P. Gilliver wrote:
On 2026/3/6 20:29:39, Paul wrote:
Which suggests I may be susceptible to what this thread is about. Can IWindows Secure Boot is EXPIRING: Do This Before June 2026!
turn it off? (Ideally from within Windows?)
No need to switch Secure boot off now. You can do it when
Windows doesn't boot because of a missing valid certificate
(happened for me a few years ago). But what you should do
I have C: (and hidden partitions) images - does that help?
now is: if your system disk is encrypted, make sure you have
I've no idea whether it is or not.
access to the Bitlocker key, because when you switch off
I have no idea how to get that.
Secure Boot, Windows will boot only if you enter the
Bitlocker key. In my case it was saved in a Microsoft account,
AFAIK I have no such account.
but the phone number for that account was no longer validThis is getting very wearing.
so I had to wait 4 weeks to access the account without a
SMS verification. This means, 4 weeks no access to the laptop!
On Sat, 3/7/2026 2:24 PM, J. P. Gilliver wrote:[]
This is getting very wearing.
manage-bde -status # as administrator, indicates encryption
Paul
On 2026/3/7 22:18:23, Paul wrote:
On Sat, 3/7/2026 2:24 PM, J. P. Gilliver wrote:[]
That (done in an administrator prompt) told me (between ===s):This is getting very wearing.
manage-bde -status # as administrator, indicates encryption
Paul
===
Disk volumes that can be protected with
BitLocker Drive Encryption:
Volume C: []
[OS Volume]
Size: 75.00 GB
BitLocker Version: None
Conversion Status: Fully Decrypted
Percentage Encrypted: 0.0%
Encryption Method: None
Protection Status: Protection Off
Lock Status: Unlocked
Identification Field: None
Key Protectors: None Found
Volume D: [data]
[Data Volume]
Size: 371.48 GB
BitLocker Version: None
Conversion Status: Fully Decrypted
Percentage Encrypted: 0.0%
Encryption Method: None
Protection Status: Protection Off
Lock Status: Unlocked
Identification Field: None
Automatic Unlock: Disabled
Key Protectors: None Found
===
Do I need to worry - about _anything_ in this thread? The above _looks_
to me as if I'm not using BitLocker. Am I still in danger from this
Secure Boot Certificate thing, or anything else that's been mentioned?
But if the BIOS does not contain code for operating the TPM
for the Secure Boot feature, that is a "lack of Attestation".
For example, on the Optiplex 780, there is a TPM present, but
there is no BIOS code to use it.
If I do Start : Run : msinfo32, then look at System Summary
(there is at least one other MSFT utility to display this), it says:
BIOS Mode UEFI
Secure Boot State Off
On 2026/3/7 16:55:51, Herbert Kleebauer wrote:
now is: if your system disk is encrypted, make sure you have
access to the Bitlocker key, because when you switch off
I have no idea how to get that.
https://support.microsoft.com/en-us/windows/find-your-bitlocker-recovery-key-6b71ad27-0b89-ea08-f143-056f5ab347d6
On Fri, 6 Mar 2026 15:29:39 -0500, Paul wrote:
But if the BIOS does not contain code for operating the TPM
for the Secure Boot feature, that is a "lack of Attestation".
For example, on the Optiplex 780, there is a TPM present, but
there is no BIOS code to use it.
My Windows 10 Optiplex desktop shows:
Status
Attestation not-ready
Storage not-ready
If I do Start : Run : msinfo32, then look at System Summary
(there is at least one other MSFT utility to display this), it says:
BIOS Mode UEFI
Secure Boot State Off
Same here. The computer's about 7 years old (refurbished after it
came off a corporate lease), so I suspect it simply doesn't have TPM
or Secure Boot.
On Sat, 3/7/2026 5:48 PM, J. P. Gilliver wrote:[]
[]That (done in an administrator prompt) told me (between ===s):
Do I need to worry - about _anything_ in this thread? The above _looks_
to me as if I'm not using BitLocker. Am I still in danger from this
Secure Boot Certificate thing, or anything else that's been mentioned?
That tells you, since there is no evidence of Microsoft encryption,
then there would not be any blowback from resetting the TPM or so.
You would not need a recovery key, to access your own disk.
It means "one fewer complication", it's not some sort of
complete solution to every problem.
One of the installs I did here (perhaps 25H2 on the Test Machine),
[]
So - _am_ I going to have to do anything about what this thread is about?
On 2026/3/7 22:18:23, Paul wrote:
On Sat, 3/7/2026 2:24 PM, J. P. Gilliver wrote:[]
That (done in an administrator prompt) told me (between ===s):This is getting very wearing.
manage-bde -status # as administrator, indicates encryption
Paul
===
Disk volumes that can be protected with
BitLocker Drive Encryption:
Volume C: []
[OS Volume]
Encryption Method: None
Volume D: [data]
[Data Volume
Encryption Method: None
===
Do I need to worry - about _anything_ in this thread? The above _looks_
to me as if I'm not using BitLocker. Am I still in danger from this
Secure Boot Certificate thing, or anything else that's been mentioned?
On Sun, 3/8/2026 3:13 AM, J. P. Gilliver wrote:
[]
So - _am_ I going to have to do anything about what this thread is about?
That "depends on the future".
I cannot see Secure Boot becoming mandatory. The disk will
still have to boot somehow, if moved to a machine with
no Secure Boot capability. For W11, you have to think about
what 26H2 may bring.
For Win10, your concern is your Secure Boot status right now.
If Secure Boot is turned off, then I don't see the OS dropping
like a rock in mid-year.
So you at least want to check your Secure Boot status.
If it's enabled, then you could do the PCA 2023 thing.
On Sun, 3/8/2026 3:13 AM, J. P. Gilliver wrote:
[]
So - _am_ I going to have to do anything about what this thread is about?
That "depends on the future".
I cannot see Secure Boot becoming mandatory. The disk will
still have to boot somehow, if moved to a machine with
no Secure Boot capability.
For W11, you have to think about> what 26H2 may bring.
For Win10, your concern is your Secure Boot status right now.
If Secure Boot is turned off, then I don't see the OS dropping
like a rock in mid-year.
But it is still a good idea to maintain a computer,
because you as the operator, don't want to be put
between a rock and a hard place at some later date.
It's not a good example, but take the behavior of
Gentoo as an example. If you "do maintenance every day",
the changes are tiny. If you put the machine away for
six months, and try to do maintenance, suddenly you have
two incompatible things that need repair at the same
time and "things jam up". You have to be Kreskin at
that point, to figure it out and fix it (apply a
bias to the package manager, if you're lucky). When you
know these things about computers, it's just a good
idea to "maintain the machine posture", in case
lord knows what happens :-)
Even though I don't expect trouble, I still do my
BIOS flashups that are labeled "Security Fix". Because
I don't know what future exploits could happen.
So you at least want to check your Secure Boot status.
If it's enabled, then you could do the PCA 2023 thing.
Paul
You/Winston/anybody correct me if I'm wrong, but if John does not
want/need Secure Boot he can do one of two things: 1) Go into his BIOS
and turn off Secure Boot now (and check that it's off with the 'System
Information' (msinfo32) utility or 2) do nothing and just wait-and-see
if the system fails to boot in/after June 2026 and if so, do 1).
[...]
So you at least want to check your Secure Boot status.
If it's enabled, then you could do the PCA 2023 thing.
AFAIR, John already mentioned that Secure Boot *is* enabled on his
system.
On Fri, 3/6/2026 11:26 AM, J. P. Gilliver wrote:
On 2026/3/6 4:27:10, Paul wrote:
On Thu, 3/5/2026 10:15 PM, Alan K. wrote:[]
On 3/5/26 7:01 PM, Paul wrote:
On Thu, 3/5/2026 6:24 PM, Alan K. wrote:
On 3/5/26 6:30 PM, Jack wrote:
Windows Secure Boot is EXPIRING: Do This Before June 2026!
This only applies to UEFI boot. On Windows 10 this was not necessary but
for Windows 11 this is now mandatory. Whether Microsoft updates this
Is there a way to tell from a running W10 setup (i. e. without having to
do a reboot and watch for things flashing by) whether you have UEFI or
legacy boot? (And, if UEFI, whether you have "Secure Boot enabled"
[thanks VLH]?)
[]
If you go to Settings and enter TPM, the
Device Security on mine says:
"Security Processor"
...
standard hardware security not supported
Which means, roughly, that it is not enabled at BIOS level
and used for the current boot. (The Security Processor is
operating, but the BIOS is not switched to a state where
it wants to measure anything, like measure a boot process.)
The other entry in a Settings Search is "Security Processor"
and it says
Attestation Ready
Storage Ready
and above that it indicates the TPM type and version. And that
is indicating, that if I did enable Secure Boot at BIOS level, it
should work.
The fact a TPM is detected and it is listed as an Infineon device
(one of the manufacturers of such), that indicates there is a
secure enclave for any TPM based measuring and recording to be done.
But if the BIOS does not contain code for operating the TPM
for the Secure Boot feature, that is a "lack of Attestation".
For example, on the Optiplex 780, there is a TPM present, but
there is no BIOS code to use it. On the Test Machine, there is
no TPM present and there *is* BIOS code to use it. And these
non-comformances prevent Secure Boot from happening.
If I do Start : Run : msinfo32, then look at System Summary
(there is at least one other MSFT utility to display this), it says:
BIOS Mode UEFI
Secure Boot State Off
and that's a decent summary suitable for determining whether
you're in CSM or UEFI, and if in UEFI whether Secure Boot
was used or not.
Paul
I seem to have
BIOS Mode UEFI
Secure Boot State On
Is the "PCA 2023 thing" what w¤?ñ?¤ says is in his "March 6th post"? I
can't find a w¤?ñ?¤ post in this thread dated (allowing for timezones)
5, 6, or 7.
in your admin logged-on Windows profile, click on the Start button, click on the Power button(lower right), click Restart. Once Windows restarts to the Lock screen, do not sign on. Click on the Power button, and click Restart again.Then, and only then log on to Windows in the same admin account.
Open Powershell in an admin prompt, then separately run each of these
two commands.
Secure Boot Certs ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
- If the first command returns ?true,? then your PC is using the new certificate
- If this second command returns ?true,? your system is running an
updated BIOS with the new Secure Boot certificates built in.
..w¤?ñ?¤ <winstonmvp@gmail.com> wrote:
[...]
Open Powershell in an admin prompt, then separately run each of these
two commands.
Secure Boot Certs
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
-match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI
dbdefault).bytes) -match 'Windows UEFI CA 2023')
- If the first command returns ?true,? then your PC is using the new
certificate
- If this second command returns ?true,? your system is running an
updated BIOS with the new Secure Boot certificates built in.
On my HP Windows 11 laptop with the (March) 'Secure Boot Allowed Key Exchange Key (KEK) Update', both commands return 'True', while AFAIK,
the only (Windows Update supplied) BIOS update was done on Sept 19, 2023
and according to HP documentation, the Secure Boot Certificate BIOS
update for the age of my laptop (Nov 2022) should have come out around September 30 or December 31.
'HP PCs - Prepare for new Windows Secure Boot certificates' <https://support.hp.com/us-en/document/ish_13070353-13070429-16>
So how can a BIOS which was updated on Sept 19, 2023 include
certificate fixes which were not released until late 2025?
Sadly the information on what is fixed in which BIOS version for a
given model is missing in the documentation on HP's support site. It
only says something meaningless like 'security fix'.
For my laptop, the HP support site lists sp167316.exe (8.6 MB, of Dec
12, 2025) for BIOS Version F.13 Rev.A. But Windows Update hasn't offered
any new BIOS update and the 'HP Support Assistant' program only offers version F.11 (i.e. lower number) of Nov 22, 2024 (i.e. way before end of 2025).
Anyway, as I mentioned in another response, I'll probably just
wait-and-see and if Windows fails to boot in/after June, I'll turn off
Secure Boot in the BIOS (assuming the HP BIOS has such a setting). (N.B. 'System Information' of course says "Secure Boot State On".)
On 2026/3/8 18:25:39, Frank Slootweg wrote:
and turn off Secure Boot now (and check that it's off with the 'System
Does turning it off - assuming it really is as simple as just toggling something in the BIOS (assuming I can get into that) - scramble
anything? (I think I've established I don't have bitlocker on.)
On Sun, 3/8/2026 2:48 PM, J. P. Gilliver wrote:
On 2026/3/8 18:25:39, Frank Slootweg wrote:
and turn off Secure Boot now (and check that it's off with the 'System
Does turning it off - assuming it really is as simple as just toggling
something in the BIOS (assuming I can get into that) - scramble
anything? (I think I've established I don't have bitlocker on.)
When you turn Secure Boot off, it does not scramble anything in
the OS.
With a Linux OS, the boot sequence can be seen as a[]
On Sun, 3/8/2026 2:41 PM, J. P. Gilliver wrote:[]
The post is at the end of the thread.
I'd use HowardKnight, but it's broken and likely for good
(sooner or later it would lose access to part of what it uses).
******* copy of post *******Thanks again for this.
No need to change the registry
[1] If your device is capable and supported for an updated UEFI/BIOS, update the UEFI/BIOS before performing the following.
Force Secure Boot Update
..w¤?ñ?¤ <winstonmvp@gmail.com> wrote:
[...]
Open Powershell in an admin prompt, then separately run each of these
two commands.
Secure Boot Certs
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
-match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI
dbdefault).bytes) -match 'Windows UEFI CA 2023')
- If the first command returns ?true,? then your PC is using the new
certificate
- If this second command returns ?true,? your system is running an
updated BIOS with the new Secure Boot certificates built in.
On my HP Windows 11 laptop with the (March) 'Secure Boot Allowed Key Exchange Key (KEK) Update', both commands return 'True', while AFAIK,
the only (Windows Update supplied) BIOS update was done on Sept 19, 2023
and according to HP documentation, the Secure Boot Certificate BIOS
update for the age of my laptop (Nov 2022) should have come out around September 30 or December 31.
'HP PCs - Prepare for new Windows Secure Boot certificates' <https://support.hp.com/us-en/document/ish_13070353-13070429-16>
So how can a BIOS which was updated on Sept 19, 2023 include
certificate fixes which were not released until late 2025?
Sadly the information on what is fixed in which BIOS version for a
given model is missing in the documentation on HP's support site. It
only says something meaningless like 'security fix'.
For my laptop, the HP support site lists sp167316.exe (8.6 MB, of Dec
12, 2025) for BIOS Version F.13 Rev.A. But Windows Update hasn't offered
any new BIOS update and the 'HP Support Assistant' program only offers version F.11 (i.e. lower number) of Nov 22, 2024 (i.e. way before end of 2025).
Anyway, as I mentioned in another response, I'll probably just wait-and-see and if Windows fails to boot in/after June, I'll turn off
Secure Boot in the BIOS (assuming the HP BIOS has such a setting). (N.B. 'System Information' of course says "Secure Boot State On".)
[...]
On 2026/3/9 4:26:7, Paul wrote:
On Sun, 3/8/2026 2:48 PM, J. P. Gilliver wrote:
On 2026/3/8 18:25:39, Frank Slootweg wrote:
and turn off Secure Boot now (and check that it's off with the 'System
Does turning it off - assuming it really is as simple as just toggling
something in the BIOS (assuming I can get into that) - scramble
anything? (I think I've established I don't have bitlocker on.)
When you turn Secure Boot off, it does not scramble anything in
the OS.
Thanks. I'll try to figure out how to turn it off next time I reboot,
since I can't see what use it is to me, and it sounds like having it on _might_ be problematic at some point.
[]
With a Linux OS, the boot sequence can be seen as a[]
No penguin here - just W10.
(I thought we'd just agreed that was - for me, anyway - better off!)
[rest snipped (but post kept)]
On 2026/3/8 19:0:22, Paul wrote:
On Sun, 3/8/2026 2:41 PM, J. P. Gilliver wrote:[]
The post is at the end of the thread.
Thanks. I think I do remember seeing it; not sure why I've lost it.
Force Secure Boot Update
(I thought we'd just agreed that was - for me, anyway - better off!)
[rest snipped (but post kept)]
On 3/8/2026 12:05 PM, Frank Slootweg wrote:
..w??? <winstonmvp@gmail.com> wrote:
[...]
Open Powershell in an admin prompt, then separately run each of these
two commands.
Secure Boot Certs
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
-match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI
dbdefault).bytes) -match 'Windows UEFI CA 2023')
- If the first command returns ?true,? then your PC is using the new
certificate
- If this second command returns ?true,? your system is running an
updated BIOS with the new Secure Boot certificates built in.
On my HP Windows 11 laptop with the (March) 'Secure Boot Allowed Key Exchange Key (KEK) Update', both commands return 'True', while AFAIK,
the only (Windows Update supplied) BIOS update was done on Sept 19, 2023 and according to HP documentation, the Secure Boot Certificate BIOS
update for the age of my laptop (Nov 2022) should have come out around September 30 or December 31.
'HP PCs - Prepare for new Windows Secure Boot certificates' <https://support.hp.com/us-en/document/ish_13070353-13070429-16>
So how can a BIOS which was updated on Sept 19, 2023 include
certificate fixes which were not released until late 2025?
It won't.
Sadly the information on what is fixed in which BIOS version for a
given model is missing in the documentation on HP's support site. It
only says something meaningless like 'security fix'.
For my laptop, the HP support site lists sp167316.exe (8.6 MB, of Dec 12, 2025) for BIOS Version F.13 Rev.A. But Windows Update hasn't offered any new BIOS update and the 'HP Support Assistant' program only offers version F.11 (i.e. lower number) of Nov 22, 2024 (i.e. way before end of 2025).
Anyway, as I mentioned in another response, I'll probably just wait-and-see and if Windows fails to boot in/after June, I'll turn off Secure Boot in the BIOS (assuming the HP BIOS has such a setting). (N.B. 'System Information' of course says "Secure Boot State On".)
[...]
Look in System Information for BIOS Version/Date
What version and date value is reported for your device?"BIOS Version/Date AMI F.07, 04/07/2023"
Fyi:
Key Fixes and Enhancements in F.13:
Security Updates: Addresses security vulnerabilities (often referencing CVE-2023-39368, CVE-2023-38575, and CVE-2023-28746).
Charging Fix: Fixes an issue where the unit would not charge during sleep/hibernate/shutdown states when using a 15W USB Type-C adapter.
Battery Management: Adds a pop-up message recommending the use of
genuine HP-branded batteries.
Functionality: Addresses potential loss of Clickpad functionality during sudden shutdowns.
Error Reporting: Improves error messages for Fan 1 and Fan 2 to provide
more specific, actionable information.
System Stability: Updates Intel RC for compatibility enhancements
Vulnerability
CVE-2023-39368 - Intel Bus Lock Regulator Denial of Service
CVE-2023-38575 - Intel Information disclosure
CVE-2023-28746 - Intel Information exposure(Atom CPU)
- None of these were specific to certificates for Secure Boot
On Mon, 3/9/2026 12:07 PM, J. P. Gilliver wrote:[]
On 2026/3/9 4:26:7, Paul wrote:
With a Linux OS, the boot sequence can be seen as a[]
No penguin here - just W10.
The point of mentioning Linux, is to show that the OS boot
procedure collects information about "how the boot went".
In Windows, this could be recorded as an Event in eventvwr.msc .
The Linux happens to show one or two lines in Bold Text, pointing
out to the observer whether the Secure Boot went well, or it
has indigestion. If the Linux screen puts up a red rectangle with
scare text in the middle, that means the integrity of some
file is suspect and the boot... stopped. I would expect Windows
to have scare text too, on a failure (such as certificate-expired error). Both OSes should have a red-window as a possible result.
*******
Enter the BIOS and somewhere in a menu, like maybe under
Boot, would be a "Secure Boot" line, and that line offers
"Other OS" or "UEFI Secure Boot". There really
should not be a lot of options in that line. In yet
another place, it will allow CSM (legacy BIOS boot) or
UEFI/CSM or UEFIonly as options, for determining the
BIOS flavor. Windows has supported both CSM and UEFI
at times, so if you're working on someones computer,
don't be surprised if the disk is MSDOS partitioned
and the boot is a Legacy BIOS boot that cannot do
Secure Boot under any circumstances.
I have on purpose, done both kinds of installs.
I have even used MBR2GPT and switched an older
OS to GPT, so it can be installed-over-top and
even do Secure Boot on the new OS. It is because
of all these bloody options, I have no hair left.
You get the idea.
When I tell you things like this, it's not to scare
you. I drop hints like this, so you will be able
to classify your own goods when necessary.
So based on the above descriptions, a person who installed
Windows 10 (32 bit) in Legacy mode, they are
doubly-behind-the-8ball when it comes time to
upgrade to Win11 64bit gpt secure-boot UEFI over top.
That's never going to work. For many other combinations,
the situation is not nearly as tense (which is
presumably where you are right now, based on the
hints you are dropping). You've done enough ID stuff
so far, you don't seem to be in any trouble, one way
or another.
If Winstons two commands were to return True,
then there would be nothing at all to worry about.
If you can't manage to get those both True, just use
"Other OS" in the boot, or at least any "not-Secure-Boot"
option. A person with a 2026 laptop, may have
only "Secure" or "Not-Secure" as BIOS options.
(A 2026 laptop may not boot Windows 7. "Other OS"
means to use CSM legacy boot which is Win7/OldLinux.)
On Linux, they don't want us to use CSM boot any more.
They ruin the GRUB setup to try to stop you, and I
just use Boot Repair disc and pave over the idiots. For
as long as that works of course. And I have to do that...
for test reasons, when someone else tries to install
NewLinux on an OldLinux or multiboot disk drive.
It's because the users are so experienced here, that
you get the full spectrum of cases.
Paul--
On 3/9/2026 9:16 AM, J. P. Gilliver wrote:
On 2026/3/8 19:0:22, Paul wrote:
On Sun, 3/8/2026 2:41 PM, J. P. Gilliver wrote:[]
The post is at the end of the thread.
Thanks. I think I do remember seeing it; not sure why I've lost it.
Force Secure Boot Update
(I thought we'd just agreed that was - for me, anyway - better off!)
[rest snipped (but post kept)]
Leave Secure Boot enabled.
Just run the following one at at time in the following order in a
Powershell admin.
- copy each command and paste into Powershell, press the 'Return' key.
Set-ItemProperty -Path
?HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot? -Name
?AvailableUpdates? -Value 0x40
Start-ScheduledTask -TaskName ?\Microsoft\Windows\PI\Secure-Boot-Update?
Restart the device twice, once after performing the above, and again
when Windows finishes the first restart(do not logon to Windows, restart
for the second time)...once the second restart finishes logon to Windows
in an Admin account.
Your done.
Just run the following one at at time in the following order in a
Powershell admin.
- copy each command and paste into Powershell, press the 'Return' key.
Set-ItemProperty -Path
?HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot? -Name
?AvailableUpdates? -Value 0x40
Start-ScheduledTask -TaskName ?\Microsoft\Windows\PI\Secure-Boot-Update?
Restart the device twice, once after performing the above, and again
when Windows finishes the first restart(do not logon to Windows, restart
for the second time)...once the second restart finishes logon to Windows
in an Admin account.
Your done.
On Mon, 3/9/2026 12:16 PM, J. P. Gilliver wrote:See my reply to Winston ...
(I thought we'd just agreed that was - for me, anyway - better off!)
[rest snipped (but post kept)]
You should use the administrator terminal and try winstons two status commands.
Just to see if PCA 2023 has already wandered in there.
I'm seeing them both return True, even though my motherboard
did not have a BlackLotus patch like the other motherboards.Me too.
And my Secure Boot key situation has been changing dynamically
with time (the kind of behavior I hate). At one time,
I was even able to get red scare text in Linux about
Secure Boot, and that seems to have stopped, but I don't
know what exactly fixed it.
I wouldn't panic about remedying this right away,
but a minimum for you to do right now, is to
run the two status commands.
Paul
On 3/8/2026 12:05 PM, Frank Slootweg wrote:
..w¤?ñ?¤ <winstonmvp@gmail.com> wrote:
[...]
Open Powershell in an admin prompt, then separately run each of these
two commands.
Secure Boot Certs
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
-match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI
dbdefault).bytes) -match 'Windows UEFI CA 2023')
- If the first command returns ?true,? then your PC is using the new
certificate
- If this second command returns ?true,? your system is running an
updated BIOS with the new Secure Boot certificates built in.
On my HP Windows 11 laptop with the (March) 'Secure Boot Allowed Key
Exchange Key (KEK) Update', both commands return 'True', while AFAIK,
the only (Windows Update supplied) BIOS update was done on Sept 19, 2023
and according to HP documentation, the Secure Boot Certificate BIOS
update for the age of my laptop (Nov 2022) should have come out around
September 30 or December 31.
'HP PCs - Prepare for new Windows Secure Boot certificates'
<https://support.hp.com/us-en/document/ish_13070353-13070429-16>
So how can a BIOS which was updated on Sept 19, 2023 include
certificate fixes which were not released until late 2025?
It won't.
Sadly the information on what is fixed in which BIOS version for a
given model is missing in the documentation on HP's support site. It
only says something meaningless like 'security fix'.
For my laptop, the HP support site lists sp167316.exe (8.6 MB, of Dec
12, 2025) for BIOS Version F.13 Rev.A. But Windows Update hasn't offered
any new BIOS update and the 'HP Support Assistant' program only offers
version F.11 (i.e. lower number) of Nov 22, 2024 (i.e. way before end of
2025).
Anyway, as I mentioned in another response, I'll probably just
wait-and-see and if Windows fails to boot in/after June, I'll turn off
Secure Boot in the BIOS (assuming the HP BIOS has such a setting). (N.B.
'System Information' of course says "Secure Boot State On".)
[...]
Look in System Information for BIOS Version/Date
What version and date value is reported for your device?
So you at least want to check your Secure Boot status.
If it's enabled, then you could do the PCA 2023 thing.
BIOS Mode UEFI
Secure Boot State On
BIOS Version/Date Phoenix Technologies Ltd. A1ZG0380.X64, 2022-07-06
The boot options screen doesn't seem to have any way to turn Secure
Boot off. Can I do that within Windows?
Delete Signatures
Signatures Information
Enroll Signatures
Anyway, as I mentioned in another response, I'll probably just
wait-and-see and if Windows fails to boot in/after June, I'll turn off
Secure Boot in the BIOS (assuming the HP BIOS has such a setting). (N.B. 'System Information' of course says "Secure Boot State On".)
Not sure how to logon in an Admin account, but if "my done" at that
point, presumably don't need to.
I'm back, after two restarts (though they were full ones, getting into Windows). Not sure what I do next ...
...w¤?ñ?¤ <winstonmvp@gmail.com> wrote:
Set-ItemProperty -Path
?HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot? -Name
?AvailableUpdates? -Value 0x40
For example on my Windows 11 25H2 system they are both already there
and the task has been run and is run every 12 hours. (Minor nit: I think
you mean 0x400 (1024 decimal). That's what mine is set to and what I
have seen mentioned in several web articles.)
On Mon, 9 Mar 2026 16:07:34 +0000, J. P. Gilliver wrote:
On 2026/3/9 4:26:7, Paul wrote:
On Sun, 3/8/2026 2:48 PM, J. P. Gilliver wrote:
On 2026/3/8 18:25:39, Frank Slootweg wrote:
and turn off Secure Boot now (and check that it's off with the
'System
Does turning it off - assuming it really is as simple as just toggling >>>> something in the BIOS (assuming I can get into that) - scramble
anything? (I think I've established I don't have bitlocker on.)
When you turn Secure Boot off, it does not scramble anything in the OS.
Thanks. I'll try to figure out how to turn it off next time I reboot,
since I can't see what use it is to me, and it sounds like having it on
_might_ be problematic at some point.
I'm fond of penguins so I turn it off and leave it off. It might have some utility for Windows but I don't know what. Zero use with Linux except for complicating life.
You probably don't want to turn off Fast Boot on a Windows machine.
On 2026/3/8 19:0:22, Paul wrote:
I'd use HowardKnight, but it's broken and likely for good
(sooner or later it would lose access to part of what it uses).
Sad, but inevitable, I think. (Maybe the MID enhancement to Thunderbird
will come along soon.)
On Mon, 9 Mar 2026 14:44:59 -0700, Stan Brown wrote:
The boot options screen doesn't seem to have any way to turn Secure
Boot off. Can I do that within Windows?
I was mistaken. I restarted the laptop and went into the BIOS boot
options again, this time checking the sub-menus. I found "Secure Boot Configuration" under Security. There are three settings within it:
* Secure Boot Option [Enabled]; can be changed to Disabled
* Install Default Secure Boot Keys [Enter] -- I'm nervous about
testing that without knowing what it will do
* Delete All Signatures [Enter] -- seems like a bad idea
There are also three sub-sub-menus:
Delete Signatures
Signatures Information
Enroll Signatures
Correct me if I'm wrong, but the _least_ likely source of trouble
seems to me to be changing Secure Boot Option to Disabled.
On 2026/3/9 17:26:21, ...w¤?ñ?¤ wrote:
On 3/8/2026 12:05 PM, Frank Slootweg wrote:
..w¤?ñ?¤ <winstonmvp@gmail.com> wrote:
[...]
Open Powershell in an admin prompt, then separately run each of these
two commands.
Secure Boot Certs
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) >>>> -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI
dbdefault).bytes) -match 'Windows UEFI CA 2023')
- If the first command returns ?true,? then your PC is using the new >>>> certificate
- If this second command returns ?true,? your system is running an
updated BIOS with the new Secure Boot certificates built in.
Here's what I got (entire session, between ===== lines):
=====
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Try the new cross-platform PowerShell https://aka.ms/pscore6
PS C:\Windows\system32> Secure Boot Certs ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
Secure : The term 'Secure' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that
the path is correct and try again.
At line:1 char:1
+ Secure Boot Certs ([System.Text.Encoding]::ASCII.GetString((Get-Secur ...
+ ~~~~~~
+ CategoryInfo : ObjectNotFound: (Secure:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
PS C:\Windows\system32> ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
False
PS C:\Windows\system32>
=====
I'm fond of penguins so I turn it off and leave it off. It might have some utility for Windows but I don't know what. Zero use with Linux except for complicating life.
You probably don't want to turn off Fast Boot on a Windows machine.
I'm fond of penguins so I turn it off and leave it off. It might have some utility for Windows but I don't know what. Zero use with Linux except for complicating life.
You probably don't want to turn off Fast Boot on a Windows machine.
On 3/9/2026 12:39 PM, J. P. Gilliver wrote:
Not sure how to logon in an Admin account, but if "my done" at that
point, presumably don't need to.
You should know which logon accounts on your device(s) are logon
accounts as an Administrator(i.e. an Admin account)
I'm back, after two restarts (though they were full ones, getting into
Windows). Not sure what I do next ...
Now, in a Powershell admin window copy and paste the following and press
the 'Enter' key. The response will indicate True or False.
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
Report the response in a reply.
On Mon, 9 Mar 2026 16:16:44 +0000, "J. P. Gilliver" <G6JPG@255soft.uk>
wrote:
On 2026/3/8 19:0:22, Paul wrote:
I'd use HowardKnight, but it's broken and likely for good
(sooner or later it would lose access to part of what it uses).
Sad, but inevitable, I think. (Maybe the MID enhancement to Thunderbird
will come along soon.)
Not that it's actually needed, though, since MID functionality already
exists via extensions.
On Mon, 3/9/2026 4:11 PM, J. P. Gilliver wrote:
On 2026/3/9 17:26:21, ...w¤?ñ?¤ wrote:
On 3/8/2026 12:05 PM, Frank Slootweg wrote:
..w¤?ñ?¤ <winstonmvp@gmail.com> wrote:
[...]
Open Powershell in an admin prompt, then separately run each of these >>>>> two commands.
Secure Boot Certs
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) >>>>> -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI
dbdefault).bytes) -match 'Windows UEFI CA 2023')
- If the first command returns ?true,? then your PC is using the new >>>>> certificate
- If this second command returns ?true,? your system is running an >>>>> updated BIOS with the new Secure Boot certificates built in.
Here's what I got (entire session, between ===== lines):
=====
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Try the new cross-platform PowerShell https://aka.ms/pscore6
PS C:\Windows\system32> Secure Boot Certs
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
-match 'Windows UEFI CA 2023')
Secure : The term 'Secure' is not recognized as the name of a cmdlet,
function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that
the path is correct and try again.
At line:1 char:1
+ Secure Boot Certs ([System.Text.Encoding]::ASCII.GetString((Get-Secur ... >> + ~~~~~~
+ CategoryInfo : ObjectNotFound: (Secure:String) [],
CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
PS C:\Windows\system32>
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI
dbdefault).bytes) -match 'Windows UEFI CA 2023')
False
PS C:\Windows\system32>
=====
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
On 2026/3/10 0:11:23, rbowman wrote:
[Secure Boot]
I'm fond of penguins so I turn it off and leave it off. It might have some >> utility for Windows but I don't know what. Zero use with Linux except for >> complicating life.
I haven't touched it yet.
You probably don't want to turn off Fast Boot on a Windows machine.
That's the first time _Fast_ Boot has been mentioned in this thread (I think); not sure if I have that or not. I think I have verbose or
something like that, as it tells me what's happening, and I like that -
gives me some idea what's going on (or at least that something is); the
boot time (I have an SSD) isn't irritatingly slow.
On 2026/3/10 1:14:6, ...w¤?ñ?¤ wrote:
On 3/9/2026 12:39 PM, J. P. Gilliver wrote:
Not sure how to logon in an Admin account, but if "my done" at that
point, presumably don't need to.
You should know which logon accounts on your device(s) are logon
accounts as an Administrator(i.e. an Admin account)
I think I have two accounts - my normal one (from which I can "run
[things] as Administrator", but I don't think it is an Admin account),
and an Administrator one, which I created (or enabled - I think it was
there, but hidden) in response to something (IIRR) here. I can't
remember how to get into it - but I could probably find out. (I _think_
I can remember its password.)
On Tue, 3/10/2026 9:39 AM, J. P. Gilliver wrote:[]
That's the first time _Fast_ Boot has been mentioned in this thread (I
think); not sure if I have that or not. I think I have verbose or
something like that, as it tells me what's happening, and I like that -
gives me some idea what's going on (or at least that something is); the
boot time (I have an SSD) isn't irritatingly slow.
There are "two fast things" on your computer.
The "Fast" one in the BIOS, that setting can change the behavior
of the BIOS.
Any time electrical components are changed inside the computer,
it reverts to "slow boot" while it does a slightly better
memtest on the way up. I've had modern computers take
90 seconds to come up, when they are doing their "thorough"
method. The motherboards with the four white "staging LEDs",
none of the LEDs are lit while the guru in there contemplates
its navel. The next time, the BIOS might be 5-8 seconds, because
it knows the hardware content of the box has not changed. We
see this slow startup behavior, on new screwdriver assembly
of computer components. The first boot is a slow one. You
sit with crossed fingers waiting waiting for the staging
LEDs to light up :-) It's like waiting for Christmas.
*******
In Windows, in the Power options, there is a control to enable
things you would not normally enable. If you hibernate just
the kernel of the OS, between sessions (and writing hiberfil.sys
for storage space), that takes a minimum of time at shutdown
(350MB write), and on the way up, the kernel blob is "bulk loaded",
and that saves time on reading in the individual driver files
for all the hardware. That reduces the OS boot component to
5-10 seconds (depending on the prowess of your processor).
The kids with the 6GHz processors, will race their machines
to see "who is the fastest". And the "Fast Startup" OS option helps.
# If you have trouble opening this .webp graphic, Irfanview can open it.
# Using "control.exe" and then Power Options, eventually gives this dialog
https://cdn.mos.cms.futurecdn.net/r5TsgNrpaNUSgzgckzGnEG-888-80.jpg.webp
There is a similarity between OSes, so other versions have something like this.
( https://www.laptopmag.com/how-to/turn-off-fast-startup-on-windows-11 )
Turning off Fast Startup, is for if you are a multibooter. If you only
use the one OS on the laptop, then leaving Fast Startup enabled is fine.
All the kit in the room here, has that turned off, as I refuse to be held hostage by any silliness :-) I only care about boot times if it
takes 3-5 minutes. A TORAM boot of a Linux DVD takes that long...
Use a USB stick instead.
Paul--
control.exe then "User Accounts", then "Manage another account" .
That allows reviewing the "full" accounts on the machine.
Mine has three accounts. The administrator group account (the
one I MUST NOT delete :-) ), plus two unelevated accounts
used as credentials for file sharing sessions.
The real administrator account is not enabled on the machine.
By default, this is OFF and I generally leave it OFF as it
has a slight security aspect to it. With real malware,
I don't think it matters what you do but we can always
pretend these little ceremonies make a difference.
Paul
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
Ah, got it: I hadn't realised that Winston's "Secure Boot Certs" was
just him telling me what the next two lines did - I thought that was
supposed to be part of what I was to enter.
I've just entered the above two lines into an Admin powershell, and the
first one said True, the second False.
(Incidentally, copying them from _your_ post _didn't_ give any embedded
">> " bits, even though they were split.)
[]
So what does one returning True and one returning False tell me/you/us?
Turning off Fast Startup, is for if you are a multibooter. If you only
use the one OS on the laptop, then leaving Fast Startup enabled is fine.
On 2026-03-10 14:23, Paul wrote:
Turning off Fast Startup, is for if you are a multibooter. If you only
use the one OS on the laptop, then leaving Fast Startup enabled is fine.
Also you should disable it if you use imaging software to back up your system disk.
Java Jive <java@evij.com.invalid> wrote:
On 2026-03-10 14:23, Paul wrote:
Turning off Fast Startup, is for if you are a multibooter. If you only
use the one OS on the laptop, then leaving Fast Startup enabled is fine.
Also you should disable it if you use imaging software to back up your
system disk.
Why?
The imaging software - in my case Macrium Reflect Free - just does a sector copy of the partitions. Any changes to the file-systems/
partitions while the image backup is taking place are recorded in a
Volume Shadow Copy.
So I don't see why Fast Startup, which only does it's preparation/ (partial-)hibernation work during Shutdown, has any effect on an image backup.
Or is your concern that the hibernated system copy might be
stale compared to the current OS? If so, 1) when restoring, the Rescue
media will be booted, invalidating the old hibernated system copy and
2) AFAIK, the hiberfil.sys file is not included in the image, so it
can't be restored.
But please educate me/us.
On 2026-03-10 18:47, Frank Slootweg wrote:
Java Jive <java@evij.com.invalid> wrote:
On 2026-03-10 14:23, Paul wrote:
Also you should disable it if you use imaging software to back up your
Turning off Fast Startup, is for if you are a multibooter. If you only >>>> use the one OS on the laptop, then leaving Fast Startup enabled is fine. >>>
system disk.
ÿÿ Why?
ÿÿ The imaging software - in my case Macrium Reflect Free - just does a
sector copy of the partitions. Any changes to the file-systems/
partitions while the image backup is taking place are recorded in a
Volume Shadow Copy.
ÿÿ So I don't see why Fast Startup, which only does it's preparation/
(partial-)hibernation work during Shutdown, has any effect on an image
backup.
ÿÿ Or is your concern that the hibernated system copy might be
stale compared to the current OS? If so, 1) when restoring, the Rescue
media will be booted, invalidating the old hibernated system copy and
2) AFAIK, the hiberfil.sys file is not included in the image, so it
can't be restored.
ÿÿ But please educate me/us.
First, let me clarify things.ÿ From what has been discussed before here &/or in other Windows NGs, Fast Start only hibernates the state of the OS, IIRC at login, whereas user hibernation saves the state of the Desktop and running programs.ÿ The above is a minimum and there may well be other differences, but I'm not aware of them, and particularly not wrt the following problem, which I know happens when an OS is user hibernated.
When an OS is hibernated by the user, the state of play of ALL the Windows readable disks is remembered, not just that of the system disk. If then the PC is booted into a different OS which results in changes to any of the disks readable by Windows, say you copy in a file, when the original Windows OS is reverted to, it will attempt to revert the state of ALL the disks back to their remembered state, and thus any changes made, such as copying in that file, will probably be lost.ÿ At very least a chkdsk is likely to be triggered.
Similarly, if you restore a Windows OS from a backup taken while the OS was hibernated, then when the restored OS boots it will attempt to revert all the disks back to their state when the backup was taken, potentially losing any legitimate changes made in the meantime, even those to a data disk.
So I'm thinking that possibly/probably the same thing may happen when Fast Start is enabled, and thus I cannot recommend using imaging software to back up a Windows OS with Fast Start enabled.
On 2026-03-10 14:23, Paul wrote:
Turning off Fast Startup, is for if you are a multibooter. If you only
use the one OS on the laptop, then leaving Fast Startup enabled is fine.
Also you should disable it if you use imaging software to back up your system disk.
On 2026/3/10 3:20:5, Paul wrote:
On Mon, 3/9/2026 4:11 PM, J. P. Gilliver wrote:
On 2026/3/9 17:26:21, ...w¤?ñ?¤ wrote:
On 3/8/2026 12:05 PM, Frank Slootweg wrote:
..w¤?ñ?¤ <winstonmvp@gmail.com> wrote:
[...]
Open Powershell in an admin prompt, then separately run each of these >>>>>> two commands.
Secure Boot Certs
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) >>>>>> -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI
dbdefault).bytes) -match 'Windows UEFI CA 2023')
- If the first command returns ?true,? then your PC is using the new >>>>>> certificate
- If this second command returns ?true,? your system is running an >>>>>> updated BIOS with the new Secure Boot certificates built in.
Here's what I got (entire session, between ===== lines):
=====
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Try the new cross-platform PowerShell https://aka.ms/pscore6
PS C:\Windows\system32> Secure Boot Certs
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
-match 'Windows UEFI CA 2023')
Secure : The term 'Secure' is not recognized as the name of a cmdlet,
function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that
the path is correct and try again.
At line:1 char:1
+ Secure Boot Certs ([System.Text.Encoding]::ASCII.GetString((Get-Secur ... >>> + ~~~~~~
+ CategoryInfo : ObjectNotFound: (Secure:String) [],
CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
PS C:\Windows\system32>
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI
dbdefault).bytes) -match 'Windows UEFI CA 2023')
False
PS C:\Windows\system32>
=====
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
Ah, got it: I hadn't realised that Winston's "Secure Boot Certs" was
just him telling me what the next two lines did - I thought that was
supposed to be part of what I was to enter.
I've just entered the above two lines into an Admin powershell, and the
first one said True, the second False.
(Incidentally, copying them from _your_ post _didn't_ give any embedded
">> " bits, even though they were split.)
[]
So what does one returning True and one returning False tell me/you/us?
On 3/10/2026 7:18 AM, J. P. Gilliver wrote:[]
On 2026/3/10 3:20:5, Paul wrote:
[]([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
Ah, got it: I hadn't realised that Winston's "Secure Boot Certs" was
just him telling me what the next two lines did - I thought that was
supposed to be part of what I was to enter.
I've just entered the above two lines into an Admin powershell, and the
first one said True, the second False.
So what does one returning True and one returning False tell me/you/us?
It means you're done with updating the device for the current 2023 cert,
and good to go.
The only other option until the Secure Boot 2011 are
revoked/expired/removed is an OEM provided UEFI/BIOS update - which can
be installed if released, if not, your done.
Any future Windows Updates with Secure Boot will be installed via
Windows Update, the scheduled task will continue to run and update the
2023 cert if necessary. After 2011 cert is revoked and 2023 fully implemented the scheduled task can be deleted or ignored.
On Tue, 3/10/2026 3:28 PM, Java Jive wrote:
On 2026-03-10 18:47, Frank Slootweg wrote:
Java Jive <java@evij.com.invalid> wrote:
On 2026-03-10 14:23, Paul wrote:
Also you should disable it if you use imaging software to back up your >>>> system disk.
Turning off Fast Startup, is for if you are a multibooter. If you only >>>>> use the one OS on the laptop, then leaving Fast Startup enabled is fine. >>>>
ÿÿ Why?
ÿÿ The imaging software - in my case Macrium Reflect Free - just does a >>> sector copy of the partitions. Any changes to the file-systems/
partitions while the image backup is taking place are recorded in a
Volume Shadow Copy.
ÿÿ So I don't see why Fast Startup, which only does it's preparation/
(partial-)hibernation work during Shutdown, has any effect on an image
backup.
ÿÿ Or is your concern that the hibernated system copy might be
stale compared to the current OS? If so, 1) when restoring, the Rescue
media will be booted, invalidating the old hibernated system copy and
2) AFAIK, the hiberfil.sys file is not included in the image, so it
can't be restored.
ÿÿ But please educate me/us.
First, let me clarify things.ÿ From what has been discussed before here &/or in other Windows NGs, Fast Start only hibernates the state of the OS, IIRC at login, whereas user hibernation saves the state of the Desktop and running programs.ÿ The above is a minimum and there may well be other differences, but I'm not aware of them, and particularly not wrt the following problem, which I know happens when an OS is user hibernated.
When an OS is hibernated by the user, the state of play of ALL the Windows readable disks is remembered, not just that of the system disk. If then the PC is booted into a different OS which results in changes to any of the disks readable by Windows, say you copy in a file, when the original Windows OS is reverted to, it will attempt to revert the state of ALL the disks back to their remembered state, and thus any changes made, such as copying in that file, will probably be lost.ÿ At very least a chkdsk is likely to be triggered.
Similarly, if you restore a Windows OS from a backup taken while the OS was hibernated, then when the restored OS boots it will attempt to revert all the disks back to their state when the backup was taken, potentially losing any legitimate changes made in the meantime, even those to a data disk.
So I'm thinking that possibly/probably the same thing may happen when Fast Start is enabled, and thus I cannot recommend using imaging software to back up a Windows OS with Fast Start enabled.
Does a Macrium Rescue CD "allow" a backup to run while a hiberfil.sys
has a validated header on it (the OS partition being in a hibernated state) ?
If I run this through CoPilot, I think you can imagine what the answer
is, but I'm not convinced the LLM-AI knows this to be true. It could be
a projection of logical-consequences instead of an observation based
on seeing someone report this.
************** CoPilot Answer *********************
Here?s the clear, technically accurate answer <=== Pinocchio's nose seems longer...
you?re looking for - and the short version is: **No, a Macrium Rescue CD Answer has no cites.
will not allow you to run a proper image backup of a Windows partition that is in a hibernated state (i.e., with a valid hiberfil.sys header).**
---
# **Short Answer**
**Macrium Reflect Rescue Media will *refuse* to image an OS partition that contains a valid hibernation file header**, because that indicates the filesystem
is in an *inconsistent* state. This is by design ? imaging a hibernated Windows volume would produce a corrupted or unbootable image.
---
# **Why This Happens**
When Windows hibernates:
- It writes the entire memory state into **hiberfil.sys**.
- It marks the filesystem as **?dirty / hibernated?** in the NTFS metadata.
- The volume is *not* in a crash-consistent state.
Macrium Reflect (including the Rescue CD environment) checks for this condition.
If it detects a valid hibernation header:
- It **blocks the backup**
- It warns that the volume is in a hibernated state
- It requires you to **disable hibernation or boot Windows normally** before imaging
This is the same behavior you see when trying to mount or image a
hibernated NTFS volume under Linux ? the filesystem is considered unsafe to access.
---
# **Why Macrium Blocks It**
Allowing a backup of a hibernated OS partition would risk:
- Filesystem corruption
- Incomplete or inconsistent system state
- Unbootable restored images
Macrium?s design philosophy is to guarantee *restorable* images, so it refuses to proceed.
---
# **What *Does* Work**
If you want to image the OS partition from Rescue Media:
### Boot into Rescue Media
### Open a command prompt
### Run:
powercfg /h off
```
This deletes **hiberfil.sys** and clears the hibernation flag. <=== sheerest hallucination!
it is booted off X:, not C:
After that, Macrium will allow the backup. If this works, this is my
shocked face.
---
# **Edge Case: Forced Imaging?**
Even if you try to force it (e.g., using forensic sector-by-sector mode), Macrium still checks the NTFS state and will warn or refuse.
Macrium does **not** provide an override to ignore a hibernated filesystem.
---
# **Bottom Line**
**A Macrium Rescue CD will *not* allow a backup of a Windows OS partition
if hiberfil.sys has a valid header.**
You must disable hibernation or boot Windows normally first. <=== this is a more sound advice (including no Fast Startup cycle)
[Please note: This answer had NO reference section with cites at the bottom.]
[This will require test to validate. I can believe the answer that the consistency problem will be picked up by the Rescue CD (because Macrium
devs are very thorough individuals -- hardly ever making stupid mistakes),
if you attempt to pull the old switcheroo. And adjusting your hibernation state before
going offline to make a backup, that's a good answer. But thinking
you can erase C:\hiberfil.sys while booted from X: is just silly. If the LLM-AI told me to "del C:\hiberfil.sys" from the X: prompt, that would make more logical (and dangerous) sense for an AI to cook up. And no, don't
do that either.]
When you back up, it's up to you as a responsible adult, to not be
throwing challenges into the picture that are illogical and just
asking for trouble. Great for an experiment. Bad for a part of your
regular backup cycle. Since my hiberfil.sys is disabled everywhere in
this room, I'm not even ready to test this. Purely by accident,
I'm ready for backup anytime. I didn't plan this.
Macrium can pretend to record the pagefile.sys while the
OS is running on C: , but the contents are all zero. There
is a good chance it is just faking it.
Macrium is not the only imaging software, though it is the one that currently I'm using.ÿ As you may remember, I used to use Ghost until I discovered that it is buggy with GPT disks, and that warns you that the filesystem is in a 'dirty' state, advises you not to proceed, but will
allow you to do so if you choose.
On 2026/3/11 1:41:24, ...w¤?ñ?¤ wrote:
On 3/10/2026 7:18 AM, J. P. Gilliver wrote:[]
On 2026/3/10 3:20:5, Paul wrote:
[]([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
Ah, got it: I hadn't realised that Winston's "Secure Boot Certs" was
just him telling me what the next two lines did - I thought that was
supposed to be part of what I was to enter.
I've just entered the above two lines into an Admin powershell, and the
first one said True, the second False.
So what does one returning True and one returning False tell me/you/us?
It means you're done with updating the device for the current 2023 cert,
and good to go.
Thanks! That sounds reassuring.
The only other option until the Secure Boot 2011 are
revoked/expired/removed is an OEM provided UEFI/BIOS update - which can
be installed if released, if not, your done.
Given
BIOS Version/Date LENOVO 1LCN50WW, 2017/4/17
, I don't think that's likely. (Almost certainly pre Windows 10?)
Any future Windows Updates with Secure Boot will be installed viaI guess I'll find out in June! (Or am O safe from that one?)
Windows Update, the scheduled task will continue to run and update the
2023 cert if necessary. After 2011 cert is revoked and 2023 fully
implemented the scheduled task can be deleted or ignored.
On 3/11/2026 6:29 AM, Java Jive wrote:
Macrium is not the only imaging software, though it is the one that
currently I'm using.ÿ As you may remember, I used to use Ghost until I
discovered that it is buggy with GPT disks, and that warns you that
the filesystem is in a 'dirty' state, advises you not to proceed, but
will allow you to do so if you choose.
Hardly a fair comparison(Ghost vs. Macrium). Most today would be using
the last released free version of Macrium or its current subscription released version.
Ghost last released version compatible for a Windows operating system
was over 16 years ago(Nov. 2009) - Windows 7 and earlier. Never designed
for use on Win8x and later, nor with UEFI and GPT.
For non-enterprise consumer Windows 8x and later Symantec's product was System Recovery(for Win10 version SSR version 11.1.3, aka 2013 SP4), Enterprise was Ghost Solution Suite version 3.3 later.
ÿ- Symantec consumer division Veritas was sold to Carlisle Group in
2016 with SSR rebranded as Veritas System Recovery(initial release
version 16 for Win10 compatibility).
On 3/11/2026 5:47 AM, J. P. Gilliver wrote:
On 2026/3/11 1:41:24, ...w¤?ñ?¤ wrote:
On 3/10/2026 7:18 AM, J. P. Gilliver wrote:[]
On 2026/3/10 3:20:5, Paul wrote:
[]([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
Ah, got it: I hadn't realised that Winston's "Secure Boot Certs" was
just him telling me what the next two lines did - I thought that was
supposed to be part of what I was to enter.
I've just entered the above two lines into an Admin powershell, and the >>>> first one said True, the second False.
So what does one returning True and one returning False tell me/you/us? >>>It means you're done with updating the device for the current 2023 cert, >>> ÿÿ and good to go.
Thanks! That sounds reassuring.
The only other option until the Secure Boot 2011 are
revoked/expired/removed is an OEM provided UEFI/BIOS update - which can
be installed if released, if not, your done.
Given
ÿÿÿÿBIOS Version/Dateÿÿÿ LENOVO 1LCN50WW, 2017/4/17
, I don't think that's likely. (Almost certainly pre Windows 10?)
ÿÿ Any future Windows Updates with Secure Boot will be installed viaI guess I'll find out in June! (Or am O safe from that one?)
Windows Update, the scheduled task will continue to run and update the
2023 cert if necessary.ÿ After 2011 cert is revoked and 2023 fully
implemented the scheduled task can be deleted or ignored.
As noted, you're good to go(based on your earlier reply that the Powershell command indicated 2023 cert is present in the db store.
Discussion here and elsewhere regarding Secure Boot has been going on for quite some time.
Some of the articles are missing the point and spreading fear beyond what will/does happen.
On 3/11/2026 5:47 AM, J. P. Gilliver wrote:
On 2026/3/11 1:41:24, ...w¤?ñ?¤ wrote:
On 3/10/2026 7:18 AM, J. P. Gilliver wrote:[]
On 2026/3/10 3:20:5, Paul wrote:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
Given
BIOS Version/Date LENOVO 1LCN50WW, 2017/4/17
, I don't think that's likely. (Almost certainly pre Windows 10?)
Any future Windows Updates with Secure Boot will be installed viaI guess I'll find out in June! (Or am O safe from that one?)
Windows Update, the scheduled task will continue to run and update the
2023 cert if necessary. After 2011 cert is revoked and 2023 fully
implemented the scheduled task can be deleted or ignored.
As noted, you're good to go(based on your earlier reply that the
Powershell command indicated 2023 cert is present in the db store.
Discussion here and elsewhere regarding Secure Boot has been going on
for quite some time.
Some of the articles are missing the point and spreading fear beyond
what will/does happen.
For Win10 and Secure Boot with the 2023 cert deployed(like yours True
for Windows, False for UEFI), the device and its Win10 OS(24H2) should
be enrolled in ESU to ensure any future Secure Boot updates are
available, downloaded and installed.
On 2026-03-11 17:53, ...w¤?ñ?¤ wrote:
On 3/11/2026 6:29 AM, Java Jive wrote:
Macrium is not the only imaging software, though it is the one that
currently I'm using.ÿ As you may remember, I used to use Ghost until
I discovered that it is buggy with GPT disks, and that warns you that
the filesystem is in a 'dirty' state, advises you not to proceed, but
will allow you to do so if you choose.
Hardly a fair comparison(Ghost vs. Macrium). Most today would be using
the last released free version of Macrium or its current subscription
released version.
Ghost last released version compatible for a Windows operating system
was over 16 years ago(Nov. 2009) - Windows 7 and earlier. Never
designed for use on Win8x and later, nor with UEFI and GPT.
For non-enterprise consumer Windows 8x and later Symantec's product
was System Recovery(for Win10 version SSR version 11.1.3, aka 2013
SP4), Enterprise was Ghost Solution Suite version 3.3 later.
ÿÿ- Symantec consumer division Veritas was sold to Carlisle Group in
2016 with SSR rebranded as Veritas System Recovery(initial release
version 16 for Win10 compatibility).
I just used Ghost for as long as it worked for me, because I had rescue media which automated a lot of the process of backing up and restoring,
and stopped using it when I found it was buggy and gave problems on GPT disks.
Anyway, I don't think you've altered my point, which was that there are different imaging programs which might behave differently under unusual situations, such as the 'dirty' flag being set.
On Tue, 3/10/2026 2:06 PM, Java Jive wrote:
On 2026-03-10 14:23, Paul wrote:
Turning off Fast Startup, is for if you are a multibooter. If you only
use the one OS on the laptop, then leaving Fast Startup enabled is fine.
Also you should disable it if you use imaging software to back up
your system disk.
You can back up the system hot. Not a problem.
(That's why it uses VSS, the Volume Shadow Service, it
freezes a "snapshot" of the OS files, and anything saved
after the ten second quiesce phase, will be backed up
on your *next* backup.)
Backing up from a Rescue CD, the X: OS partition there does not
have VSS, but the C: filesystem is at rest and so it is
easier to back up (compared to backing up hot).
Macrium can pretend to record the pagefile.sys while the
OS is running on C: , but the contents are all zero. There
is a good chance it is just faking it.
It would be nice if some utilities would agree as to what
files are on various representations of a partition like C:
(and the C: backup), but this hardly happens. There are
too many little differences to get an exact match out of anything.
Whereas a data partition like D: , it is more likely to have utilities
that see the same things on there.
On 2026-03-10 23:25, Paul wrote:
Macrium can pretend to record the pagefile.sys while the
OS is running on C: , but the contents are all zero. There
is a good chance it is just faking it.
Which is the sort of reason why I think the whole idea of imaging a
running system is dodgy, and always shut a system down before imaging it.
IIRC, another is that there are keys in the registry which flag whether
a system was shut down properly. If you restore the image of a running system, on first boot it will find that these flags are not in their
proper state, and a menu will be displayed asking for which version of Windows to load, even if there's only one, or whether to load safe mode, etc.
This might not matter much to a home user, but, speaking as a
former professional who used to create the OS images for thousands of corporate PCs, I'm pretty sure that I wouldn't have been allowed to
produce an image that did that, even supposing I had been sufficiently unembarrassed to try!
Java Jive <java@evij.com.invalid> wrote:
IIRC, another is that there are keys in the registry which flag whether
a system was shut down properly. If you restore the image of a running
system, on first boot it will find that these flags are not in their
proper state, and a menu will be displayed asking for which version of
Windows to load, even if there's only one, or whether to load safe mode,
etc.
I think it's extremely unlikely that this is actually a problem,
because if it was, Macrium Reflect would not offer online image backup
(of system partitions) or would at least warn for the consequences and
what precautions/ measures to take when restoring.
--This might not matter much to a home user, but, speaking as a
former professional who used to create the OS images for thousands of
corporate PCs, I'm pretty sure that I wouldn't have been allowed to
produce an image that did that, even supposing I had been sufficiently
unembarrassed to try!
On 12/03/2026 15:41, Frank Slootweg wrote:
Java Jive <java@evij.com.invalid> wrote:
IIRC, another is that there are keys in the registry which flag whether
a system was shut down properly.ÿ If you restore the image of a running
system, on first boot it will find that these flags are not in their
proper state, and a menu will be displayed asking for which version of
Windows to load, even if there's only one, or whether to load safe mode, >>> etc.
ÿÿ I think it's extremely unlikely that this is actually a problem,
because if it was, Macrium Reflect would not offer online image backup
(of system partitions) or would at least warn for the consequences and
what precautions/ measures to take when restoring.
No, agreed, not an actual problem as such, it's just the result seems somewhat unprofessional.ÿ Fine for home use, but perhaps not good for your professional reputation at work :-), which is why I added ...
ÿÿÿÿThis might not matter much to a home user, but, speaking as a
former professional who used to create the OS images for thousands of
corporate PCs, I'm pretty sure that I wouldn't have been allowed to
produce an image that did that, even supposing I had been sufficiently
unembarrassed to try!
On Wed, 3/11/2026 2:08 PM, ...w¤?ñ?¤ wrote:
Some of the articles are missing the point and spreading fear beyond what will/does happen.
The fear is justified, given how stupid some of the motherboard
engineering can be. One company lost the curation chain for their
BIOS releases. In some cases, the only reason this stuff works,
is because the BIOS in an Award, AMI, Phoenix, InSyde and those
companies push out the code for that.
It is the lack of industry expertise in UEFI and Secure Boot that
strikes fear for the unlucky computer owners.
It would help greatly, if we had a tool to properly list the certs
and revokes.
Paul
That's why I said Macrium Reflect probably doesn't even backup (the sectors containing) the hiberfil.sys file, because there's just no
point. I/we could try to chase this down in the Macrium knowledge base
etc. or/and check the contect of an image I/we made, but I won't try
such an exercise in futility.
Frank Slootweg wrote on 3/12/2026 8:26 AM:
ÿÿ That's why I said Macrium Reflect probably doesn't even backup (the
sectors containing) the hiberfil.sys file, because there's just no
point. I/we could try to chase this down in the Macrium knowledge base
etc. or/and check the contect of an image I/we made, but I won't try
such an exercise in futility.
cf.
<https://knowledgebase.macrium.com/display/KNOWX/Backup+Defaults>
Intelligent Sector Copyÿÿÿ
Only backup data blocks that are being used by files on the disk. This significantly reduces the time it takes for backups to complete and reduces the size of the backup files.
***The data blocks in Pagefile (pagefile.sys) and hibernation (hiberfil.sys) files will be excluded from images.***
Data blocks in these files are temporary and not required when Windows starts.ÿ These files will be visible in the imaged file system, but will take up zero space in the image file.
Paul wrote on 3/11/2026 1:11 PM:
On Wed, 3/11/2026 2:08 PM, ...w¤?ñ?¤ wrote:
Some of the articles are missing the point and spreading fear beyond what will/does happen.
The fear is justified, given how stupid some of the motherboard
engineering can be. One company lost the curation chain for their
BIOS releases. In some cases, the only reason this stuff works,
is because the BIOS in an Award, AMI, Phoenix, InSyde and those
companies push out the code for that.
They lost the curation chain b/c of Secure Boot requirements?
On Fri, 3/13/2026 3:18 AM, ...w¤?ñ?¤ wrote:
Frank Slootweg wrote on 3/12/2026 8:26 AM:
ÿÿ That's why I said Macrium Reflect probably doesn't even backup (the
sectors containing) the hiberfil.sys file, because there's just no
point. I/we could try to chase this down in the Macrium knowledge base
etc. or/and check the contect of an image I/we made, but I won't try
such an exercise in futility.
cf.
<https://knowledgebase.macrium.com/display/KNOWX/Backup+Defaults>
Intelligent Sector Copyÿÿÿ
Only backup data blocks that are being used by files on the disk. This significantly reduces the time it takes for backups to complete and reduces the size of the backup files.
***The data blocks in Pagefile (pagefile.sys) and hibernation (hiberfil.sys) files will be excluded from images.***
Data blocks in these files are temporary and not required when Windows starts.ÿ These files will be visible in the imaged file system, but will take up zero space in the image file.
I just tested this. I had a lot of trouble with the test subject, just getting hiberfil.sys turned on. There really is a minimum size it is happy with!
Who knew. I had to move partitions around on the test disk, it took a while to get set up for this.
The Online backup was 46,716,473 KB and the Hiberfil.sys (after having just used it to hibernate the session then wake up again) was all zeros. While it reads out as zeros, the zeros don't seem to be recorded as such. The same is true of the pagefile.sys, it's zeros and they might or might not be stored.
The Offline backup was 81,806,033 KB and the Hiberfil.sys is recorded.
The first four characters are "WAKE". The pagefile.sys is similar recorded. #HSTR:Trojan:MSIL/AgentTesla <=== a piece of some virus definitions, incoming.
Restoring an all-zeros pagefile.sys does not hurt anything. That is
because there is a GPEdit security policy that does exactly that.
It zeros the pagefile.sys at shutdown, so you "can't find those virus definitions" sitting there.
https://www.ninjaone.com/blog/virtual-memory-pagefile-encryption/
"To securely erase sensitive virtual memory data,
enable ClearPageFileAtShutdown via Group Policy...
This protects data remnants and enhances system security compliance."
The hiberfile has one header pattern for a valid head. And something different when it is invalidating the hiberfile content to prevent
accidental reuse (which might not align with file system state). so
while I can see the word "WAKE", I don't know which byte is the invalidate byte.
On Fri, 3/13/2026 4:46 AM, Paul wrote:
On Fri, 3/13/2026 3:18 AM, ...w¤?ñ?¤ wrote:
Frank Slootweg wrote on 3/12/2026 8:26 AM:
ÿÿ That's why I said Macrium Reflect probably doesn't even backup (the >>>> sectors containing) the hiberfil.sys file, because there's just no
point. I/we could try to chase this down in the Macrium knowledge base >>>> etc. or/and check the contect of an image I/we made, but I won't try
such an exercise in futility.
cf.
<https://knowledgebase.macrium.com/display/KNOWX/Backup+Defaults>
Intelligent Sector Copy
Only backup data blocks that are being used by files on the disk. This significantly reduces the time it takes for backups to complete and reduces the size of the backup files.
***The data blocks in Pagefile (pagefile.sys) and hibernation (hiberfil.sys) files will be excluded from images.***
Data blocks in these files are temporary and not required when Windows starts.ÿ These files will be visible in the imaged file system, but will take up zero space in the image file.
I just tested this. I had a lot of trouble with the test subject, just
getting hiberfil.sys turned on. There really is a minimum size it is happy with!
Who knew. I had to move partitions around on the test disk, it took a while >> to get set up for this.
Paul
On Fri, 3/13/2026 3:09 AM, ...w¤?ñ?¤ wrote:
Paul wrote on 3/11/2026 1:11 PM:
On Wed, 3/11/2026 2:08 PM, ...w¤?ñ?¤ wrote:
Some of the articles are missing the point and spreading fear beyond what will/does happen.
The fear is justified, given how stupid some of the motherboard
engineering can be. One company lost the curation chain for their
BIOS releases. In some cases, the only reason this stuff works,
is because the BIOS in an Award, AMI, Phoenix, InSyde and those
companies push out the code for that.
They lost the curation chain b/c of Secure Boot requirements?
The custody chain for BIOS updates is broken, and that injures
their ability to help customers have the best most secure
motherboards possible.
I don't use hibernation, routinely disabled(or verified as disabled) shortly after a Windows install of any type(clean, on-top, repair, feature update[now only H2]...except for testing(like you are doing).
I recall from an earlier on-MSFT-campus discussion that hiberfil.sys that was intended(oobe) to have a minimum size, but as expected that's just a starting point and growth can occur even with the same identical footprint of programs, apps, services, etc. running and without any changes to Windows.
It's like a monster *It's alive* (Victor Frankenstein, after turning on/off the electricity or lightning strike - movie version; Shelley's version - no electricity or lightning) and for my use not needed.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 15 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 215:02:49 |
| Calls: | 208 |
| Files: | 21,502 |
| Messages: | 80,773 |
