Core Ultra 9 275HX laptop: 0x3B/0x1E/0x0A BSODs always on the same E-core, #GP on valid addresses, no WHEA (Windows 11 26H2, 26300)

Question

Core Ultra 9 275HX laptop: 0x3B/0x1E/0x0A BSODs always on the same E-core, #GP on valid addresses, no WHEA (Windows 11 26H2, 26300)

pleshw 20

I have the same problem described in Recurring 0x1E bugcheck in nt!ExpPoolTrackerChargeEntry, now on Windows 11 26H2, with dump evidence that points to the CPU and not to a driver. I am opening a separate question so the data and the cross-references with Intel and Acer stay in one place.

System

Acer Predator Helios Neo 16 AI (PHN16-73), Intel Core Ultra 9 275HX (microcode 0x11B), 24 logical processors
BIOS Insyde V1.28 (installed by Windows Update on 03 Oct 2026; V1.26 before)
Windows 11 Home 26H2, build 26300 (upgraded from 25H2 on 29 Sep 2026)

Symptoms

17 BSODs since 23 May 2026, the latest on 03 Nov (two) and 04 Nov. About 10 black-screen hangs that needed a long power-button press (LiveKernelEvent 0x1A8/0x1B8) and 14 GPU timeouts.
About 8x more BSODs after 29 Sep to 03 Oct (Windows 26H2 and BIOS 1.28): 6 in 145 days before, 11 in 32 days after.
Codes: 0x3B (11x), 0x1E (2x), 0x50, 0x0A, 0x116, 0x133. Crashes happen while gaming, idle, and as early as 58 s after boot.

What the 11 minidumps show (WinDbg)

All 10 dumps with a computation or pointer error ran on logical CPU 15 (an E-core) out of 24. The chance of that by luck is about 1 in 2.6 trillion. The 11th (0x133) is a spinlock wait on CPU 13.
Two faulting addresses are valid addresses with exactly one bit flipped (bits 42 and 46).
0x0A in nt!KiCommitThreadWait: two consecutive instructions read rcx with nothing writing it in between; the second read saw one bit flipped.
7 x 0x3B: a read succeeded and the very next read on the same page, at a valid canonical address, raised #GP. This happened in nt!CmpCheckLexicographicalOrder (6x) and nt!HvIsCellAllocated, in both user and kernel memory.
No WHEA events at all.
My crashes on 12 Jul, 02 Aug and 07-08 Sep fault at the same nt!ExpPoolTrackerChargeEntry offsets reported in thread 5921413 (...a32a0, ...970b0, ...a22a0).

Software cannot change a register between two consecutive instructions, so I believe this is the same Arrow Lake-HX E-core instability other owners describe, with Windows code as the victim.

What I tried, and what happened

BIOS 1.26 -> 1.28: worse, about 8x more BSODs.
Windows updates up to 26H2 and the monthly CUs: no change (thread 5921413 also reports KB5094135 did not fix it).
Uninstalling Riot Vanguard: a BSOD still happened on 16 Oct with vgk.sys not installed.
VT-x, VT-d, VBS and Memory Integrity: already active on every boot since 14 Aug (Kernel-Boot event 153 shows "VBS Enabled ... Hvci" on all 98 boots); crashes continued. Kernel-mode Hardware-enforced Stack Protection enabled on 04 Nov.
Intel Processor Diagnostic Tool 4.5 (about 4 min): pass (too short to catch an intermittent single-core fault).
Turbo Boost off (Processor performance boost mode = 0) on 04 Nov, after 3 BSODs in about 8 hours: in the first result, heavy compilation and test runs of my game project finished without crashes. Still monitoring. This matches what other owners report in thread 5921413.

Separate issue: TPM attestation (PCR0)

On every boot since 14 Aug (98 boots, BIOS 1.26 and 1.28), TPM-WMI Event 1041 reports PcrsMatchTcgLog=false and BitMaskOfPcrMismatches=1 (PCR0), with SoftwarePcrReplayHresult=0 and HardwarePcrReplayHresult=0. TPM, EK/AIK certificates and Secure Boot are fine, but Firmware Protection (System Guard Secure Launch) is configured and never running, and SecureCorePCCompliant=false. Other PHN16-73 owners have the same issue (Acer Community threads 739715, 740933, 743183, 743929). They report that clearing the TPM, restoring the Secure Boot keys, loading BIOS defaults, reinstalling Windows and updating to BIOS 1.28 did not fix it.

