Fixing an HP EliteBook 840 G5

[jeobsplyr]

Hello my Friend.  Here are the results you requested.

PS C:\WINDOWS\system32> Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' |
>> Select-Object UEFICA2023Status, WindowsUEFICA2023Capable, AvailableUpdates
>>

UEFICA2023Status WindowsUEFICA2023Capable AvailableUpdates
---------------- ------------------------ ----------------
0

PS C:\WINDOWS\system32> Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' |
>> Select-Object UEFICA2023Status, UEFICA2023Error, UEFICA2023ErrorEvent

UEFICA2023Status UEFICA2023Error UEFICA2023ErrorEvent
---------------- --------------- --------------------
InProgress 0 0

Hope this will help you further.  Awaiting your analysis, "Fingers Crossed"!!!! PEACE!!!

[NonSequitur777]

@jeobsplyr,

Hello again, my friend! And those crossed fingers may have worked. 😊

I believe we have now reached the point where we can say something quite definitive.

Look, your latest results show:

UEFICA2023Status : InProgress

UEFICA2023Error : 0

UEFICA2023ErrorEvent : 0

That means the Windows Secure Boot servicing mechanism is not recording a failure.

However, InProgress normally means Windows has not yet changed its servicing status marker to the final:

Updated

Microsoft describes the normal sequence as: NotStarted → InProgress → Updated

with Updated meaning all required 2023 keys and the new Boot Manager have been deployed.

But here is the really important part:

Your Event 1808 overrides much of the uncertainty

You already have:

Event ID 1808 — August 13, 2026, 3:37 PM

which says: "This device has updated Secure Boot CA/keys."

and specifically lists:

• Windows UEFI CA 2023
• Option ROM CA 2023
• 3P UEFI CA 2023
• KEK 2023
• Boot Manager (2023)

Microsoft's own documentation says Event 1808 is generated when all required Secure Boot certificates have been applied to the firmware and the computer has been updated to the Boot Manager signed by Windows UEFI CA 2023.

Microsoft goes even further and specifically states:

"This event indicates that the device is fully updated."

So, despite the registry status still displaying InProgress, we have Microsoft's success event telling us that the actual Secure Boot firmware transition completed.

That is excellent news!

What about those earlier Event 1802 errors?

Those now have a logical explanation.

Earlier on August 12 and August 13, Windows attempted the update and encountered the HP firmware compatibility block:

Event 1802 — known firmware issue — KI_7

But afterward, at 3:37 PM on August 13, the system recorded Event 1808.

So the sequence appears to be:

Windows attempts update → firmware temporarily blocks it → Windows retries → update succeeds → Event 1808 recorded.

That is exactly the sort of chronological evidence we were hoping to find.

And your current error values are zero.

This is also reassuring:

UEFICA2023Error : 0

UEFICA2023ErrorEvent : 0

There is no present servicing fault being recorded.

So I do not recommend trying to force anything manually.

Please do NOT:

• clear Secure Boot keys
• restore factory keys
• reset the TPM
• change registry values manually
• force AvailableUpdates
• reinstall Windows
• flash the BIOS again

At this stage, those actions would introduce unnecessary risk into a machine that has already produced Microsoft's Secure Boot success event.

One last very small check:

I would like to verify the machine's present Secure Boot operating state rather than modify anything.

Please run these two commands in Administrator PowerShell:

Confirm-SecureBootUEFI

and:

Get-Tpm

For the second command, I mainly want to see:

• TpmPresent
• TpmReady
• TpmEnabled
• TpmActivated
• RestartPending

Please paste the results exactly as shown.

If Confirm-SecureBootUEFI returns: True

and the TPM remains present/ready/enabled/activated, then I think we can finally say:

Secure Boot is functioning correctly, the 2023 Secure Boot update successfully completed at the firmware level, and there is nothing further we should force or repair.

