HP ZBook Ultra G1a / EliteBook X G1a BIOS issues

hp-g1a-bios-issues.md

HP ZBook Ultra G1a / EliteBook X G1a — Complete BIOS & Hardware Issues

(Compiled from HP forums, Reddit, Level1Techs — May 7, 2026)

---

🔴 ISSUE 1: Boot Freeze (Critical)

The bug: Starting with BIOS 01.03.11 (EliteBook) / 01.04.03–01.04.05 (ZBook), the laptop freezes at the HP logo/spinning circle during boot. Circle stops spinning, nothing happens. Some units boot on second attempt, others are completely bricked.

Root cause: Audio hardware initialization timeout during POST. Per HP insider bootfail_cause: it's a "silicon lottery" — slightly faster hardware expects faster response times, and the BIOS timeout is too tight for some units. Explains why some machines are affected and others aren't.

HP force-pushed the broken BIOS as a "Critical" update via Windows Update — automatically, without consent. Multiple users report machines bricked overnight.

Affected Models

Model	Broken BIOS	Working Fallback	Fix
EliteBook X G1a	01.03.11, 01.05.00	01.02.05	01.05.01 (sp170213) ✅
ZBook Ultra G1a	01.04.03, 01.04.05	01.03.11	Pending — fix not yet merged

Workarounds

1. Network BIOS downgrade — Enter BIOS → Update via Network → downgrade step-by-step (01.04.05 → 01.04.03 → 01.03.11). Requires HP USB-C to Ethernet dongle — other brands may not be recognized by BIOS. WiFi option doesn't work.
2. CMOS drain + Win+V — Hold power button 30 sec (fans ramp up twice), then hold Win+V during boot ~15 sec. Temporary workaround to get into Windows.
3. Lock BIOS version — After downgrading, disable "Let OS update the BIOS" in BIOS settings.
4. USB media downgrade — sp165722.exe (01.03.02) available on HP FTP, but 01.03.02 causes kernel crashes for some. 01.03.11 is the "gold" fallback but only via network.
5. Secure Boot corruption — Some users found Windows CA certs unchecked after the freeze. Re-enabling got them booting.
6. BIOS 01.05.01 — Fixes EliteBook. Available at ftp.hp.com/pub/softpaq/sp170001-170500/sp170213.exe. Minor audio crackling on boot reported by some.

Linux BIOS Update Method (No Windows Needed)

• Run Windows .exe in Wine to extract firmware files
• Copy to /boot/efi/EFI/HP/DEVFW/firmware.bin
• Reboot → enter BIOS → "Update System Firmware" → select local media
• First attempt after EFI partition change may hang (fans at full speed) — power off/on, retry

---

🟠 ISSUE 2: Fan Spikes / Constant On-Off Cycling

Original bug (BIOS 01.03.00+): Fans spike to 100% RPM for a few seconds then stop, even on idle.

Partial fix (BIOS 01.04.03+): Fans no longer hit 100%, but now constant on/off cycling at low RPM — off → low rpm → off → low rpm, many times per minute. Motor clicks audible each time. Worsens fan longevity.

BIOS workaround: Set fan curve to 10/15 in BIOS to keep fans always-on at low speed. On AC, there's an explicit "always on" option. No equivalent option on battery.

C-State hypothesis (Level1Techs): HP's BIOS triggers fans when CPU exits deep C-states (C2/C3). Disabling C2/C3 with cpupower idle-set reduces spin-ups but increases power consumption.

YouTube background hack: Playing a YouTube video in Firefox in the background (even muted) keeps fans stable — power goes from 3W to 4W but the fan on/off loop doesn't trigger.

---

🟠 ISSUE 3: AiMT BIOS Setting Bricks the Laptop

In BIOS 1.04.03, enabling the AiMT setting causes a hard brick. Unknown what it does. Recovery: hold power 20 sec until caps lock blinks, boot, spam F10 to enter BIOS and disable it.

---

🟡 ISSUE 4: Third-Party Chargers / Dock Disconnects

Third-party chargers keep disconnecting and losing power at random times. HP Ultra G6 dock had similar issues — partially resolved in newer BIOS. One user confirmed updating the G6 dock firmware resolved their power delivery issues.

---

🟡 ISSUE 5: BSODs (Separate from Boot Freeze)

Daily BSODs with different error codes each time, starting from day 1. Affects 128GB models primarily. HP pulled a February BIOS that was supposed to fix this, then re-released it. Some users had to return units entirely.

---

🟡 ISSUE 6: QC / Hardware Defects

• Right fan bearing defect — noticeable grinding/clicking noise from right fan on some units, present from first boot. Replacement fans out of stock.
• Terrible assembly and QC — multiple users returned units for physical defects
• Biased toward Hynix RAM — Every user who reported the boot freeze also had Hynix RAM (not Samsung). May correlate with the "silicon lottery."