Questions

Is Microsoft tracking the nt!ExpPoolTrackerChargeEntry / CmpCheckLexicographicalOrder crashes on Arrow Lake-HX E-cores? Is there a known issue or a Windows-side mitigation, for example in scheduling or power management for E-cores?
Can a Microsoft engineer analyze my minidumps? I can share all 11.
Is Microsoft aware of the PCR0 Measured Boot mismatch on Insyde-based PHN16-73 firmware that breaks Azure Attestation and Secure-core, and is it working with Acer/Insyde on it?

Cross-references (the same case is open with all three companies; I will post each answer in the other cases)

Intel Online Service Center: support request 07002273
Acer: repair request and Acer Community post (I will add the numbers here as soon as they are open)

pleshw 20 Reputation points

2026-11-04T05:44:34.33+00:00

Cross-reference update: the Acer Community discussion is open at https://community.acer.com/pt/discussion/743933 (in Portuguese). Intel Online Service Center support request 07002273 already has a comment pointing to this question. The Acer repair request is not open yet; I will add its number here when it is.
pleshw 20 Reputation points

2026-11-04T16:26:41.7266667+00:00

Update: on 4 Nov 2026 I opened a repair request with Acer Brazil support, asking Acer to assess both the BIOS and the motherboard and referencing Intel case 07002273 and this question. The service order number is in the Intel case, and I can share it with Acer or Microsoft staff on request.

I'll post Acer's findings and the result of the E-core test here.

Answer accepted by question author

TaoLi 119.7K Independent Advisor

Thanks for the dumps. Four crashes occurred on CPU 15, and Vanguard wasn’t loaded in two of them. I’d check CPU/platform stability next, though this doesn’t prove a faulty CPU.

Try temporarily disabling E-cores: restart >> F2 >> F1 if needed >> Advanced >> Active Efficient Cores >> Disabled >> save and restart.

Keep Turbo Boost off and test normal use for 24–48 hours. Performance may be lower during this test.

If it still crashes or freezes, re-enable E-cores and ask Acer to check the CPU/motherboard and BIOS, referencing Intel case 07002273.

pleshw 20 Reputation points

2026-11-04T15:44:31.2633333+00:00

Thanks, TaoLi. I'll run the test you suggested: E-cores disabled in the BIOS (if the PHN16-73 BIOS exposes that option) and Turbo Boost off, for 24-48 hours of normal use. I'll post the result here.

One correction for the record: in the shared dumps, 10 of the 11 crashes ran on CPU 15 (only the 0x133 is on CPU 13), and vgk.sys was not loaded in 3 of them (16 Oct, 01 Nov and 04 Nov).

Intel (case 07002273) also referred me to Acer for a hardware and firmware assessment, so I'm opening a case with Acer support and will add the number here.
TaoLi 119.7K Reputation points Independent Advisor

2026-11-05T13:10:15.55+00:00

I think this is most likely a hardware issue. I look forward to hearing good news from you.

1 additional answer

Your answer

pleshw 20 Reputation points

2026-11-04T05:44:34.33+00:00

Cross-reference update: the Acer Community discussion is open at https://community.acer.com/pt/discussion/743933 (in Portuguese). Intel Online Service Center support request 07002273 already has a comment pointing to this question. The Acer repair request is not open yet; I will add its number here when it is.
pleshw 20 Reputation points

2026-11-04T16:26:41.7266667+00:00

Update: on 4 Nov 2026 I opened a repair request with Acer Brazil support, asking Acer to assess both the BIOS and the motherboard and referencing Intel case 07002273 and this question. The service order number is in the Intel case, and I can share it with Acer or Microsoft staff on request.

I'll post Acer's findings and the result of the E-core test here.
pleshw 20 Reputation points

2026-11-04T15:44:31.2633333+00:00

Thanks, TaoLi. I'll run the test you suggested: E-cores disabled in the BIOS (if the PHN16-73 BIOS exposes that option) and Turbo Boost off, for 24-48 hours of normal use. I'll post the result here.

One correction for the record: in the shared dumps, 10 of the 11 crashes ran on CPU 15 (only the 0x133 is on CPU 13), and vgk.sys was not loaded in 3 of them (16 Oct, 01 Nov and 04 Nov).