The lingering InProgress registry value can then be treated as a Windows servicing-state bookkeeping issue unless Windows subsequently changes it to Updated.

My friend, I really do think we're at the finish line now!

Kind Regards,

NonSequitur777

[jeobsplyr]

Well, my friend, here are your latest results:

PS C:\WINDOWS\system32> Confirm-SecureBootUEFI
False

PS C:\WINDOWS\system32> Get-Tpm

TpmPresent : True
TpmReady : True
TpmEnabled : True
TpmActivated : True
TpmOwned : True
RestartPending : False
ManufacturerId : 1229346816
PpiVersion : 1.3
ManufacturerIdTxt : IFX
ManufacturerVersion : 7.63.3353.0
ManufacturerVersionFull20 : 7.63.3353.0
ManagedAuthLevel : Full
OwnerAuth :
OwnerClearDisabled : False
AutoProvisioning : Enabled
LockedOut : False
LockoutHealTime : 2 hours
LockoutCount : 21
LockoutMax : 32
SelfTest : {}

Guess the "false" result is not promising, I guess.  Anyway, let me know your analysis.  Chat with you soon!!  PEACE!!

[NonSequitur777]

@jeobsplyr,

Hello again, my friend! And YES -there we go: this actually gives us the answer we needed. 😊

First, please don't be discouraged by that False.

The TPM is excellent!

Your TPM results are exactly what we want:

• TPM Present: True
• TPM Ready: True
• TPM Enabled: True
• TPM Activated: True
• TPM Owned: True
• Restart Pending: False

So the TPM is not our problem. We can take that completely off the suspect list.

The important result is this:

Confirm-SecureBootUEFI
False

That means Secure Boot is currently OFF in the UEFI firmware.

And I think this is the point where our troubleshooting finally becomes straightforward.

Remember, we already have the very important Event 1808 from August 13 saying:

"This device has updated Secure Boot CA/keys."

and it specifically lists the 2023 DB certificates, KEK 2023, and the 2023-signed Boot Manager.

So we should NOT go back and start manipulating certificates or keys.

Instead, we now need to address the much simpler question:

Why is Secure Boot currently disabled?

I want you to check the BIOS one more time

Please restart the EliteBook and enter BIOS Setup with F10.

Go back to the same Secure Boot Configuration screen you photographed for me previously.

Do not change any of the keys.

I want you to look specifically at the setting we discussed previously:

Secure Boot Support

If it is currently Disabled, change it to: Enabled

Then save the BIOS changes and allow Windows to boot normally.

Once Windows is back up, open PowerShell as Administrator and run only:

Confirm-SecureBootUEFI

What I expect:

If everything we've uncovered is consistent, I am hoping the result will now be: True

That would be the final piece of the puzzle!

At that point we'd have:

a properly functioning Secure Boot configuration.

One important caution, my friend:

Do NOT select Clear, Reset, Restore Factory Keys, or anything involving deleting/re-enrolling the Secure Boot keys.

We have spent considerable effort establishing that the 2023 certificate update actually occurred. There is no reason to disturb those keys now.

And I want to emphasize something else: you did not damage the TPM or "break" the computer. Your TPM is completely healthy. The False result is simply telling us that the Secure Boot switch itself is currently off.

So, my friend, I think we finally have a very simple next step:

F10 → Secure Boot Configuration → check “Secure Boot Support” → enable it if it is disabled → save → boot Windows → run Confirm-SecureBootUEFI again.

That's it. No more registry changes. No certificate manipulation. No TPM reset. No Windows reinstall.

Let's see what that one setting says. I genuinely believe this may be our last step. 🤞

PEACE, my friend!

Kind Regards,

NonSequitur777

[jeobsplyr]

Hello my friend.  Well, I did as you instructed:  Changed Secure Boot to enabled, Legacy disabled.  Got the same screens I posted earlier.  Had to restart and Disable Secure Boot, Legacy Disabled, in order to get into Windows.  Now what??  Look to hear from you soon!!

