-
×InformationNeed Windows 11 help?Check documents on compatibility, FAQs, upgrade information and available fixes.
Windows 11 Support Center. -
-
×InformationNeed Windows 11 help?Check documents on compatibility, FAQs, upgrade information and available fixes.
Windows 11 Support Center. -
Create an account on the HP Community to personalize your profile and ask a question
Your account also allows you to connect with HP support faster, access a personal dashboard to manage all of your devices in one place, view warranty information, case status and more.
Check out our WINDOWS 11 Support Center info about: OPTIMIZATION, KNOWN ISSUES, FAQs, VIDEOS AND MORE.
HP Recommended
Good evening again, my friend -and yes, you entered the commands correctly. Thank you for taking the time to retrieve the results.
There is actually useful information here, even though neither command gave us exactly what we were hoping to find.
First: the missing TPM-WMI log is not a problem:
This:
There is not an event log on the localhost computer that matches "Microsoft-Windows-TPM-WMI/Operational".
simply means that this particular Windows installation does not have that event channel registered. Please don't try to create it or troubleshoot that further. We can cross that item off our list.
Second: the three Event 7017 entries aren't the Secure Boot evidence we need:
All three entries are from:
Provider: Netwtw06
Event ID: 7017
Netwtw06 is the Intel wireless driver. Its message contains the words "secure boot (SB) configuration", but these entries don't tell us whether the Microsoft 2023 Secure Boot certificate update succeeded or failed.
So, I don't want to read anything into those events.
The good news is that we don't need to repeat the tests:
We already have the much more important evidence from your previous registry inspection:
- WindowsUEFICA2023Capable = 0
- UEFICA2023Status = InProgress
- DBLastUpdateErrorReason = Firmware_KI_7
- KEKLastUpdateErrorReason = Firmware_KI_7
- DB3POROMLastUpdateErrorReason = Firmware_KI_7
- DB3PUEFILastUpdateErrorReason = Firmware_KI_7
- BootMgrLastUpdateErrorReason = PCA2023NotFoundInDB
And we know:
- PK is present
- KEK is present
- db is present
- dbx is present
- SetupMode = 0
- Secure Boot is currently disabled
- The computer boots normally with Secure Boot disabled
Microsoft's current documentation confirms that the 2023 Secure Boot transition involves updating the active Secure Boot certificate databases and subsequently updating the Windows Boot Manager. Some systems can require an OEM firmware update for the process to complete successfully.
That makes your registry evidence particularly interesting.
So, let's perform one different, very targeted check:
We need to determine what certificate is actually being used to sign your current Windows Boot Manager.
Please open PowerShell as Administrator and run:
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" | Select-Object UEFISecureBootEnabled, SecureBootCapable
Then run:
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" |
Select-Object WindowsUEFICA2023Capable, UEFICA2023Status,
DBLastUpdateErrorReason, KEKLastUpdateErrorReason,
BootMgrLastUpdateErrorReason
And finally, please run:
Get-ChildItem "$env:windir\Boot\EFI\bootmgfw.efi" | Select-Object FullName, Length, LastWriteTime
No worries: these commands only read information. They do not modify the Secure Boot configuration.
Why I want this information:
We need to distinguish between two possibilities:
A. The firmware's Secure Boot database does not contain the Windows UEFI CA 2023 certificate, so the newer boot manager cannot be authenticated.
B. The firmware does contain the necessary certificate, but Windows' servicing state is stuck/inconsistent and has not successfully completed the boot-manager transition.
Those are very different problems and would require different solutions.
And there is one particularly important point: I do not want you to try to "fix" the problem by loading factory Secure Boot keys or manually adding certificates.
Your PK/KEK/db/dbx hierarchy is intact, and we should preserve that state while we determine exactly what is missing.
For now, leave the machine exactly as it is:
Secure Boot: Disabled
Legacy Support: Disabled
Windows: booting normally
Please don't clear the keys, don't reset the Secure Boot configuration, and don't repeat the certificate procedure.
We're narrowing this down now rather than making changes blindly.
And please tell your grandson I appreciate his help with the computer detective work! 😊
Once you post the output from those three commands, we'll have a much better idea whether the problem is specifically the Windows UEFI CA 2023 certificate in DB, the 2023-signed Boot Manager, or the firmware's ability to process the update.
Kind Regards,
NonSequitur777
122
9
2
HP Recommended
HP Recommended
Good morning again, my good friend! And I have to say, your grandson is going to have some serious competition for your attention today!
Thank you for getting these results to me so early. And yes — they are very useful results. In fact, I think we're getting quite close to the heart of this problem.
The short version is:
Nothing has gotten worse, and we now have considerably stronger evidence that the problem is in the Secure Boot certificate transition between Windows and the HP firmware — not with your TPM or Windows installation.
First, the July 15 Boot Manager result:
This is encouraging:
C:\WINDOWS\Boot\EFI\bootmgfw.efi
Size: 3,086,848 bytes
Last modified: July 15, 2026
So, Windows has a current/recent Boot Manager present. However, the timestamp alone doesn't tell us which certificate signed it, so we still need to identify that.
The really important result remains this:
WindowsUEFICA2023Capable : 0 UEFICA2023Status : InProgress DBLastUpdateErrorReason : Firmware_KI_7 KEKLastUpdateErrorReason : Firmware_KI_7 BootMgrLastUpdateErrorReason : PCA2023NotFoundInDB
That last line is particularly interesting: PCA2023NotFoundInDB
Windows is telling us that it cannot find the required 2023 certificate in the firmware's Secure Boot DB.
That fits extremely well with everything we've seen so far.
Remember, we already established that:
- PK is present
- KEK is present
- db is present
- dbx is present
- SetupMode = 0
- Windows boots normally with Secure Boot disabled
- TPM itself is present and operational
- Secure Boot is currently disabled
So, we're no longer looking at a simple "Secure Boot is turned off" situation.
Instead, the evidence is pointing toward:
Windows is attempting the Microsoft 2023 Secure Boot certificate transition, but the HP firmware is not successfully accepting the new certificate(s).
That would explain why Windows remains stuck at: UEFICA2023Status = InProgress
rather than eventually reaching: Updated
One thing I want to emphasize:
Please don't change anything in the BIOS yet.
In particular:
- Don't clear Secure Boot keys.
- Don't manually add certificates.
- Don't repeatedly load factory keys.
- Don't reset the TPM.
- Don't reinstall Windows.
- Don't rebuild the boot configuration.
We're actually in a pretty good diagnostic position right now, and I don't want to disturb the evidence we've collected.
Let's make four final read-only checks:
Please open PowerShell as Administrator and run these one at a time.
1. Let's see exactly what is contained in the firmware's DB:
Get-SecureBootUEFI -Name db | Format-List
2. And let's examine the firmware's KEK:
Get-SecureBootUEFI -Name KEK | Format-List
3. Now let's determine which certificate actually signed your Windows Boot Manager:
Get-AuthenticodeSignature "$env:windir\Boot\EFI\bootmgfw.efi" | Format-List Status,StatusMessage,SignerCertificate
4. Finally, let's see whether Windows' Secure Boot servicing task is still active:
Get-ScheduledTask -TaskPath "\Microsoft\Windows\PI\" -TaskName "Secure-Boot-Update" | Select-Object TaskName,State
These are read-only commands. They won't modify your Secure Boot configuration.
What we're looking for:
The first two commands should help us determine whether the Windows UEFI CA 2023 certificate is actually present in the firmware's trust databases.
The third should tell us whether your current bootmgfw.efi is signed with the older Windows certificate or the newer 2023 certificate.
And the fourth will tell us whether Windows still has its Secure Boot certificate-update mechanism waiting to complete.
At that point, we'll have a much clearer picture of whether:
A. the HP firmware is missing the required 2023 certificate,
B. Windows has the newer Boot Manager but the firmware cannot authenticate it,
or
C. Windows' servicing state itself has become stuck.
And that distinction matters, because the appropriate fix is very different in each case.
So, my friend, I think we're finally past the "let's try this and see what happens" stage. We're now doing actual forensic work on the Secure Boot trust chain.
For now, leave the machine exactly as it is:
Secure Boot: Disabled
Legacy Support: Disabled
Windows: Booting normally
Enjoy your time with your grandson, and when you get a chance, post those four outputs. We'll take the next step from there.
And yes... you're definitely getting the hang of PowerShell now!
Kind Regards,
NonSequitur777
122
9
2
HP Recommended
HP Recommended
Good afternoon again, my friend! And you picked a pretty good time to do some computer detective work — hopefully your grandson got a good nap!
These results are definitely useful, and one of them is particularly important.
We now know something we didn't know before:
Your current Windows Boot Manager is still signed with the 2011 Microsoft certificate:
Your result says:
Subject: Microsoft Windows
Issuer: Microsoft Windows Production PCA 2011
That is significant.
Microsoft's current Secure Boot guidance says the transition is intended to move Windows boot components to the newer 2023 certificate chain, and the Windows UEFI CA 2023 certificate is the certificate that should be present in the firmware's DB to allow the Windows OS Loader to be authenticated.
So, we now have an interesting combination:
- UEFICA2023Status = InProgress
- WindowsUEFICA2023Capable = 0
- DBLastUpdateErrorReason = Firmware_KI_7
- KEKLastUpdateErrorReason = Firmware_KI_7
- BootMgrLastUpdateErrorReason = PCA2023NotFoundInDB
- Current bootmgfw.efi is signed by Microsoft Windows Production PCA 2011
That is a very coherent picture.
It suggests Windows has not completed the transition to the 2023 Secure Boot trust chain on this machine.
But there is one thing we must NOT assume yet
The Get-SecureBootUEFI results:
Name : db
Bytes : {161, 89, 192, 165...}
and:
Name : KEK
Bytes : {161, 89, 192, 165...}
do not tell us which certificates are actually contained in DB and KEK.
Those commands simply return the raw UEFI variable contents. Microsoft documents Get-SecureBootUEFI as returning the raw UEFI variable data, so we need to inspect that data for the certificate names.
And this is exactly what I want to do next.
One more interesting result:
The last command produced: TaskName State
with nothing underneath it.
That means Windows did not return a matching scheduled task named Secure-Boot-Update at that path.
I'm not going to interpret that as a failure yet. The Secure Boot certificate servicing mechanism has changed over time, and the absence of that particular task does not by itself prove that Windows' servicing mechanism is broken.
So, let's leave that one alone.
Let's perform two very targeted certificate checks:
Please open PowerShell as Administrator and run:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes)) -match 'Windows UEFI CA 2023'
Then:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes)) -match 'Microsoft Corporation KEK 2K CA 2023'
These should return either:
True
or:
False
These are the results I particularly want.
Microsoft's current Secure Boot documentation identifies Windows UEFI CA 2023 as the certificate that belongs in DB, while Microsoft Corporation KEK 2K CA 2023 belongs in KEK and permits updates to DB/DBX.
And let's check the other Microsoft 2023 certificates while we're at it:
Please also run:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes)) -match 'Microsoft UEFI CA 2023'
and:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes)) -match 'Microsoft Option ROM UEFI CA 2023'
So we'll have four simple answers:
Certificate Expected location
| Microsoft Corporation KEK 2K CA 2023 | KEK |
| Windows UEFI CA 2023 | DB |
| Microsoft UEFI CA 2023 | DB |
| Microsoft Option ROM UEFI CA 2023 | DB |
Microsoft's current guidance lists these certificates and their intended Secure Boot locations.
This is the key diagnostic point:
If Windows UEFI CA 2023 = False, while we already know:
BootMgrLastUpdateErrorReason = PCA2023NotFoundInDB
and the installed Boot Manager is still signed by:
Microsoft Windows Production PCA 2011
then we have three independent pieces of evidence pointing in the same direction.
That would make the diagnosis considerably stronger:
The Windows Secure Boot certificate transition is stuck because the firmware's Secure Boot DB does not contain the required Windows UEFI CA 2023 certificate.
And if the KEK 2023 certificate is also absent, that would explain why Windows cannot successfully update the DB through the normal servicing mechanism.
Please don't change anything yet
This is important.
Do not manually add the certificates.
Do not clear Secure Boot keys.
Do not load factory keys again.
Do not reset the TPM.
Do not reinstall Windows.
We're now very close to establishing exactly where the transition is failing, and I don't want to alter the Secure Boot databases before we've documented their current state.
Once you post those four True/False results, I think we'll be able to answer a much more precise question:
Is Windows failing to update the certificates because the required 2023 trust anchors are absent from the HP firmware, or are the certificates already present and Windows' servicing state is simply stuck?
That distinction is extremely important, because if the 2023 certificates are genuinely absent from the firmware, the appropriate solution is likely to involve HP firmware support rather than another Windows reinstall or another attempt to repair Windows.
We're getting there, my friend. This is now a much more narrowly defined Secure Boot trust-chain problem than where we started.
Kind Regards,
NonSequitur777
122
9
2
HP Recommended
HP Recommended
Good evening, my friend! And no apology necessary whatsoever. In fact, the corrected result is quite helpful — and it changes one part of our interpretation in an important way.
I also checked Microsoft's current Secure Boot documentation and HP's current support information for the EliteBook 840 G5, and there is a particularly interesting development: HP's support page for this exact model now explicitly flags that the product may experience an HP Secure Boot error after installing a cumulative Microsoft Security Update.
First: the scheduled task result is actually good news:
We now have:
TaskName State -------- ----- Secure-Boot-Update Ready
That means the Windows Secure Boot servicing task does exist and is enabled/ready to run. So we can discard my previous concern that the task might be missing.
Microsoft's current documentation confirms that \Microsoft\Windows\PI\Secure-Boot-Update is the mechanism Windows uses to process the Secure Boot certificate updates.
But I want to correct something from my previous post:
The four False results are interesting, but they are not yet definitive proof that the certificates are absent.
The reason is that Get-SecureBootUEFI returns the raw EFI Signature List binary data. Simply converting that binary data to an ASCII string and searching it for a certificate's subject name isn't a sufficiently reliable certificate-enumeration method.
So I don't want us to jump from: False
to: "The certificate definitely isn't in DB."
That would be too strong.
However, the results are still consistent with everything else we've found, particularly:
- UEFICA2023Status = InProgress
- WindowsUEFICA2023Capable = 0
- DBLastUpdateErrorReason = Firmware_KI_7
- KEKLastUpdateErrorReason = Firmware_KI_7
- BootMgrLastUpdateErrorReason = PCA2023NotFoundInDB
- Windows Boot Manager is still signed by Microsoft Windows Production PCA 2011
Microsoft's current Secure Boot requirements specifically identify Microsoft Corporation KEK 2K CA 2023 for KEK and Windows UEFI CA 2023 for DB.
And Microsoft says that systems still using the 2011 certificates can continue booting, but they can encounter problems receiving future Secure Boot protections and early-boot component updates.
There is another very important clue:
The timing is now significant.
The 2011 Secure Boot certificates began expiring in June 2026, and Microsoft has been transitioning Windows systems to the 2023 trust chain.
And HP's current support page for the EliteBook 840 G5 specifically warns of a Secure Boot error after installing a cumulative Microsoft Security Update.
That makes your grandson's machine look increasingly like a real interaction between Microsoft's 2023 Secure Boot certificate transition and the HP firmware, rather than a damaged Windows installation.
So, let's NOT change anything yet.
I agree with your previous approach: no clearing keys, no factory-key reset, no TPM reset, and no Windows reinstall.
Instead, let's determine exactly what Windows believes the servicing mechanism is trying to do.
Please open PowerShell as Administrator and run these four commands:
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' | Select-Object UEFICA2023Status, WindowsUEFICA2023Capable, AvailableUpdates, UEFICA2023Error
Then:
Get-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update' | Get-ScheduledTaskInfo | Select-Object LastRunTime, LastTaskResult, NextRunTime
Then:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='TPM-WMI'; Id=1795,1801,1802} -MaxEvents 10 | Select-Object TimeCreated, Id, LevelDisplayName, Message
And finally:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot" /v AvailableUpdates
Please don't run Start-ScheduledTask yet.
I specifically want to see the task's LastTaskResult and the current AvailableUpdates value before we deliberately trigger it.
Why this is the right next step:
We're now trying to answer a much more precise question:
Is Windows already attempting the 2023 Secure Boot transition but the HP firmware is rejecting the requested update, or has Windows simply not queued the appropriate update operation yet?
That distinction matters enormously.
Microsoft's current documentation confirms that Windows uses the AvailableUpdates mechanism to tell the Secure Boot servicing task which certificate updates to apply.
And if the task has already run and LastTaskResult corresponds to an unsuccessful firmware operation, that would give us considerably stronger evidence that the problem is occurring at the firmware interface, rather than inside Windows itself.
One final point I really like about this investigation: we now have HP and Microsoft evidence converging on the same general area. HP's current EliteBook 840 G5 support material explicitly flags a Secure Boot problem following cumulative Microsoft updates, while Microsoft's documentation confirms the 2023 certificate transition is occurring now.
So we're no longer just chasing an obscure Secure Boot symptom. We're narrowing down the actual servicing failure.
Post those four results, my friend, and then we'll decide whether it is appropriate to let Windows actually attempt the update.
Kind Regards,
NonSequitur777
122
9
2
HP Recommended
HP Recommended
These results are actually very useful, and I think we should resist the temptation to change anything just yet. There is one especially important result here.
The Secure Boot update task is completing successfully:
You got:
LastRunTime : 8/27/2026 7:50:07 PM LastTaskResult : 0
A LastTaskResult of 0 means the scheduled task itself completed successfully.
That is significant because Windows is running the Secure-Boot-Update task. So, we can now rule out:
- Missing scheduled task
- Disabled scheduled task
- Task failing to execute
And we also have: AvailableUpdates = 0
That means Windows currently has no pending Secure Boot database update queued.
But here's the interesting part:
UEFICA2023Status : 0 WindowsUEFICA2023Capable : [blank] AvailableUpdates : 0 UEFICA2023Error : [blank]
Combined with the information we already have, this tells us something quite important:
The servicing task is running successfully, but Windows is not currently staging a Secure Boot certificate update.
That is very different from the task itself failing.
And I want to correct one thing from my previous reasoning:
The four ASCII searches returning False are not sufficient to prove that the certificates are absent from DB/KEK.
We need to inspect the actual EFI signature lists and decode the certificates properly. The raw Bytes returned by Get-SecureBootUEFI aren't intended to be searched as ordinary ASCII text.
So, please don't conclude yet that the 2023 certificates are absent from the firmware.
The TPM-WMI error isn't concerning
This:
There is not an event provider on the localhost computer that matches "TPM-WMI"
doesn't indicate a TPM failure.
The command I gave you was simply too restrictive for this particular system. We already have other evidence concerning TPM-WMI from the earlier investigation, so let's not spend time chasing that error right now.
Here's what I want to do next:
Since Windows' scheduled task is apparently functioning normally, let's have Windows tell us what Secure Boot certificates it actually sees.
Please run this in PowerShell as Administrator:
Get-SecureBootUEFI -Name db | Format-List *
and:
Get-SecureBootUEFI -Name KEK | Format-List *
Then I want to obtain the actual certificate information from the EFI variables rather than trying to interpret the binary data as ASCII.
Please also run:
Confirm-SecureBootUEFI
and:
Get-SecureBootUEFI -Name PK | Format-List *
Don't modify anything in BIOS. Don't clear the keys. Don't load factory keys. And don't manually enroll anything.
We're still in diagnostic mode.
One thing has changed in our picture:
At the beginning, we were wondering whether Windows' Secure Boot servicing mechanism was simply broken.
I don't think that's our leading hypothesis anymore.
We now know:
1. The Secure-Boot-Update task exists.
2. It is Ready.
3. It has actually run.
4. It returned LastTaskResult = 0.
5. AvailableUpdates = 0.
Yet we also have the previously reported:
UEFICA2023Status = InProgress
WindowsUEFICA2023Capable = 0
DBLastUpdateErrorReason = Firmware_KI_7
KEKLastUpdateErrorReason = Firmware_KI_7
BootMgrLastUpdateErrorReason = PCA2023NotFoundInDB
and the installed Windows Boot Manager is still signed through the 2011 Microsoft production certificate chain.
That is an increasingly interesting combination.
In other words, Windows' servicing machinery appears healthy enough to execute, but the machine's Secure Boot state has not completed the 2023 transition.
And because this is an EliteBook 840 G5, I am particularly interested in determining exactly what is currently enrolled in its PK/KEK/DB before we touch anything. That will let us distinguish between:
A. The required 2023 certificates aren't actually present in the firmware,
and:
B. They are present, but Windows has some other reason for reporting the system as incapable/in-progress.
That distinction is now the heart of the investigation.
So, my friend, enjoy dinner and let the computer sit exactly as it is.
When you're ready, post those four outputs. I think we're getting very close to the point to tell you whether this is something you can safely correct from Windows, or whether we're looking at an HP firmware-level Secure Boot compatibility problem.
Kind Regards,
NonSequitur777
122
9
2
HP Recommended
Be alert for scammers posting fake support phone numbers and/or email addresses on the community.
If you think you have received a fake HP Support message, please report it to us by clicking on "Flag Post".
Didn't find what you were looking for?
Ask the community