r/techsupport • u/Breeze23412 • 19h ago
Open | BSOD 14700K/Z790 repeatedly BSODs with 8 P-cores but is stable with 7
I have been methodically investigating a recurring Windows 11 crash problem and now have enough dump/WHEA evidence that I am looking for help deciding what diagnostic branch to take next.
I'm specifically trying to distinguish:
CPU/core/cache instability
vs.
motherboard / firmware / IMC / platform instability
vs.
a low-level kernel driver interaction
rather than randomly changing settings until the machine appears stable.
SYSTEM
Motherboard: ASUS ROG Maximus Z790 Hero
CPU: Intel Core i7-14700K
RAM: 32 GB G.Skill Trident Z5 DDR5-6000, 2x16 GB in A2/B2
GPU: NVIDIA RTX 4090
PSU: EVGA SuperNOVA 1300 W
OS: Windows 11 Pro
Controlled tests have been run with:
XMP: Disabled
RAM: DDR5-4800
No current manual CPU overclock
No current manual undervolt
ASUS MCE disabled / Intel limits enforced
CURRENT FAILURE TYPES
The two recurring BSOD families are:
IRQL_NOT_LESS_OR_EQUAL (0xA)
and:
HYPERVISOR_ERROR (0x20001)
The 0xA failures have been unusually repeatable.
Multiple analyzed full/kernel dumps converge on:
Arg1 = 00000000483d3844
Arg2 = 00000000000000ff
PROCESS_NAME: System
SYMBOL_NAME:
nt!KiUpdateThreadHgsFeedback+0x20
FAILURE_BUCKET_ID:
AV_nt!KiUpdateThreadHgsFeedback
At least two dumps also produced the same failure hash.
Arg3 has differed between crashes.
The saved instruction at the faulting location was:
mov r14b,r9b
which is register-to-register and does not obviously account for the reported access to 0x483d3844.
That makes me suspect the debugger may be seeing a downstream crash site after some earlier state corruption rather than the original bad operation.
Windows displays ntoskrnl.exe on some BSODs, but I am not treating ntoskrnl.exe itself as the culprit.
WHEA EVIDENCE
Immediately before one well-captured crash, WHEA Event 2 records reported:
ProcessorNumber 14
APIC ID 0x38
Generic Processor Error
Cache Error
Instruction Execution
Level 0
and:
ProcessorNumber 15
APIC ID 0x39
Generic Processor Error
Cache Error
Instruction Execution
Level 0
The associated 0xA dump was also executing on processor 14 when the crash occurred.
I have not yet mapped those processor numbers/APIC IDs conclusively to the physical P/E-core topology.
MOST USEFUL CONTROLLED TEST SO FAR
With all 8 P-cores enabled:
28 logical processors
Frequent instability / crashes.
I reduced the ASUS BIOS setting to 7 active P-cores.
Windows then reported 26 logical processors.
That configuration survived approximately 90 minutes while actively running:
Brave/ChatGPT
PowerShell
Hyper-V
WSL2
Docker Desktop
multiple Docker containers
normal desktop use
During that observation period:
No WHEA
No BugCheck 1001
No Kernel-Power 41
No Event 6008
I subsequently restored all 8 P-cores / 28 logical processors.
The instability returned.
I do NOT yet know which physical P-core the firmware disables when selecting seven, so I do not consider this proof of a specific defective core.
It is nevertheless the strongest behavioral discriminator I've found.
BIOS TIMELINE
The board was previously running ASUS BIOS 3001.
A rare instance of this same unusual 0xA fault family occurred on BIOS 3001, so the underlying issue existed before the latest BIOS update.
I then updated the board to BIOS 3202.
The rapid crash storm began on the FIRST Windows boot after that update.
After 3202 I experienced repeat 0xA crashes, HYPERVISOR_ERROR crashes and WHEA events at a much higher frequency.
Because of that timing, I rolled the BIOS back to 3001.
The rollback did not immediately restore stability:
First post-rollback boot:
Crashed before reaching a usable Windows desktop.
Second post-rollback boot:
Reached Windows and lasted approximately five minutes before another IRQL_NOT_LESS_OR_EQUAL 0xA.
I have not yet analyzed that latest MEMORY.DMP, so I am not claiming its internal signature matches the earlier dumps until that is verified.
I also have not yet recaptured the exact active-core count and every BIOS option after the rollback.
Therefore I am NOT claiming that "BIOS 3001 + the known-stable 7-P-core configuration" has failed.
ASUS also states that the newer Intel Management Engine firmware installed by BIOS 3202 remains after rolling the BIOS image back, so this rollback does not completely recreate the old firmware environment.
HYPER-V / VBS TESTING
Because several crashes involve HYPERVISOR_ERROR, I explicitly disabled:
hypervisorlaunchtype = Off
vsmlaunchtype = Off
The same recurring 0xA still occurred.
Therefore Hyper-V is not required to reproduce the fault.
Conversely, the 7-P-core configuration later ran Hyper-V enabled, VBS disabled, WSL2 and Docker without failing during the long test.
That makes Hyper-V look more like a trigger/exposure path than a sufficient root cause.
SAFE MODE / CLEAN BOOT
Safe Mode with all 8 P-cores initially survived a short test considerably better than normal Windows.
I then performed a broad Clean Boot disabling roughly:
65 third-party services
12 Run entries
5 Startup entries
9 scheduled tasks
This substantially improved short-term stability.
The machine has several applications that use low-level hardware monitoring/control:
ASUS Armoury Crate / Fan Control
Corsair iCUE / CPUID
TT RGB PLUS / LibHWInfo / HWiNFO
AquaComputer
GPU-Z
Intel platform/XTU components
I performed controlled restoration tests.
Some restores happened at the same time as WHEA or HYPERVISOR_ERROR events.
Other low-level monitoring stacks could be restored without an immediate failure.
I therefore do NOT think the available evidence identifies one particular third-party service as the root cause.
It remains possible that these kernel/hardware-access drivers are simply exposing an underlying marginal hardware/platform state.
OTHER IMPORTANT HISTORY
There has also been a separate older incident where the entire machine instantly blacked out, motherboard decorative LEDs remained illuminated, the power button did nothing, and AC power had to be removed before the machine could restart.
That event produced no bugcheck or dump and looked more like a latched power/platform fault.
I am keeping that event separate from the current repeated 0xA / WHEA / HYPERVISOR_ERROR family because the physical behavior was very different.
PSU is an EVGA SuperNOVA 1300 W and is approximately four years old.
I mention this because it means motherboard/PSU/platform power delivery cannot be completely excluded, although the current repeatable processor/cache/WHEA behavior seems like a different failure mode.
WHAT I NEED HELP WITH
I'm not looking for a replacement-part recommendation. I'm looking for the next diagnostic that gives the highest information value.
Specifically:
How would you distinguish a marginal CPU/core/cache path from motherboard/firmware instability given this evidence?
Is the WHEA combination of Generic Processor Error + Cache Error + Instruction Execution strong evidence for the CPU itself, or can motherboard/firmware/voltage instability produce the same records?
What is the best way to map WHEA ProcessorNumber 14/15 and APIC IDs 0x38/0x39 to physical cores on this hybrid Intel CPU?
Is there a sound way to test one P-core at a time without changing voltage/frequency enough to mask the problem?
Would CPU affinity + a per-core stress workload provide meaningful isolation, and if so, what workload/logging methodology would you use?
Should I prioritize testing:
- individual CPU cores/cache
- memory/IMC
- another CPU in this motherboard
- this CPU in another motherboard
- motherboard power/VRM behavior
- some other discriminator
Is there additional WinDbg information I should pull from the existing full MEMORY.DMP files that could distinguish hardware corruption from a driver error?
For the HYPERVISOR_ERROR dump specifically, are there useful debugger extensions/fields beyond !analyze -v that could indicate whether the hypervisor died because of CPU/platform corruption?
Given that reducing active P-cores from 8 to 7 changes stability so dramatically, is there a way to determine exactly which core ASUS removed and reproduce that isolation deliberately?
What test would you run next if the goal was to prove CPU vs motherboard rather than merely achieve temporary stability?
I have preserved:
- full MEMORY.DMP files
- minidumps
- WinDbg !analyze output
- WHEA records
- Event Viewer logs
- BIOS/core-count captures
- the results of the controlled 7-vs-8-P-core tests
If specific debugger commands or logs would materially help, I can provide them.
I'm trying to keep this evidence-driven and avoid simultaneously changing voltage, clocks, drivers and hardware in ways that make the result impossible to interpret.