[NonSequitur777]

@jeobsplyr,

Hello again, my friend! And NOW we have the really important clue. Please don't be discouraged -this result actually narrows the problem down considerably.

You did exactly what I asked, and you did the right thing by disabling Secure Boot again when Windows would not boot. We are NOT going to keep changing BIOS settings blindly.

Here's what we now know:

Your TPM is healthy.

The 2023 Secure Boot certificate process produced a successful Event 1808.

But when you actually enable Secure Boot:

Windows will not boot.

When Secure Boot is disabled:

Windows boots normally.

That tells us something very specific:

The problem is no longer TPM. It is the UEFI Secure Boot validation of the Windows boot chain.

In other words, the firmware is refusing to authenticate something required during the Windows boot process.

And this is exactly why I don't want you clearing or resetting the Secure Boot keys. We now have a very specific problem to diagnose.

One important correction:

I don't want us to assume that because Event 1808 says the 2023 certificates were updated, everything concerning Secure Boot must therefore be correct.

Event 1808 tells us the certificate/key update completed. It does not tell us that your current Windows bootloader is successfully passing the firmware's Secure Boot signature verification.

Your symptom tells us that something in that chain is still not being accepted.

So, let's make one controlled test:

Leave the BIOS exactly as it is now:

Secure Boot: Disabled
Legacy Support: Disabled

Boot normally into Windows.

Then open PowerShell as Administrator and run these commands:

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' |
Format-List *

Then:

bcdedit /enum {bootmgr}

And finally:

bcdedit /enum {current}

Please paste the complete output of all three commands.

And I need one more thing:

Please tell me exactly what happens on the screen when you enable Secure Boot and attempt to boot.

If you see the same message you photographed previously, please give me the exact wording again.

For example, if it says something along the lines of:

"Invalid signature detected. Check Secure Boot Policy in Setup."

please give me that exact message.

If there is a different message, give me that instead.

Do NOT do any of these things yet

Please do not:

• Clear Secure Boot keys
• Reset Secure Boot keys
• Restore factory keys
• Reset the TPM
• Reinstall Windows
• Run bcdboot
• Change Legacy/CSM settings
• Flash the BIOS again

We have enough evidence now that we should be able to identify the offending component without taking any of those risks.

And my friend, this is actually progress.

We have gone from: "Something is wrong with Secure Boot."

to: "Secure Boot is being enabled, but the firmware rejects the Windows boot chain."

That is a much narrower problem.

Once I see those three command results and the exact boot-screen message, I believe we'll be able to determine whether we're dealing with the Windows Boot Manager, its signature/certificate, or the HP firmware's Secure Boot policy.

So, for now, leave Secure Boot disabled so you can use Windows, collect those results, and don't change anything else.

We're not going to give up at the finish line!

Kind Regards,

NonSequitur777

[jeobsplyr]

Okay my friend.  I'm with you, ALL THE WAY to the finish line.  Here are the results and the screen photos I took when Secure Boot is enabled.  Can't remember the exact wording, but, I have the photos.

1.  

PS C:\WINDOWS\system32> Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' |
>> Format-List *

AvailableUpdates : 0
PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
PSChildName : SecureBoot
PSDrive : HKLM
PSProvider : Microsoft.PowerShell.Core\Registry

2.  PS C:\WINDOWS\system32> bcdedit /enum {bootmgr}
Invalid command line switch: /encodedCommand
Run "bcdedit /?" for command line assistance.
The parameter is incorrect

3.  PS C:\WINDOWS\system32> bcdedit /enum {current}
Invalid command line switch: /encodedCommand
Run "bcdedit /?" for command line assistance.
The parameter is incorrect.
PS C:\WINDOWS\system32>

PHOTOS:

If you need me to rerun any commands, just hit me back.  I'll be up for awhile tonight.  I'll look to hear from you soon. PEACE!

[NonSequitur777]