---

🟢 Power & Thermal Data

• APU idle: ~3W, total system idle ~10W (screen + 128GB RAM consume their share)
• CPU max: 70W sustained, brief 80W bursts, drops to 55W after extended load
• GPU max: 110-120W in high performance mode (echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level)
• Battery life: ~7-8 hours light work, ~5% battery per hour at minimal use
• External monitors (3x 1440p + internal): 7-15W average
• Vapour chamber cooling keeps palmrest cool; good thermal management overall
• PTM7950 thermal pad swap yields 8-10°C improvement (confirmed by multiple Level1Techs users)

---

🔵 Linux-Specific Notes

• amd_iommu=off breaks deep sleep on kernels 6.18.18+
• AC wakeup trigger causes immediate wake — fix: echo disabled > /sys/devices/platform/ACPI0003:00/power_supply/AC/power/wakeup
• System freezes for 1-2 sec on battery with kernel 6.19 (fixed in 6.19.8)
• Fans spinning during sleep (20-30% battery drain overnight) — fixed in kernel 6.19.8
• GNOME/Wayland stutters in video playback on Debian stable — KDE and Xorg work fine
• Long BIOS POST times fixed by draining battery to 0% (full charge/discharge cycle)
• Webcam driver patches progressing: amd_capture renamed to amd_isp4_capture (github.com/jtsiros/amd-isp4-camera)

---

💀 HP's Response

• Forum threads marked "Solved" prematurely
• Support offers: "reinstall Windows," "send it in"
• 2-month depot repair to replace motherboards — for a firmware issue HP caused
• HP deleted original bug report threads from their forum
• Quietly removed "Critical" tag from broken BIOS, quietly made older versions available
• No official fix for ZBook yet — only EliteBook got 01.05.01
• Users filing BBB complaints, contacting Tom's Hardware/The Register
• HP has a documented multi-year pattern: 2021 Victus F.10, 2023 TG01 Desktop, 2024 ProBook/EliteBook 01.17, 2025 EliteBook, 2026 ZBook — all identical bricking via firmware update
• 2024 ProBook incident only resolved after Tom's Hardware and The Register coverage

---

Sources

1. HP Forum: URGENT ZBook Ultra G1a BIOS 01.04.05 causing boot freeze
2. Reddit: ZBook Ultra G1a first-attempt boot freeze
3. Reddit: ZBook Ultra G1a fan spike issue
4. HP Forum: EliteBook X G1a BIOS upgrade stuck circle boot
5. Level1Techs: Arch SecureBoot Guide for Ryzen AI Max (HP G1a)

Cool guide! Just a minor note:

Run Windows .exe in Wine to extract firmware files

You may run 7z x to extract the firmware files from the .exe binary. No need to run it or install wine.

I've had the Zbook Ultra G1a 395 with 64GB since 2026-01-30, so it's been 6 months. After the first RC of kernel 6.19, I stopped having hardware issues. I installed CachyOS following a Level1Techs tutorial (linked here) to enable Secure Boot, DKMS, and signing on updates.

Current issues:

1. I had to patch the Wi-Fi firmware to report the correct power (20W instead of 3W in max power mode). Everything works fine up to kernel 7.1.3, but with the 7.2 RC kernel, my Wi-Fi adapter doesn’t show up at all. Without the patch, it works but loses signal frequently. This is linux/mediatek related issue, not HP.

2. For some unknown reason, or since this laptop was originally the “Ubuntu” version, the Pluton security was disabled by default. This caused many TPM-related issues and prevented the laptop from entering deep sleep, resulting in about 7-11W power consumption during sleep. After adding some boot flags, I optimized this down to 3W (measured with a USB-C power meter). Finally, after weeks of debugging, I enabled Pluton, reducing sleep power consumption to 0-1W.

3. The laptop is not compatible with Thunderbolt 4 displays. I use a Dell U4025QW (140W PD), which disconnects randomly—sometimes stable for 2 hours, then disconnecting 4 times within 10 seconds. The journal logs indicate DP resync issues. I’ve tried disabling all power-saving features and Thunderbolt 4 in BIOS, but nothing helps. Dell blames HP; HP blames Dell. I borrowed a Dell TB4 dock: it doesn’t disconnect entirely (USB devices and ethernet remain stable), but HDMI and DisplayPort both disconnect randomly in the same way. This is very frustrating. At work, I use an older Dell U4320Q with 65W PD and DP-alt mode only, which works perfectly fine without external power (the laptop rarely uses more than 55W under normal workloads).

