Fixing an HP EliteBook 840 G5

[jeobsplyr]

Hello Again My Friend.  The results you wanted are as follows:

PS C:\WINDOWS\system32> ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Windows UEFI CA 2023')
False

PS C:\WINDOWS\system32> ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbDefault).Bytes) -match 'Windows UEFI CA 2023')
False

Well, I guess I'm not feeling too optimistic right now.  Feel like I'm going to keep Secure Boot off so I can use my laptop.  And all because I tried doing something I should've.  That f30 error lingers in my mind, wish it never happened.  anyway, I look forward to your response.  PEACE!!

[jeobsplyr]

My Friend, much, much thanks for that detailed explanation.  Makes so much sense to me, now.  That's how I like an explanation to be presented.....simple, concise, most importantly, in a way I can understand it.  Hanging in there....👍!!

[NonSequitur777]

@jeobsplyr,

Hello again, my friend! And please don't lose heart over those results.

Actually, I don't think today's results are bad news at all. They are exactly what I would expect given the Event 1802/KI_7 evidence we already have.

You now have:

KEK → Microsoft KEK 2023: False

KEKDefault → Microsoft KEK 2023: False

db → Windows UEFI CA 2023: False

dbDefault → Windows UEFI CA 2023: False

That tells us that the 2023 certificates have not been provisioned into either the active or default Secure Boot stores.

But here's the important part:

This does NOT mean your EliteBook is broken.

And it does NOT mean we have proven that these missing certificates caused your F30.

Remember that Event 1802 already told us the reason Windows isn't completing that certificate transition:

"The Secure Boot update KEK 2023 was blocked due to a known firmware issue on the device."

That's a very different situation from:

"The computer cannot boot because its Secure Boot certificates are missing."

In fact, your earlier testing gave us several reassuring pieces of information:

• The SSD is detected.

• HP's storage diagnostics consider the SSD okay.

• The Windows EFI boot manager exists.

• We verified that bootmgfw.efi has a valid Microsoft digital signature.

Those are all good facts.

And please don't blame yourself.

You said: "all because I tried doing something I should've."

My friend, you didn't do anything foolish!

You were trying to solve a legitimate problem. Secure Boot is something Microsoft, HP, Windows 11, and modern games increasingly depend upon, so trying to understand and correct a Secure Boot situation was completely reasonable.

The problem is that we are dealing with a rather unusual intersection of:

HP firmware + Secure Boot + Microsoft's 2023 certificate transition + a documented firmware compatibility block + the original F30 boot incident.

That's why this has required so much detective work.

And here's what I want you to do right now:

Keep Secure Boot OFF.

If that allows the EliteBook to boot into Windows normally, use the laptop.

Don't change anything else.

Don't clear the Secure Boot keys.

Don't import certificates.

Don't reset the TPM.

Don't reinstall Windows.

Don't touch the SSD.

In other words:

Let's preserve the working state we have.

The fact that the machine operates with Secure Boot disabled is actually useful information for our diagnosis.

It gives us a controlled baseline.

And I want you to remember something important:

We haven't reached the finish line yet — but we also haven't gone backward.

We've eliminated several possibilities and identified something unusually specific in the firmware:

HP Q78 01.31.00 / board 83B2 / KI_7 / Event 1802.

That is a much stronger diagnostic position than we had when we started.

The F30 is still the question I care most about. The Secure Boot certificate issue is a separate, related investigation, and I don't want us allowing the certificate results to make us conclude that we have found the cause of the F30 when the evidence doesn't say that.

So, for now, my friend:

Secure Boot OFF → Windows boots → leave it alone.

You haven't lost the battle. Quite the contrary — we're finally getting enough evidence to understand what this machine is actually doing.

And we'll keep the F30 question firmly in our sights.

One Small Addendum, My Friend:

Before you do anything else, I want to make our next step absolutely clear.

We are going to temporarily put the Secure Boot certificate investigation aside and return our attention to the original F30 problem.

For now, please leave Secure Boot Support DISABLED — exactly as it is now.

Then:

1. Boot normally into Windows.

2. Confirm that Windows operates normally.

3. Open Administrator PowerShell and run: Confirm-SecureBootUEFI

Please report the result.

4. Then run:

Get-Disk | Select Number, FriendlyName, PartitionStyle, OperationalStatus

Please report the complete output.

5. Finally, run:

Get-Partition | Select DiskNumber, PartitionNumber, DriveLetter, Type, Size

Again, send me the complete output.

What we're establishing:

We're creating a known-good baseline:

UEFI → SSD detected → Windows boot files accessible → Windows boots normally → Secure Boot OFF

If all of that checks out, we'll know that the fundamental storage/UEFI/Windows boot path is functioning when Secure Boot isn't involved.

That is extremely useful information.

And then we'll decide what the next controlled test should be.

Please do NOT enable Secure Boot yet.

And absolutely no:

• clearing Secure Boot keys
• restoring factory keys
• importing certificates
• resetting the TPM
• reinstalling Windows
• rebuilding the boot configuration
• changing BIOS settings other than what we've explicitly discussed

We've gathered enough information now that we don't need to experiment blindly.

One controlled step at a time, my friend.

And remember: those four False results did not mean that four things have failed. They gave us a consistent picture of the 2023 certificate transition being blocked by the HP firmware.

Now we're going back to the question that started this whole journey:

Why did the F30 occur, and what exactly happens when Secure Boot is involved?

That's the question we're going to answer next.

Kind Regards,

NonSequitur777

[jeobsplyr]

Thank you for your reassurance and the confidence to stay the course.  Please excuse my "temporary" lack of faith toward a solution.  Your words have renewed my resolve in staying the course.  Here are your results:

PS C:\WINDOWS\system32> Get-Disk | Select Number, FriendlyName, PartitionStyle, OperationalStatus
>>

Number FriendlyName PartitionStyle OperationalStatus
------ ------------ -------------- -----------------
1 Msft Virtual Disk GPT Online
0 CT1000P3PSSD8 GPT Online

PS C:\WINDOWS\system32> Get-Partition | Select DiskNumber, PartitionNumber, DriveLetter, Type, Size

DiskNumber : 1
PartitionNumber : 1
DriveLetter :
Type : Basic
Size : 33488896

DiskNumber : 0
PartitionNumber : 1
DriveLetter :
Type : System
Size : 377487360

DiskNumber : 0
PartitionNumber : 2
DriveLetter :
Type : Reserved
Size : 16777216

DiskNumber : 0
PartitionNumber : 3
DriveLetter : C
Type : Basic
Size : 998563119104

DiskNumber : 0
PartitionNumber : 4
DriveLetter :
Type : Recovery
Size : 1244659712

Awaiting further instruction.  PEACE!!

[NonSequitur777]

@jeobsplyr,

My Friend, NOW we're getting somewhere. And these results are considerably more encouraging than you may realize.

Your SSD/storage configuration looks very healthy from the information you've just provided.

Here's what your results tell us:

Your physical SSD is:

Disk 0 — CT1000P3PSSD8

and Windows reports it as:

GPT — Online

That's exactly what we want for a modern UEFI Windows installation.

Even better, Disk 0 contains:

Partition 1 — System — ~360 MB

That is your EFI System Partition (ESP).

Then:

Partition 2 — Reserved — 16 MB

That's the normal Microsoft Reserved partition.

Partition 3 — C: — ~999 GB

That's your Windows partition.

And:

Partition 4 — Recovery — ~1.24 GB

That's your Windows Recovery partition.

So, in simplified form, your SSD looks like this:

CT1000P3PSSD8

→ EFI System Partition
→ Microsoft Reserved Partition
→ Windows (C:)
→ Recovery Partition

That is a normal GPT/UEFI Windows installation.

And remember: HP's diagnostic already found the SSD itself to be okay.

So, we're progressively eliminating the possibility that the F30 is simply: "The SSD is dead."

It clearly isn't.

One thing is missing:

I don't see the result from the first command I asked you to run:

Confirm-SecureBootUEFI

Please run that one again and send me the result.

I expect it to be: False

because we deliberately have Secure Boot disabled.

Then I want one more read-only examination:

Please run: bcdedit /enum {bootmgr}

and send me the complete output.

Then run: bcdedit /enum {current}

and send me that complete output as well.

Do not change anything based on what these commands show.

We're simply asking Windows: "What does your Boot Manager configuration say, and which Windows installation is it configured to boot?"

This is the next logical layer of the investigation.

We're moving through the boot chain systematically:

SSD hardware

✓ detected
✓ HP diagnostics okay