@jeobsplyr,

Hello again, my friend! And THIS time I have very good news.

I have carefully examined all four photographs, and I believe we have finally identified the actual problem.

The photographs tell us exactly what is happening

The first photograph shows the HP Secure Boot Configuration screen.

The second says:

"Secure Boot keys are not configured. Please press Enter to enable secure boot."

Then we get:

HP Sure Recover

and finally:

Boot Device Not Found — 3F0

That sequence is the smoking gun.

The computer isn't rejecting Windows because Windows is damaged.

The firmware has no usable Secure Boot key configuration with which to authenticate the Windows bootloader.

That is why:

Secure Boot OFF → Windows boots

but

Secure Boot ON → Secure Boot cannot authenticate the boot path → HP Sure Recover → 3F0

And now I have something considerably better than another theory:

HP has an official recovery procedure for this exact type of problem.

HP specifically documents Secure Boot errors on its commercial systems with HP Sure Start, and the EliteBook 840 G5 is explicitly included in the affected-product list. HP's recovery procedure is:

1. Disable Sure Start Secure Boot Keys Protection
2. Disable Secure Boot
3. Reboot
4. Enter BIOS again
5. Reset Secure Boot keys to factory defaults
6. Reboot
7. Re-enter BIOS
8. Set Legacy Support = Disabled
9. Set Secure Boot = Enabled
10. Save and boot Windows

That is HP's documented procedure -not an experimental Internet workaround.

So, I am changing my earlier advice:

Earlier I told you not to reset the Secure Boot keys.

I am now changing that advice because we have new evidence.

Your photographs prove that the Secure Boot key configuration itself is the problem, and HP's own recovery instructions specifically tell us to use Reset Secure Boot keys to factory defaults for this situation.

There is an important distinction:

DO NOT select "Clear Secure Boot Keys."

We want:

"Reset Secure Boot keys to factory defaults"

Those are NOT the same operation.

HP says that the factory-reset action copies the platform's default DB/DBX contents into the active Secure Boot databases.

Before we do it — one safety precaution:

Because changing Secure Boot state can trigger BitLocker recovery, I want to check whether BitLocker is active before we touch the BIOS.

You are currently able to boot Windows with:

Legacy Support: Disabled
Secure Boot: Disabled

Please leave it exactly that way.

Open PowerShell as Administrator and run:

Get-BitLockerVolume -MountPoint C: |
Select-Object MountPoint,VolumeStatus,ProtectionStatus

Please give me the complete result.

Do NOT change anything in BIOS yet.

Once I see that result, I will walk you through the HP procedure one step at a time.

And one more thing about your bcdedit errors:

Don't worry about those.

The commands themselves weren't successfully passed to bcdedit because PowerShell interpreted the {bootmgr} / {current} portions in a way that resulted in the strange /encodedCommand error.

We don't need those commands now.

The photographs have given us much more useful information than those commands would have.

Why I am now confident about the diagnosis

We have:

TPM: completely healthy
Windows: boots normally with Secure Boot disabled
UEFI: functioning
Legacy Support: disabled
Secure Boot: fails only when enabled
BIOS: explicitly reports Secure Boot keys are not configured
Boot failure: 3F0 after Secure Boot is enabled
HP Sure Recover: follows the failed Secure Boot boot attempt

That is a remarkably coherent set of symptoms.

And it fits HP's documented Sure Start/Secure Boot recovery procedure almost perfectly.

So, my friend, we finally have a concrete path instead of another diagnostic experiment.

For right now, just give me the BitLocker result.

Don't touch anything else.

Once I see that, we'll perform the HP recovery procedure carefully and deliberately.

And yes -I still have my fingers crossed!

Kind Regards,

NonSequitur777

[jeobsplyr]

My Friend, here are the results to your last query:

PS C:\WINDOWS\system32> Get-BitLockerVolume -MountPoint C: |
>> Select-Object MountPoint,VolumeStatus,ProtectionStatus