Lastly, I'd add that the actual power consumption from the cable is about 9–13W with the lid closed and not sleeping. With the display on at 40% brightness, I measured between 15–22W. Even light work pushes it to 35W, but I rarely exceed 55W on average. Depending on the adapter, it can go up to 133W, but that's very rare.

3. The laptop is not compatible with Thunderbolt 4 displays. I use a Dell U4025QW (140W PD), which disconnects randomly—sometimes stable for 2 hours, then disconnecting 4 times within 10 seconds. The journal logs indicate DP resync issues. I’ve tried disabling all power-saving features and Thunderbolt 4 in BIOS, but nothing helps. Dell blames HP; HP blames Dell. I borrowed a Dell TB4 dock: it doesn’t disconnect entirely (USB devices and ethernet remain stable), but HDMI and DisplayPort both disconnect randomly in the same way. This is very frustrating. At work, I use an older Dell U4320Q with 65W PD and DP-alt mode only, which works perfectly fine without external power (the laptop rarely uses more than 55W under normal workloads).

You need to use a more powerful dock that has enough budget for the laptop too. E.g. I have a HP Thunderbolt 4 Ultra G6 280w dock that works perfectly, I think the 180w version works too.

BTW if you are still on linux, I have some specific setup that I have done for my machine on another gist.

The laptop uses a 140W PD charger. The Dell display supports 140W PD and can deliver 140W because my other laptop, a Lenovo Yoga, which also supports 140W PD, works perfectly fine. Lenovo isn't Dell, so this is somewhat surprising, but it shouldn't be—if every manufacturer followed the PD 3.1 specification, it would be compatible. The TB4 dock supports only 96W for non-Dell systems, but that's not the issue. Even with the original adapter connected, nothing changes. If it were a power issue, why does the 65W non-TB4 display work perfectly fine on the balanced power plan?

I started a thread about it on freedesktop.org but that's probably dead and I have no more relevant info or successful ending so ...

[22:32:28] usb 5-1: USB disconnect, device number 10
[22:32:28] usb 5-1.4: USB disconnect, device number 11
[22:32:28] usb 5-1.4.1: USB disconnect, device number 12
[22:32:28] usb 5-1.4.1.1: USB disconnect, device number 15
[22:32:28] thunderbolt 0-0:2.1: retimer disconnected
[22:32:28] amdgpu 0000:c3:00.0: amdgpu: [drm] DMUB HPD IRQ callback: link_index=6
[22:32:28] thunderbolt 0-2:1.1: retimer disconnected
[22:32:28] thunderbolt 0-2: device disconnected
[22:32:28] pcieport 0000:01:00.0: Unable to change power state from D0 to D3hot, device inaccessible
[22:32:28] usb 6-1: USB disconnect, device number 7
[22:32:28] usb 6-1.4: USB disconnect, device number 8
[22:32:28] usb 6-1.4.1: USB disconnect, device number 9
[22:32:28] usb 6-1.4.2: USB disconnect, device number 10
[22:32:28] r8152-cfgselector 6-1.4.3: USB disconnect, device number 11
[22:32:28] usb 5-1.4.1.3: USB disconnect, device number 16
[22:32:28] usb 5-1.4.1.4: USB disconnect, device number 17
[22:32:28] usb 5-1.4.1.5: USB disconnect, device number 18
[22:32:28] usb 5-1.4.2: USB disconnect, device number 13
[22:32:28] usb 5-1.4.2.4: USB disconnect, device number 14
[22:32:32] thunderbolt 0-2: new device found, vendor=0xd4 device=0xc041
[22:32:32] thunderbolt 0-2: Dell U4025QW
[22:32:32] thunderbolt 0-0:2.1: new retimer found, vendor=0x1da0 device=0x8835
[22:32:33] thunderbolt 0-2:1.1: new retimer found, vendor=0x1da0 device=0x8835
[22:32:33] amdgpu 0000:c3:00.0: amdgpu: [drm] DMUB HPD IRQ callback: link_index=6
[22:32:33] pcieport 0000:00:01.1:   bridge window [mem 0xbc000000-0xd3ffffff]

Asus Z13 doesn't have this issue with U3225QE, which is also TB4 and the same Strix Halo base..

Adding a data point for 01.05.07 on a ZBook Ultra G1a 14, and two findings that may be new to this list.

1. 01.05.07 silently bumps the USB4® Retimer from 2.2.0.12 to 2.2.0.14. It is not mentioned in the History.txt shipped with SoftPaq sp172978 — those notes list GOP, PSP, SMU, EC, PXE ROM and TI PD, but not the retimer. It only appears in HpFirmwareUpdRec.log, under FlashConfirmPage::OnSetActive. Worth checking your own log if you are tracking what these updates actually change.

