I'm troubleshooting recurring Windows 11 crashes on an ASUS ROG Maximus Z790 Hero with a Core i7-14700K, 32 GB of DDR5-6000, and an RTX 4090. XMP is disabled, memory is running at DDR5-4800, manual overclocking and undervolting are off, and ASUS MultiCore Enhancement is disabled with Intel limits enforced.
The main failures are IRQL_NOT_LESS_OR_EQUAL (0xA) and HYPERVISOR_ERROR (0x20001). Several full or kernel dumps point to nt!KiUpdateThreadHgsFeedback, although the register-to-register instruction at the reported location makes downstream corruption possible rather than proving that Windows itself is responsible. 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. One related 0xA crash was running on processor 14.
The strongest controlled result is that the system is unstable with all 8 P-cores enabled and 28 logical processors, but ran for about 90 minutes with 7 P-cores enabled and 26 logical processors while using Hyper-V, WSL2, Docker, PowerShell, Brave, and normal desktop applications. During that test there were no WHEA events, bugchecks, unexpected shutdowns, or Kernel-Power events. Restoring the eighth P-core brought the instability back, although I do not yet know which physical P-core the firmware disables.
The issue existed at least once on BIOS 3001, became much more frequent after updating to BIOS 3202, and did not immediately disappear after rolling back. The newer Intel Management Engine firmware from the newer BIOS may remain installed, so the rollback was not a complete reproduction of the earlier firmware state. Disabling Hyper-V and VBS did not prevent the 0xA crashes, while the seven-core setup was stable with Hyper-V enabled.
Safe Mode and a broad clean boot improved short-term stability. The system has several low-level monitoring and hardware-control packages installed, including Armoury Crate, iCUE, HWiNFO-related components, RGB software, AquaComputer software, GPU-Z, and Intel tuning components. However, the current evidence does not identify one specific driver as the cause. There was also an older hard-power-lockup incident, so motherboard, power delivery, and the approximately four-year-old 1300 W PSU cannot be completely excluded.
I'm looking for the most informative next diagnostic step to distinguish a failing CPU core or cache from motherboard, firmware, IMC, power-delivery, or driver problems. In particular, I'd like to know how to map the WHEA processor numbers and APIC IDs to physical P-cores, whether individual-core testing can be done without masking the fault, what WinDbg information would be useful, and whether the evidence is strong enough to pursue CPU replacement or warranty service.
2 Answers
The older 13th- and 14th-generation desktop CPUs have a well-known history of degradation when motherboard firmware allows excessive voltage or power. Your cache-related WHEA records and the repeatable return of failures when all P-cores are enabled fit that pattern. First make sure the BIOS is using Intel-recommended limits and conservative defaults, then test with a known-good replacement CPU if possible. If another compatible CPU is stable in this board, that is far more useful evidence than repeatedly changing Windows drivers.
The seven-versus-eight-core behavior is a very strong sign that the CPU is marginal, especially combined with WHEA cache and instruction-execution errors. It is not absolute proof of one defective core—firmware, voltage behavior, or the board’s power delivery can create similar symptoms—but disabling one P-core removing the crashes is much more suspicious for the processor than for an ordinary Windows driver. I would verify that all automatic motherboard overclocking and enhanced-voltage options are disabled, keep the latest stable firmware and Intel limits, and pursue a CPU warranty replacement rather than treating the seven-core setting as a permanent fix.
It is also worth checking whether the board applied aggressive default voltage or power settings. A BIOS update can expose or worsen a marginal CPU, but the fact that the problem existed on the older firmware means the update is probably not the whole explanation.
If replacement is necessary, a compatible 12th-generation processor avoids the specific later-generation degradation issue, although checking warranty coverage for the current processor should come first.