MountPoint VolumeStatus ProtectionStatus---------- ------------ ----------------
C: FullyDecrypted Off

Okay, guess I'm ready when you are.  PEACE!!

[NonSequitur777]

@jeobsplyr,

My friend, PERFECT.

C: FullyDecrypted and ProtectionStatus: Off means BitLocker is completely out of our way.

And I think we're finally ready to fix the actual problem.

We've done enough diagnostics. No more PowerShell commands for now. We're going into the BIOS and following HP's documented recovery procedure for the Secure Boot-key configuration on the EliteBook 840 G5.

Take your time. There is absolutely no need to rush this.

STEP 1 — Enter BIOS:

Restart the computer and repeatedly tap F10 until you enter BIOS Setup.

Go to:

Security → Secure Boot Configuration

We are going to make a few deliberate changes.

STEP 2 — Disable Sure Start Secure Boot Keys Protection:

Find:

Sure Start Secure Boot Keys Protection

Set it to:

Disabled

If the BIOS asks you to confirm the change, confirm it.

STEP 3 — Make sure Secure Boot is disabled:

Set:

Secure Boot → Disabled

and:

Legacy Support → Disabled

Then Save Changes and Exit.

Let the computer restart.

STEP 4 — Enter BIOS again:

As soon as the computer restarts, press F10 again to return to BIOS Setup.

Go back to:

Security → Secure Boot Configuration

Now we want to restore the factory Secure Boot key configuration.

Look for the option that says something like:

Reset Secure Boot keys to factory defaults:

This is the option we want.

DO NOT choose:

Clear Secure Boot Keys

Those are different operations.

We want the factory reset/default operation.

If the BIOS presents a confirmation prompt, accept the factory-default Secure Boot key restoration.

STEP 5 — Re-enable Secure Boot:

After the factory keys have been restored, verify:

Legacy Support → Disabled

Then set:

Secure Boot → Enabled

Leave the Secure Boot keys themselves alone.

Do not manually add, delete, or clear anything.

STEP 6 — Save and reboot:

Save the BIOS changes and allow the computer to restart.

Now comes the moment we've been working toward.

If the factory Secure Boot keys have been restored correctly, the firmware should once again have a valid Secure Boot trust chain and should be able to authenticate the Windows Boot Manager.

IMPORTANT:

If Windows boots normally, STOP THERE.

Don't change anything else.

Once Windows is running, open Administrator PowerShell and run:

Confirm-SecureBootUEFI

We want:True

That's the result we're looking for.

Then also run:

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' |
Format-List *

Paste both results back here.

If it DOES NOT boot:

This is important.

If enabling Secure Boot again produces the same:

HP Sure Recover

followed by:

Boot Device Not Found — 3F0

do not start changing things.

Do not clear the keys.

Do not reinstall Windows.

Do not run bcdboot.

Just tell me exactly what happened and, if possible, take a photograph of the screen.

Why I am confident enough to do this now:

We have established all of the following:

TPM: healthy
Windows: boots with Secure Boot disabled
BitLocker: completely decrypted
Legacy Support: disabled
Secure Boot: currently disabled
BIOS: reports Secure Boot keys are not configured
Secure Boot ON: produces 3F0
Event 1808: records the 2023 Secure Boot CA/key update

And, most importantly, HP specifically documents restoring the factory Secure Boot keys as the remedy for this Secure Boot/Sure Start condition on this family of systems.

So this isn't another shot in the dark.

We're restoring the firmware's known-good Secure Boot trust database, then testing Secure Boot again.

My friend, we've been very careful getting here. This is the first time I'm comfortable saying: let's actually make the change. 😊

Take your time, read each BIOS option carefully, and remember the golden rule:

RESET/RESTORE FACTORY KEYS — DO NOT CLEAR THE KEYS.

I'll be right here for the result!

Kind Regards,

NonSequitur77