2. Downgrading below 01.05.07 is refused by the platform. I tried going back to 01.03.11 (sp163324). BIOS Rollback Policy is Unrestricted, Lock BIOS Version has to be disabled first (otherwise the button is greyed out and the log says BIOS update blocked by system BIOS setting, exit 1602), and with that done the staging succeeds — exit 3010, "Update will occur on restart". But on restart the firmware refuses it and boots straight through: 80 seconds from shutdown to desktop, BIOS unchanged. My assumption is the AMD PSP anti-rollback level, which reads 2 against a factory value of 1. 01.03.11 carries PSP FW 0.40.0.61 versus 0.40.1.65 in 01.05.07. An earlier rollback in April from 01.04.05 to 01.03.11 did work — both were inside the 0.40.0 line then.

My actual problem: since the update this machine can no longer be powered by an 85 W USB-C monitor. Under CPU load the PD contract collapses and re-negotiates every 1–2 seconds, taking the DP link down with it. Measured in Kernel-Power id 105: 0–1 transitions per day before the update, 7–25 per day after, same monitor and cable, and 24 transitions in a 45-second load test. HP's own charger is perfectly stable, and two other USB-C monitors (HP Z27u G3, Dell U2722DE) are fine as sole power source — the one that fails is the one with the smallest budget.

Anyone else seeing USB-C monitor charging get unreliable after 01.04.03 / 01.04.05 / 01.05.07, especially with a 60–90 W monitor? And did anyone get a downgrade past the PSP anti-rollback?

My update to this:

1. @tylerebowers I checked your config, but nothing helpful for my setup (CachyOS, Lemonade on Vulkan), I had my own fix for mediatek, fixed it for 7.2 and 7.3RC has the fix implemented, I get 23db TX on it.
2. @cevanloon-ux I'm running it daily for 8+ hours (mostly 10) at work on mentioned U4320Q, zero issues at all. On U4025QW I'm still getting DP disconnects.

I need to correct the statement, U4320Q has 90W PD, not 65W PD. Also I bought a better USB-C meter for a project and tried it on the laptop. On original adapter, it's 27.5V / <1A idle, so 24-26W, not 15-22W. On light work it's under 45W, on Claude Code with Qwen model running in Lemonade/Vulkan it takes 105W maximum from the original adapter. Compiling and other standard work takes maximum 95W, so 100W adapter is just fine for portability (Choetec 30x30x45mm) and as I sait multiple times, 90W PD is enough for most jobs. I really don't believe the issue in DP is caused by insufficient power.

Thunderbolt is a major factor. I'm having the most trouble with my LG 34WK95U-W (Thunderbolt 3 minimum requirement). Before the update, I was able to run without additional power since the first day I got the laptop. Since the update, disconnects until I connect an additional power supply (100W+ PD). Then it's stable.