Intel (case 07002273) also referred me to Acer for a hardware and firmware assessment, so I'm opening a case with Acer support and will add the number here.
TaoLi 119.7K Reputation points Independent Advisor

2026-11-05T13:10:15.55+00:00

I think this is most likely a hardware issue. I look forward to hearing good news from you.

Answer 1

TaoLi 119.7K Independent Advisor

Hello,

When your computer experiences a "blue screen" (BSOD), we require a file in the .dmp format to analyze and pinpoint the cause of the error. The default location for these "minidump" files is: C:\Windows\Minidump

If this file does not exist on your computer, you will need to adjust a few settings:

Open the Control Panel, then go to System and Security > System > Advanced system settings. Under the "Startup and Recovery" section, click "Settings."

Set "Write debugging information" to "Small memory dump (256 KB)" and ensure the "Small dump directory" is set to %SystemRoot%\Minidump.

After applying these settings, please restart your computer. The next time a blue screen occurs, a new file will be generated. You can then upload this file to OneDrive (or another cloud storage service of your choice) and provide us with a download link.

https://onedrive.live.com

Alternatively, you may use any other cloud storage platform.

pleshw 20

Thanks, TaoLi. Dump settings were already "Small memory dump" (CrashDumpEnabled = 3, %SystemRoot%\Minidump). On this build (26H2, 26300), Windows still writes 10–14 MB minidumps, and they contained personal data: the serial number, e-mail addresses, Wi-Fi names and fragments of application memory. So I made reduced copies:

Re-saved: each dump was re-saved with WinDbg .dump /m.
Trimmed: only the classic small-dump section was kept (context, exception, PRCB, process, thread, stack, driver list and KDDEBUGGER_DATA). The secondary data that drivers append was dropped.
Masked: the serial number and my name/computer name were replaced with X's of the same length.

All 11 open in WinDbg with the same bugcheck, CPU and faulting symbol as the originals, with one exception: in the 0x133, the reduced copy's stack stops at the clock interrupt. The original shows vgk+0x1de165 spinning on a lock. I kept the full originals in case a Microsoft engineer needs them privately.

All 11 minidumps (10 Oct to 04 Nov, 111–247 KB each, plus a README), view-only: https://1drv.ms/u/c/12d694d9a43b7de0/IQA0rs7TDWBST42E62L6x4hvAXfRns27_V41m1okeDtIPqc

File	Date	Bugcheck	CPU	Faulting code
101026-21234-01	10 Oct	0x0A	15	nt!KiCommitThreadWait+0x242
101626-12171-01	16 Oct	0x3B	15	nt!CmpCheckLexicographicalOrder+0xc2
101726-22250-01	17 Oct	0x3B	15	nt!CmpCheckLexicographicalOrder+0xc2
101726-21531-01	17 Oct	0x3B	15	nt!CmpCheckLexicographicalOrder+0xc2
101726-14375-01	17 Oct	0x50	15	vgk.sys
102526-21906-01	25 Oct	0x3B	15	nt!CmpCheckLexicographicalOrder+0xc2
102826-20234-01	28 Oct	0x1E	15	vgk.sys
110126-12812-01	01 Nov	0x3B	15	nt!HvIsCellAllocated+0x51
110326-86812-01	03 Nov	0x133	13	DPC watchdog (vgk.sys waiting on a spinlock)
110326-22187-01	03 Nov	0x3B	15	nt!CmpCheckLexicographicalOrder+0xc2
110426-22218-01	04 Nov	0x3B	15	nt!CmpCheckLexicographicalOrder+0xc2

What they show (details in the question):

Same core: 10 of 10 computation-error crashes are on CPU 15, an E-core. The 0x133 is on CPU 13 and is a different type of failure.
Bit flips: single-bit flips in two pointers (bits 42 and 46).
Changed register: in the 0x0A, a register changed between two consecutive instructions.
#GP on valid addresses: in 7 crashes, a read succeeded and the next read in the same page took a #GP.
No WHEA in any of them.

Update since I posted: Turbo Boost has been off (PERFBOOSTMODE = 0) since shortly after the 04 Nov 00:40 crash. There has been no BSOD since, but at 05:10 (about 4.5 hours later, light load) the laptop froze completely:

No dump: Kernel-Power 41 with BugcheckCode 0, no minidump, no live dump and no WHEA.
Power button: Windows did not react to it.

So Turbo off reduced the failures, but did not stop them.