Fixing an HP EliteBook 840 G5

[jeobsplyr]

I'm a little confused.  Secure Boot Configuration is under "Advanced" heading on my machine.  Sure Start is Under "Security".  I followed the instructions, but, after enabling Secure Boot, the same screens appeared as before that I posted.  I'm not having very much success with the process. Sorry.

[NonSequitur777]

@jeobsplyr,

Hello my friend!

Excellent — and please don't apologize. Your BitLocker result is exactly what we wanted:

FullyDecrypted / Off

So, we're safe to proceed.

However, I want to correct our previous direction: do not reset or clear the Secure Boot keys again. Your 840 G5's problem appears to be the known firmware issue preventing the 2023 Secure Boot certificate update, and we now have evidence that this can be addressed manually.

For now, leave the BIOS exactly as it is:

• Legacy Support: Disabled
• Secure Boot: Disabled

Windows should boot normally.

One thing only for the next step:

Open PowerShell as Administrator and run:

Get-SecureBootUEFI -Name PK -Decoded

Please send me the complete output.

That's it. Don't change anything in BIOS and don't import or clear any keys yet.

I need the existing Platform Key (PK) information so we can identify the correct certificate-update procedure for your particular Q78 01.31.00 firmware.

We're finally moving from diagnosis to the actual repair.

Kind Regards,

NonSequitur777

[jeobsplyr]

Alright my Friend,  a little "hiccup" there, but, I'm not deterred.  Will continue to push forward with you.  Here are the results you requested:

PS C:\WINDOWS\system32> Get-SecureBootUEFI -Name PK -Decoded

SignatureOwner : f5a96b31-dba0-4faa-a42a-7a0c9832768e
Subject : O=HP Inc., C=US, OU=CODE-SIGN, CN=HP UEFI Secure Boot PK 2017
Version : 3
Algorithm : sha256RSA
SerialNumber : 5FB660D4C2FB166B6576B7257A4C37AB
ValidFrom : 2017-01-19 19:00:00Z
ValidTo : 2033-01-16 18:59:59Z

Hope this brings us into the "home stretch".  Await your response!!  PEACE!!

[NonSequitur777]

@jeobsplyr,

On it -Hello my friend!

YES — this is the result we needed, and it is actually very encouraging.

Your machine has:

HP UEFI Secure Boot PK 2017
BIOS Q78 01.31.00

That is the same configuration reported by another EliteBook 840 G5 owner who successfully completed the 2023 Secure Boot certificate update.

And here's the important part:

We are NOT going to replace your HP Platform Key.

That other 840 G5 owner reported that the PK replacement was rejected by the HP firmware -but the remaining certificate updates were accepted, and the machine successfully received the 2023 certificates.

So your 2017 HP PK is not the obstacle.

Our next step:

Before we change anything, I want to verify one thing:

Please run this in Administrator PowerShell:

([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023')

Send me the result.

That's all for now.

Do not change anything in BIOS.
Do not clear the keys.
Do not enable Secure Boot yet.

If that returns False — which I expect — then we have identified the missing piece: the Microsoft 2023 KEK.

And that is precisely the certificate the successful 840 G5 procedure says is the critical one.

We're getting very close now, my friend.

Kind Regards,

NonSequitur777

[jeobsplyr]

Okay My Friend, I have results for you:

PS C:\WINDOWS\system32> ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023')
False

Await your guidance. PEACE!

[NonSequitur777]

@jeobsplyr,

Hello my friend!

YES — this is an important result.

Microsoft Corporation KEK 2K CA 2023 = False means the 2023 KEK is not currently installed in the active Secure Boot KEK database.

That fits perfectly with the Event 1802 errors we've been seeing.

But don't change anything yet. We're going to make one final check before touching the firmware.

Please run this in Administrator PowerShell:

([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEKDefault).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023')

Send me the result — True or False.

That's all I need right now.

If it returns True, the certificate is already in the firmware's default KEK store and we have a much safer path forward.

If it returns False, we'll know the 2023 KEK isn't present there either, and I'll give you the next step based on that result.

No BIOS changes. No clearing keys. No certificate imports yet.

We're doing this one step at a time now.

PEACE, my friend!

Kind Regards,

NonSequitur777

[jeobsplyr]

Good Afternoon My Friend.  Well, I thought I could hang in with you last night, but, the "sandman" had the upper hand.  What can I say, I'm not a "night owl" much anymore.  That being said, I'm ready to tackle our issue.  The results you wanted are as follows:

PS C:\WINDOWS\system32> ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEKDefault).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023')
False

Certainly hope this sheds more light in reaching the "finish line".  Look to hear from later!  PEACE!!

[NonSequitur777]

@jeobsplyr,

Good Afternoon, my friend! And no worries whatsoever about the Sandman — I think he has defeated all of us a time or two.

Now, this result is important.

You gave us:

KEK = False

last night, and now:

KEKDefault = False

today.

That means the Microsoft Corporation KEK 2K CA 2023 certificate is absent from BOTH the currently active KEK database and the firmware's default KEK database.

And THAT fits very neatly with something Windows has already told us in Event Viewer:

Event ID 1802
Secure Boot update: KEK 2023
Blocked due to a known firmware issue
SkipReason: KI_7

So, I believe we've reached an important point in our diagnosis.

This does not look like a situation where we should manually import the KEK 2023 certificate.

Quite the opposite: Windows apparently knows the 2023 Secure Boot update is needed, but Microsoft has deliberately prevented that update from being applied to this particular firmware configuration because of a known compatibility problem.

And here's the particularly interesting part: I found another report involving an HP EliteBook 840 G5 running the same Q78 01.31.00 firmware and the same 83B2 motherboard, producing the same Event 1802 / KI_7 firmware block.

So, we're no longer chasing a mysterious Windows configuration problem. We appear to be dealing with a specific HP firmware compatibility issue involving the 2023 Secure Boot certificate transition.

Before we call the investigation complete, however, I would like to document the other half of the Secure Boot certificate database.

Please run these two read-only commands in Administrator PowerShell:

([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Windows UEFI CA 2023')

and:

([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbDefault).Bytes) -match 'Windows UEFI CA 2023')

Please send me the two results, True or False, in this order:

db = ?

dbDefault = ?

And once again:

Do NOT clear the Secure Boot keys.
Do NOT restore factory keys.
Do NOT manually import any certificates.
Do NOT change anything in the BIOS.

We're only reading the firmware variables.

At this point I believe we're very close to being able to explain exactly what your EliteBook is doing -and, just as importantly, what we should NOT try to force it to do.

Kind Regards,

NonSequitur777

[jeobsplyr]

My Friend, I have a question that has been nagging me throughout this process....Why is there so much emphasis on Secure Boot certificates, present or lack of? Can this be causing the f30 error, even if my SSD was detected and deemed "okay". I'm just trying to get a clear picture of the "dynamics" that goes into solving this. Trust me, I  have every confidence that everything your doing is proper and concise. Honestly, I would never attempt to correct this on my own. That's why your help is so vital. Then again, maybe I "think" too much...LOL! Chat with you soon!!

[NonSequitur777]

@jeobsplyr,

My Friend, that is actually an outstanding question — and no, you aren't "thinking too much."  As a matter of fact, you're asking the exact question that helps make sense of what we're actually doing rather than simply following commands.

And I want to make one important distinction very clear:

The missing 2023 Secure Boot certificates are NOT, by themselves, proof that they are causing your F30/3F0 error.

We are examining them because Secure Boot is one part of the computer's boot chain, and your Event 1802 messages specifically told us that the 2023 certificate transition is being blocked by your HP firmware.

Think of the boot process roughly like this:

1. The firmware starts the computer.

2. The firmware looks for a bootable storage device.

3. It finds the SSD and looks for the EFI boot files.

4. It locates Windows Boot Manager (bootmgfw.efi).

5. If Secure Boot is enabled, the firmware verifies that bootloader's digital signature against its trusted Secure Boot certificates.

6. If everything checks out, Windows Boot Manager takes over and Windows begins loading.

That distinction is extremely important.

Your SSD being detected and passing diagnostics tells us something very valuable: The computer can see the physical SSD, and HP's storage test considers the drive hardware healthy.

But that does NOT necessarily prove that the firmware can successfully execute the Windows bootloader on that SSD.

And conversely, a Secure Boot certificate problem generally concerns whether the firmware will trust the boot software it has already found.

So the two problems are related to different stages of the boot process.

Where the 2023 certificates fit:

The 2023 certificates are part of Microsoft's ongoing Secure Boot certificate transition. Microsoft is replacing the older 2011 certificates because they are reaching the end of their useful validity period. Microsoft specifically notes that an affected computer can continue to boot normally while still lacking the new certificates; the immediate consequence is primarily that Secure Boot won't be able to validate certain newer early-boot components after the transition.

That's why I have been interested in the certificates.

But I do not want you to think we've proven that the missing KEK 2023 certificate is responsible for your F30 error. We have not.

In fact, your earlier evidence gives us an important piece of reassurance:

Your Windows Boot Manager file: C:\Windows\Boot\EFI\bootmgfw.efi

was present, and we verified that its Authenticode signature was Valid, with Microsoft Windows as the signer.

That's good evidence that the Windows bootloader itself is legitimate.

So, why are we investigating Secure Boot at all?

Because your machine has given us two separate clues:

Clue #1 — the F30/3F0 boot problem

This tells us something is preventing the firmware from completing the boot process from the SSD.

Clue #2 — Event 1802 / KI_7

This tells us that Windows' attempt to update the Secure Boot certificate hierarchy is being blocked by a known firmware issue in your particular HP firmware.

Those two clues occur in the same general boot ecosystem, but one does not automatically prove the other caused it.

That's why we've been careful not to start changing certificates.

And that's also why I have repeatedly told you:

No clearing Secure Boot keys.
No manually importing certificates.
No factory-resetting the Secure Boot database.

We don't want to turn a diagnostic situation into a new boot problem.

So, my friend, your question actually makes me more confident in our method, not less.

We're not assuming:

"Missing certificate = F30."

We're asking:

"At which stage of the boot chain is this particular EliteBook failing, and what evidence do we have for each stage?"

I believe that is the proper way to solve this.

And I promise you: when we reach the finish line, I'll be able to explain not only what fixed it, but why it fixed it.

That's much more useful than simply getting the machine to boot by trial and error.

Kind Regards,

NonSequitur777