Partition structure
✓ GPT
✓ EFI System Partition present
✓ Windows partition present
✓ Recovery partition present

Next:

UEFI/Windows Boot Manager configuration

And only after we understand that will we decide whether Secure Boot has anything to do with the F30 behavior.

So please stay the course, my friend.

No BIOS changes. No certificate changes. No key clearing. No boot repairs.

We're still in information-gathering mode, and that's exactly where I want us right now.

Kind Regards,

NonSequitur777

[jeobsplyr]

Okay My Friend.  Here's the results you wanted.  "Onward and Upward", lets solve this thing!!!

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

C:\Windows\System32>bcdedit /enum {bootmgr}

Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=\Device\HarddiskVolume1
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-us
inherit {globalsettings}
default {current}
resumeobject {5e95034e-974d-11f1-bdb1-f43909776b19}
displayorder {current}
toolsdisplayorder {memdiag}
timeout 30

C:\Windows\System32>bcdedit /enum {current}

Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \WINDOWS\system32\winload.efi
description Windows 11
locale en-us
inherit {bootloadersettings}
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {5e95034e-974d-11f1-bdb1-f43909776b19}
nx OptIn
bootmenupolicy Standard

I'm with you all the way!!  Look to hear from you soon!!!  PEACE!!

[NonSequitur777]

@jeobsplyr,

My Friend — THIS is excellent! “Onward and Upward” indeed!

I believe we have just eliminated another major possibility.

Your BCD configuration is internally consistent and, importantly, it points to exactly the files and partitions we would expect on a healthy UEFI Windows installation.

Let's translate what your computer just told us.

Windows Boot Manager:

Your system says: path \EFI\Microsoft\Boot\bootmgfw.efi

That is the correct Microsoft UEFI Windows Boot Manager.

It also says: default {current}

So Boot Manager knows which Windows installation to launch.

Windows Boot Loader:

Your {current} entry says: device partition=C:

and: osdevice partition=C:

and: path \WINDOWS\system32\winload.efi

Again, that is exactly what we want.

In other words:

UEFI/GPT partitioning — GOOD

SSD detected and online — GOOD

EFI System Partition exists — GOOD

Windows partition exists — GOOD

Boot Manager points to the EFI bootloader — GOOD

Boot Loader points to C: — GOOD

Windows loader is winload.efi — GOOD

And Secure Boot is currently: False

which is expected because we've intentionally left it disabled.

This is an important milestone:

At this point, I do NOT want you to run bcdboot or perform any boot repair.

There is no evidence in the information you've provided that your BCD is broken.

And this is precisely why we've been taking this slowly.

We don't repair something that the evidence says is already working.

One final read-only check before we test Secure Boot:

Let's verify the actual contents of the EFI System Partition that Windows Boot Manager is using.

Please run these commands in Administrator PowerShell, one at a time:

mountvol S: /S

Then:

Get-ChildItem S:\EFI\Microsoft\Boot\ -File | Select Name, Length

Then:

Get-ChildItem S:\EFI\Microsoft\Boot\ -Filter bootmgfw.efi

And finally:

Get-AuthenticodeSignature S:\EFI\Microsoft\Boot\bootmgfw.efi | Select Status,SignerCertificate

Please send me the complete output from all four commands.

IMPORTANT:

These are read-only examinations except for mountvol, which merely assigns a temporary drive letter to the existing EFI System Partition.

Do not delete, copy, rename, or modify anything on S:.

When we're finished examining it, I'll have you remove that temporary drive letter.

We're now narrowing the question down very nicely:

Is the F30 occurring because the firmware cannot properly proceed from the EFI System Partition into the already-valid Windows Boot Manager when Secure Boot is enabled?

That's a much more precise question than where we started.

And based on everything you've given me so far, I am much more optimistic than I was earlier.

We're not looking at an obviously dead SSD, a bad GPT layout, or an obviously broken BCD.

We're getting down to the actual boot transition where the problem is occurring.

Onward and upward, my friend!

Kind Regards,

NonSequitur777

[jeobsplyr]

Well My Friend, I got some more results for you.  I feel a "breakthrough" coming!  Let's make it a "reality"!  One sept at a time, of course. Results are:

PS C:\WINDOWS\system32> mountvol S: /S

PS C:\WINDOWS\system32> Get-ChildItem S:\EFI\Microsoft\Boot\ -File | Select Name, Length