Anecdotal, but I had some intermittent ThunderBolt display dropout (it's actually dual-link SST display), where the display would go black and all connected peripherals would disconnect.

Adding thunderbolt.clx=0 to my kernel flags seemed to help, as it prevents supported high-speed links from entering their CLx power-saving states while idle. Unsure if this would affect the actual link that charges the computer from the display, as I have my OEM charger connected most of the time, but worth a try.

You were right, and it took two settings on Windows to get what thunderbolt.clx=0 gives you on Linux.

USB selective suspend off fixed the failure under load — 24 PD transitions in a 45 s all-core test went to 0, cores at 100 %.

PSPP (PCIe Speed Power Policy) = Disabled in the HP BIOS fixed the failure at boot, which the Windows setting could not touch. Cold boot with the cable attached went from 17 display enumerations to 2. Settable without entering F10:

$i = Get-CimInstance -Namespace root\HP\InstrumentedBIOS -ClassName HP_BIOSSettingInterface
Invoke-CimMethod -InputObject $i -MethodName SetBIOSSetting -Arguments @{Name='PSPP (PCIe Speed Power Policy)'; Value='Disabled'; Password=''}

So on this platform it's two separate mechanisms — OS-side USB suspend and firmware-side PCIe speed policy — and each covers a different half. Thanks for the pointer; I'd written it off because my failure was load-correlated rather than idle-correlated, and that was the wrong call.

new BIOS out ! 01.06.02 released on 2026-09-10 yet the timestam says 2026-08-26

EC (embedded controller): 35.34.00 -> 35.36.00

The disconnects are still present for me. Currently on kernel 7.3.0RC1 which is generally very stable for me. I tried to apply tb clx=0 again, I first thought it helped as instead of full TB teardown I only had DP disconnects and the TB hub was alive.

In logs, I have a lot of restarts (or better said, switching between awake and sleep) of PCIe controller in the display itself, so I'm really starting to believe the issue is both HP and Dell. I added an udev rule to disable PCIe sleep, will see in a few days how helpful it is.

@morvy — thanks for testing 01.06.02 so quickly. Before I follow you onto it, two things.

First, a correction to my earlier post. I reported that setting PSPP (PCIe Speed Power Policy) = Disabled took a cold boot from 17 display enumerations to 2. That was a measurement artefact on my side: I read the counter before its 4-minute window had filled. The real figure for that boot was 5, and every boot since has still cycled — 5, 44, 14, 17. PSPP did not fix the boot-time failure for me.

What does hold up: disabling USB selective suspend in Windows reliably fixes the failure under load. A 90-second all-core test with the monitor as sole power source went from 24 PD transitions to 0, with cores at 100 %. It does nothing for the boot-time failure.

Second, and the reason I'm asking: I don't think we have the same hardware, and possibly not the same bug.

You and most others here seem to be on Dell monitors. Mine is an LG 34WK95U — 34", 5120×2160, Thunderbolt 3, and only 85 W of USB-C PD. So it's a tunnelled DisplayPort link rather than plain DP Alt Mode, and the smallest power budget I've measured on this machine.

On mine there are clearly two distinct failures:

1. Under load while running — PD contract collapses and re-negotiates every 1–2 seconds, screen flickers, battery drains while Windows says "plugged in". Fixed by disabling USB selective suspend.
2. At boot with the cable already attached — continuous cycling, no picture. Unplug and replug after Windows loads, and it's fine. Nothing I've tried fixes this one.

So when you say the disconnects are still present on 01.06.02 — which of those two is it for you? And which monitor, and what's its PD rating?

If yours is #2 and it survived the update, that saves me the exercise. If yours is #1, we may be chasing different things.

If anyone wants to give comparable numbers instead of impressions, this counts display re-enumerations per hour and needs no admin:

Get-WinEvent -FilterHashtable @{LogName="System";ProviderName="Microsoft-Windows-USB-USB4DeviceRouter-EventLogs";StartTime=(Get-Date).AddDays(-14)} |
  Group-Object { $_.TimeCreated.ToString("MM-dd HH") } | Sort-Object Name

One or two enumerations shortly after a boot is normal. Mine currently shows 11 of 20 boots cycling, highest count 44, on 01.05.07 with EC 35.34.00.

My plan: I'm deliberately not updating yet. At 11 in 20 this is close to a coin flip per boot, so a handful of boots either way proves nothing. I'm collecting a few more days of baseline this week, then installing 01.06.02 next week, then running the same count over a comparable number of boots. I'll post both tables side by side when I'm done, so there's an actual before/after instead of a feeling.

@cevanloon-ux I'm experiencing disconnects while normally using the laptop on U4025WQ only. This one is 140W PD. It's been about an hour since I disabled the power saving on PCIe in the display, zero transitions since and zero flashes too (knock knock?). This is a TB4 display. Due to those disconnects I was really not motivated to use that superexpensive monitor and I only used it on my old Lenovo Legion 5 Pro where I have no issues (and Lenovo doesn't have TB, supports 100W PD).

At work, where I spend at least 8 hours connected to U4320Q I have zero disconnects. Never had, since first day it was perfectly stable. This one is not TB, it's standard USB-C 90W PD with DP Alt Mode and that's why I believe it's stable. HP U32 4K (only 65W PD) is perfectly stable as well. So I only have issues when connected to TB4 display and doesn't matter what wattage or cable (tried on 100W PD TB4 and WD22TB4 dock too).

I also experienced those super slow boots you mention and they were all somehow connected to the Pluton processor, which when disabled, also prevents deep sleep as TPM is not working. I was fighting with them too, also turning off the laptop when the display was connected resulted in 5 minutes of waiting.

PS: updating to the latest BIOS did not work via USB, it went through all 8 stages very quickly and then said it's updating firmware but nothing was flashed. But when I kept the display connected with ethernet, I used the HP.com online search in the BIOS itself and that flashed on first try.

Follow-up as promised: 01.06.02 does not fix the boot-time failure here either. I said I'd post before/after tables instead of an impression, so here they are — plus a better way to test this than I was using, and one correction that matters.

@morvy — this lines up with what you're seeing, from the Windows side.

It looked random because I wasn't controlling the one thing that matters — whether the cable is attached at POST:

Cable already in when you press power → fails, essentially every time.
Cable out at POST, plugged in during the Windows loading animation → clean, every time.
Control for that and the failure is deterministic, so three boots are enough to conclude something. Worth stating which of the two you did when posting numbers.

Before / after, same condition (cable attached from the power button)

Firmware Boots tested Cycling
01.05.07 · EC 35.34.00 · retimer 2.2.0.12 7 7
01.06.02 · EC 35.36.00 · retimer 2.2.0.14 3 3

Counts within 4 minutes of POST — USB4DeviceRouter id 1 enumerations, and Kernel-Power id 105 power-source transitions, which is the one that tracks visible flickering:

01.05.07                        01.06.02
  enum  PD                        enum  PD
    14  31                          18  26
    17  22                          48  68   <- worst boot I have on record
    23  34                          17  32
    30  36
    17  32
    27  38
    44  64  (resume, not cold)
control, same machine, same day: cable plugged in during the loading animation
     4   0

No improvement, and the single worst boot in my whole dataset is after the update (I'm on Windows 11 Pro 26200)

That this reproduces identically on Windows and on your kernels is, I think, the most useful thing in this post. Different OS, different connection manager, different power-management stack, same failure on Thunderbolt displays and same absence on DP Alt Mode ones. That points at firmware rather than at either OS. It means thunderbolt.clx=0, your PCIe-power-saving change and my USB selective suspend are probably three doors into the same room: link power-state management.

Also confirming your update tip: 01.06.02 via HP.com's online search from inside the BIOS worked first time here too (F10 → Update System BIOS → network).

The retimer: flash logs lie
I posted earlier that 01.05.07 silently bumps the USB4® Retimer 2.2.0.12 → 2.2.0.14, based on HpFirmwareUpdRec.log, which does say exactly that:

Firmware update found for: USB4(R) Retimer
  Current Version Feature/Major/Minor/Build: 2 / 2 / 0 / 12
  New     Version Feature/Major/Minor/Build: 2 / 2 / 0 / 14

It never applied it. For the twelve days afterwards, across dozens of boots, HP_BIOSSetting kept reporting USB4(R) Retimer FW : 02.02.00.12. It only flipped to 02.02.00.14 after I installed 01.06.02 from inside the BIOS.

So HpFirmwareUpdRec reports success for a sub-component it didn't flash. If you're tracking what these updates actually change, read the version rather than the log:

# needs admin
Get-CimInstance -Namespace root\HP\InstrumentedBIOS -ClassName HP_BIOSSetting |
  Where-Object { $_.Name -match 'Retimer FW|Type-C Controller' } |
  ForEach-Object { '{0} : {1}' -f $_.Name, $_.Value }

And it clears the retimer as a suspect: it's demonstrably at 2.2.0.14 now and the failure is unchanged. Same for the EC, which has moved twice (35.2F.00 → 35.34.00 → 35.36.00) to no effect.

Entering the network updater for BIOS update, it offered "Rollback to 01.04.05" as the only downgrade target. This is one of the versions causing the boot freeze at the HP logo. Anyone reaching for that button as an escape from 01.05.07/01.06.02 should know what's being offered.

My last known-good, 01.03.11, is refused directly: AMD PSP FW Anti Rollback Security Level reads 2 against a factory level of 1. The step-down route described above (01.04.05 → 01.04.03 → 01.03.11) presumably still works, but both intermediate stops are freeze versions, so I'm not taking that bet.

What actually helps on Windows, measured

1. At boot: don't have the cable attached at POST. Power on without it, plug in during the loading animation. 0 PD transitions, every time. One second of patience per boot.
2. Already flickering? Unplug for at least 30 seconds, then back in. 11 seconds was too short; 31 worked.
3. Under CPU load: disable USB selective suspend. A 90-second all-core test with the monitor as sole power source went from 24 PD transitions to 0. Does nothing for the boot case.
4. Tested and useless here, so nobody has to repeat it: Pre-boot DMA Protection = Disable (3 of 3 boots still cycled), PSPP (my earlier claim about that was a measurement error, corrected above in the thread), PCIe ASPM off, Fast Startup off, and the monitor's DisplayPort version set to 1.4.

The firmware brings the Thunderbolt link up itself during POST. That's why the monitor shows the BIOS menu fine. The OS connection manager then has to take over that firmware-established link, and that handover is what breaks. With no cable at POST the firmware never touches it, the OS negotiates from scratch, and it's clean.

That fits replugging working, a short unplug not being enough, and resumes being erratic. It also fits there being no fix in setup: the full settings list on this machine (290 entries) contains no pre-boot Thunderbolt or USB4 option at all.

Glad to be told I'm wrong about the mechanism. The numbers hold either way, and anyone can generate a comparable table in one line:

Get-WinEvent -FilterHashtable @{LogName="System";ProviderName="Microsoft-Windows-USB-USB4DeviceRouter-EventLogs";StartTime=(Get-Date).AddDays(-14)} |
  Group-Object { $_.TimeCreated.ToString("MM-dd HH") } | Sort-Object Name

Hello guys, I am also owner this great laptop and sometimes piece of crap... bitter sweet relationship. I have different fault than the boot freeze, but the same platform. Two system board replacements did not fix it. I post the raw numbers here because this thread has people who measure instead of guess.

Machine

Model        HP ZBook Ultra G1a 14 inch Mobile Workstation PC, SKU C84CJES#BCM
CPU          AMD Ryzen AI Max+ 395 w/ Radeon 8060S, 16C/32T
RAM          64 GB LPDDR5X 8000, Samsung K3KL9L90EM-MGCU x8 (4 GB reserved for iGPU in BIOS)
SSD          WD PC SN8000S 2 TB, fw HPS1N8A
OS           Windows 11 Enterprise 25H2, build 26200.9457 (two clean installs, MS image and HP Cloud Recovery)
GPU driver   32.0.31041.1004 (2026-08-17), drivers only from HP Support Assistant, WU driver delivery off
BIOS         X89 01.05.07 (2026-05-05), EC 53.52, KBC 35.34.00, USB4 Retimer FW 02.02.00.14
Type-C PD    TPS66994E 8.3.0, TPS66993E 7.3.0
PSP          Anti Rollback Security Level 2, factory level 1 (same as cevanloon-ux, downgrade is refused)
Hyper-V      on, one VM running 24/7 (8 vCPU, 16 GB), VBS on, Secure Boot on
BIOS setup   factory defaults, 273 settings, full dump kept. Only two values I ever touched: Dedicated Graphics Memory 4 GB, Secure Boot on (it came disabled on the replacement boards, I turned it back on)
Bought       February 2026, HWM onsite warranty, elevated stand, never throttled

Fault 1: instant power off at idle

The machine suddently dies in one moment. Screen black, no BSOD, no error, nothing in any log before it. Like you would take out powercord from outlet. Windows writes Kernel-Power 41 with BugcheckCode 0, PowerButton false, WHEA 0. Uptime before death is anything from 20min to 8 days. It never happened under load. I run 105 to 130 W for hours with a VM and 30 client load tests. It dies when nobody touches it, often at night.

Two crashes in the whole history produced a dump. Both are watchdog timeouts:

2026-08-08 22:55   0x133 DPC_WATCHDOG_VIOLATION
2026-08-23         0x101 CLOCK_WATCHDOG_TIMEOUT, core 6

Count of Kernel-Power 41 events since first boot, by month:

2026-03   6
2026-04   2
2026-05   4
2026-06  11
2026-07  14
2026-08  29
2026-09   6   (3 on 2nd board on 1 Sep, 2 are technician power offs on 8 Sep, none for now on 3rd board)
total    72

Longest quiet periods on 1st board were 9, 11,5, 13 and 17 days. So a quiet week proves nothing on this machine.
There is probably also vacation period there so there is bias in this data.

Fault 2: micro freezes during video

Since about August the machine has short freezes during YouTube playback. Picture and sound stop for a fraction of a second. Same on all three boards. Today I caught two of them with a circular kernel trace (wpr, DPC/ISR/Interrupt keywords, 128 MB memory buffer, saved when a high priority thread pinned to core 0 measures a scheduling gap above 100 ms).

Both freezes are a DPC and ISR storm on core 0, 130 to 150 ms long. Nothing in the OS logs at that time.

freeze 1 (14:55:56)   core 0, longest items in the 150 ms window
  DPC  ntoskrnl.exe    4985 us
  DPC  ACPI.sys        2859 us
  DPC  amdkmdag.sys    2431 us, 2287 us, 1942 us
  ISR  dxgkrnl.sys     1807 us, 1739 us, 1727 us   (normal on this machine: 29 us)
  DPC  ntoskrnl.exe    1500 to 2800 us at the same time on cores 1, 2, 9, 10, 11, 14, 15
  333 DPC/ISR above 300 us, 52 above 1 ms, all inside this one window

freeze 2 (14:59:21)   core 0
  DPC  dxgkrnl.sys     6653 us
  DPC  amdkmdag.sys    4775 us, 3083 us
  DPC  Wdf01000.sys    4548 us, 3894 us, 3360 us, 3127 us
  DPC  ntoskrnl.exe    3969 us, 3581 us, 3148 us
  337 above 300 us, 77 above 1 ms

quiet 45 s baseline (9 Sep, board 3)
  core 0 spends 6.0 % of time in DPC+ISR, every other core under 0.2 %
  DPC amdkmdag.sys  31426x  960 ms  avg 30.6 us  max 394 us
  ISR dxgkrnl.sys   30912x  895 ms  avg 29.0 us  max 327 us
  DPC Wdf01000.sys   6598x  395 ms  avg 59.8 us  max 796 us
  18 DPC above 500 us in 45 s

My reading: the freeze is the same mechanism as the two dumps, only shorter. GPU interrupts take 50 times longer than normal for 150 ms, ACPI is in the middle of it, and all cores get long kernel DPCs at once. That is platform, not an app.

Fault 3: USB-C display and PD drops

Same class as morvy and cevanloon-ux report. Monitor Philips 40B1U5600 (5K2K, USB-C, 96 W PD, DP Alt Mode, TB5 80 Gbps cable).
Second PD source on the other port, 140 W (HP original or Ecoflow 320 W desk charger, same behavior).

Event pattern, all within 1 s, everything back after about 3 s:
  Kernel-PnP 1010   DISPLAY\PHL0990 surprise removed
  Kernel-PnP 1010   USB\VID_2109 hub in the monitor surprise removed
  Kernel-PnP 1010   audio endpoint surprise removed
  Kernel-Power 105  power source change

Since 2026-03-11:  202 DISPLAY surprise removals, 233 spontaneous power source change pairs
Boards:            all three
Correlation with the power offs: 4 of 72 deaths had a drop in the 10 min before. Not the trigger.

Kernel-Power 105 per day, last 14 days (2nd board then 3rd board):
  09-03 2   09-05 116   09-06 10   09-07 340   09-08 16   09-09 26   09-11 8   09-16 8

Port test: monitor moved to the left USB4 port, same cable, 7,5 h: 0 drops.
           Back on the left USB-C 10 Gbps port: 4 drops in 72 h.
Today:     10:58:13 monitor plus hub dropped and AcOnline went false at the same second.
           11:15:33 AcOnline false for 5 s, nobody touched a cable.

Notes for this thread: 3rd board shipped with retimer 02.02.00.14 already, on BIOS 01.05.07 and EC 35.34.00.
USB4DeviceRouter has no events there, the monitor is DP Alt Mode, not a tunnel.
USB selective suspend and PSPP are at defaults. I did not change them yet because I keep the machine clean for the warranty case.

Timeline

2026-02-26  bought, BIOS 01.02.x
2026-03-14  first Kernel-Power 41
2026-04..07 2, 4, 11, 14 per month, BIOS 01.05.07 from May
2026-08-08  0x133 DPC_WATCHDOG_VIOLATION
2026-08-16  HP UEFI diagnostics: CPU, memory, system board, AC adapter, SMART long DST, 1800 s CPU stress: all PASS
2026-08-16  BIOS 01.06.01 offered only inside HP PC Hardware Diagnostics for Windows 3.1.1.0, not on the support page, no changelog. Installed. 17 deaths in the next 9 days.
2026-08-23  0x101 CLOCK_WATCHDOG_TIMEOUT
2026-08-24  HP case, onsite
2026-08-25  2nd board, bare board only, technician moved the old crumbling thermal pads. BIOS 01.05.07 kept on purpose.
2026-09-01  3 deaths on 2nd board, all idle. HP had closed the case on 27 Aug. New case, escalation.
2026-09-08  3rd board, bare board again, paste instead of pads. Identical part: product 8D01, KBC 35.34.00, BIOS 01.05.07, EC 53.52, same CPU stepping, same RAM part, 0 differences in firmware resources.
2026-09-09  DPC baseline trace, 6 % of core 0 in DPC+ISR at idle
2026-09-16  3rd board: 0 deaths in 8 days, micro freezes still present, 2 captured in traces

What is ruled out

OS              two clean installs
Drivers         HP only
BIOS            fault present on 01.02, 01.05.07, 01.06.01
BIOS settings   factory defaults except iGPU memory 4 GB and Secure Boot on, full dump kept
Board           three boards of the same design
Power           HP 140 W, measured with a PD meter, 136 W peak. One death on battery.
Thermal         idle 48 C, 16 threads 66 C, cool down to 51 C in 2 min after 3rd board. Readings before every death are nothing special.
Load            never under load. 1800 s UEFI stress PASS. 1344 cycles of idle/burst C-state churn: nothing.
PD replug       13 manual hotplugs of monitor plus adapter: nothing.
PMF thrash      amdpmfservice resets the power policy thousands of times a day on every source change. 0 events in the 5 min before 18 of 20 monitored deaths. Not the trigger.

Questions

1. Does anyone see the same power off with BugcheckCode 0 at idle on 01.06.02?
2. Does anyone have a DPC trace of a video micro freeze on this machine? Same amdkmdag plus dxgkrnl plus ACPI pattern?
3. Did anyone get HP to do more than swap the same board part number?

HP release notes for 01.04.05 (sp170065) say: fixes an intermittent issue where Windows crashes with multiple stop codes when the system is idle. My case is on 01.05.07 and later, so that fix did not cover it.

I can share the monitoring scripts (PowerShell, 10 s hardware blackbox with 7 thermal zones and core 0 DPC rate, the freeze catcher with circular wpr trace, the trace parser). If anyone would find it useful.