I'm investigating recurring Windows 11 crashes on an ASUS ROG Maximus Z790 Hero with an Intel Core i7-14700K, 32 GB of DDR5-6000, an RTX 4090, and an EVGA 1300 W PSU. For testing, XMP is disabled, memory is running at DDR5-4800, manual overclocking and undervolting are off, ASUS MCE is disabled, and Intel power limits are enforced.
The main failures are IRQL_NOT_LESS_OR_EQUAL (0xA) and HYPERVISOR_ERROR (0x20001). Several full or kernel dumps repeatedly point to nt!KiUpdateThreadHgsFeedback, although the register-to-register instruction at the reported location does not appear to explain the referenced address. This makes downstream corruption possible rather than proving that Windows itself is the cause.
More concerningly, WHEA records immediately before one crash reported Generic Processor Error, Cache Error, and Instruction Execution on processor numbers 14 and 15, with APIC IDs 0x38 and 0x39. The associated 0xA crash was running on processor 14. I have not yet conclusively mapped those IDs to physical P- or E-cores.
The strongest controlled result is that the system is unstable with all 8 P-cores enabled, exposing 28 logical processors, but survived roughly 90 minutes of normal use with Hyper-V, WSL2, Docker, PowerShell, and browser workloads after reducing the BIOS setting to 7 active P-cores. There were no WHEA, BugCheck, Kernel-Power, or unexpected-shutdown events during that test. Restoring all 8 P-cores brought the instability back, although I do not yet know which physical core the firmware disables.
The problem became much more frequent after BIOS 3202, though a similar crash had occurred on BIOS 3001. Rolling back does not fully restore the old firmware environment because newer Intel Management Engine firmware remains installed. Disabling Hyper-V and VBS did not prevent the recurring 0xA crashes, while the reduced-core configuration remained stable with Hyper-V enabled. Safe Mode and a broad clean boot also improved stability, but the machine contains several low-level monitoring and control tools, so I cannot yet identify one driver as the cause.
There was also an older hard-lock and power-cycle incident, so PSU, motherboard, VRM, and platform power issues cannot be completely dismissed. I'm looking for the highest-value next diagnostic—not random setting changes. How should I distinguish a defective CPU core or cache from motherboard, firmware, IMC, power-delivery, or driver instability? What is the best way to map the WHEA processor and APIC IDs, isolate one P-core at a time without masking the problem, analyze the existing dumps, and determine whether the CPU or motherboard is responsible?
4 Answers
The debugger location in ntoskrnl is not enough to blame Windows. For the full dumps, compare all failures for the faulting thread, processor, blackbox data, stack, trap frame, register state, loaded third-party modules, and any consistent corruption pattern. For the hypervisor failures, inspect the bugcheck parameters and hypervisor flags, but a hypervisor crash can simply be where corrupted CPU or memory state becomes visible. MemTest-style testing, a long conservative memory/IMC test, and a clean-boot reproduction are useful exclusions, but the CPU-versus-board swap is likely to provide more information than repeatedly changing clocks or voltages.
The most informative hardware test is a controlled swap, not a more aggressive stress test. Run the same conservative BIOS configuration with another known-good compatible CPU in this board, or test this CPU in another suitable board if that is practical. Keep memory at JEDEC settings and use the same operating-system image and driver set. If another CPU is stable in the board while this CPU fails, the CPU becomes the leading suspect; if both fail, investigate board firmware, socket contact, VRM behavior, memory, and power delivery. Test one variable at a time and record WHEA counts, crash time, active cores, BIOS version, and temperatures.
The repeatable difference between 8 and 7 P-cores, combined with WHEA cache and instruction-execution errors, makes a marginal CPU core or cache path a serious possibility. It is not absolute proof—the same records can result from unstable voltage delivery, firmware behavior, or a damaged platform—but this is more significant than a normal driver-only crash. First make sure every BIOS setting is genuinely at Intel defaults, including power, load-line, CEP, thermal, and current protections. Also verify the exact active-core configuration after each BIOS change, since a rollback may not reproduce the previous firmware state.
For core mapping, collect Windows processor topology and APIC data rather than relying on the processor number alone. Compare the WHEA APIC IDs with the logical-processor and core layout reported by tools such as WinDbg, coreinfo, and the Windows processor-information APIs. Then repeat the test with explicit affinity masks and a per-core workload, logging which logical processors are exercised and whether WHEA records name the same APIC IDs. Affinity is useful for correlation, but it is not perfect isolation because cache, fabric, IMC, interrupts, and firmware activity are shared. Keep monitoring drivers removed or disabled during this phase, and use Driver Verifier only selectively on non-Microsoft drivers because it can create additional crashes and obscure the hardware pattern.
Disabling one core can hide a weak part without repairing it. If the processor is still under warranty, repeated WHEA processor/cache errors and the core-count-dependent behavior would be useful evidence for a replacement claim.