Name Length
---- ------
kd_07_1415.dll 58784
kd_0C_8086.dll 87440
SecureBootRecovery.efi 174584
winsipolicy.p7b 10341
bootmgfw.efi 3086728
bootmgr.efi 3069432
kdnet_uart16550.dll 58776
kdstub.dll 87536
kd_02_10df.dll 71072
kd_02_10ec.dll 562592
kd_02_1137.dll 71064
kd_02_14e4.dll 284048
kd_02_15b3.dll 91552
kd_02_1969.dll 83328
kd_02_19a2.dll 71056
memtest.efi 2603984
boot.stl 12521
kd_02_1af4.dll 62864
BCD 73728
kd_02_8086.dll 361872
kd_02_1414.dll 99752
kd_02_15ad.dll 58792
kd_02_1d0f.dll 83328

PS C:\WINDOWS\system32> Get-ChildItem S:\EFI\Microsoft\Boot\ -Filter bootmgfw.efi

Directory: S:\EFI\Microsoft\Boot

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 7/15/2026 8:14 AM 3086728 bootmgfw.efi

PS C:\WINDOWS\system32> Get-AuthenticodeSignature S:\EFI\Microsoft\Boot\bootmgfw.efi | Select Status,SignerCertificate

Status SignerCertificate
------ -----------------
Valid [Subject]...

You have the "ball"!  Await your analysis!!  PEACE!!!

[NonSequitur777]

@jeobsplyr,

My Friend — I believe we have our breakthrough! And this time, the evidence is exceptionally strong.

Your latest results are exactly what I hoped to see.

The EFI System Partition contains the expected Windows UEFI boot files, including:

bootmgfw.efi — 3,086,728 bytes

And, most importantly:

Authenticode Status: Valid

That means the actual Microsoft Windows Boot Manager on the EFI System Partition is present, intact, and cryptographically valid.

Combined with everything we already established, we can now say:

UEFI/GPT installation — GOOD
EFI System Partition — GOOD
Windows Boot Manager — PRESENT
Windows Boot Manager signature — VALID
BCD — PRESENT and internally consistent
Windows boot loader — CORRECT
Windows boots normally with Secure Boot disabled — YES

So, my friend, we are finished troubleshooting the Windows installation.

I do NOT want you to run bcdboot, rebuild the BCD, reinstall Windows, repartition anything, or modify the EFI files.

There is simply no evidence that any of those things are necessary.

Now let's put this together with the most important evidence we obtained earlier:

TPM-WMI Event 1802

Your computer explicitly reported that:

KEK 2023 was blocked due to a known firmware issue on the device.

And it identified:

Firmware Manufacturer: HP
Firmware Version: Q78 Ver. 01.31.00
SkipReason: KI_7

That is the smoking gun we've been looking for.

Windows is trying to transition the Secure Boot trust configuration to the newer 2023 certificates, but the HP firmware is explicitly refusing the KEK 2023 update because of a known firmware issue.

And now we have independently proven that the Windows EFI bootloader itself is valid.

So the evidence is converging very strongly on:

HP UEFI/Secure Boot firmware — NOT Windows — as the source of the F30 failure.

We are going to perform one final controlled test.

First, whilst still in Administrator PowerShell, remove the temporary S: drive letter:

mountvol S: /D

Then reboot into BIOS Setup.

Leave:

Legacy Support = Disabled

Change only:

Secure Boot Support = Enabled

Save the change and reboot.

Do not change any Secure Boot keys.

Do not select CLEAR.

Do not restore security settings to factory defaults.

Do not attempt another certificate installation.

Then tell me exactly what happens.

If we get the F30 again, we will have an extremely strong A/B test:

Secure Boot OFF → Windows boots

Secure Boot ON → HP firmware produces F30

while the underlying Windows EFI installation remains unchanged and has a valid Microsoft-signed Boot Manager.

At that point, my friend, I believe we can confidently say:

The problem is in the HP firmware/Secure Boot path, not in Windows.

And THAT would indeed be the breakthrough we've been working toward.

One step at a time.

Onward and Upward!

PEACE, my friend!

Kind Regards,

NonSequitur777

[jeobsplyr]

Sorry My Friend,  this is what happened:

PS C:\WINDOWS\system32> mountvol S: /D
The system cannot find the file specified.

After enabling Secure Boot:

Not very promising..PEACE!!