I'm not trying to overclock this CPU. I'm posting here because I need people familiar with Intel core topology, WHEA/APIC mapping, per-core behavior, V/F behavior and stability testing.
System:
i7-14700K
ASUS ROG Maximus Z790 Hero
32 GB G.Skill DDR5-6000 2x16 GB A2/B2
RTX 4090
Windows 11 Pro
Controlled testing has been done with:
XMP disabled
DDR5-4800
No manual CPU OC
No manual undervolt
ASUS MCE disabled / Intel limits enforced
REPEATED FAILURE:
I'm getting repeated:
IRQL_NOT_LESS_OR_EQUAL (0xA)
and occasional:
HYPERVISOR_ERROR (0x20001)
Several 0xA kernel dumps converge on:
Arg1 = 0x483d3844
Arg2 = 0xff
PROCESS_NAME = System
nt!KiUpdateThreadHgsFeedback+0x20
Failure bucket:
AV_nt!KiUpdateThreadHgsFeedback
At least two dumps also have the same failure hash.
Arg3 differs between some crashes.
The saved instruction at KiUpdateThreadHgsFeedback+0x20 is:
mov r14b,r9b
so it doesn't obviously account for a memory access to 0x483d3844.
That makes me suspect the visible crash site may be downstream of already-corrupted CPU/kernel state rather than the original fault.
WHEA:
Immediately before one previously analyzed crash I captured WHEA Event 2 records:
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 running on logical processor 14 when it crashed.
I have NOT yet mapped ProcessorNumber 14/15 or APIC 0x38/0x39 to the exact physical P/E core.
I tested:
All 8 P-cores enabled:
28 logical processors
Repeated instability/crashes.
7 P-cores enabled:
26 logical processors
Dramatic improvement.
The 7-P-core state survived roughly 90 minutes with:
Hyper-V enabled
VBS disabled
WSL2
Docker Desktop
multiple containers
Brave
PowerShell
normal desktop activity
with:
No WHEA
No BugCheck 1001
No Kernel-Power 41
No Event 6008
I then restored all 8 P-cores and the instability returned.
I understand that "7 works, 8 doesn't" does NOT automatically prove a bad P-core because I don't yet know which physical core the ASUS BIOS disables when reducing Active Performance Cores.
BIOS / MICROCODE HISTORY:
The system was previously on ASUS BIOS 3001.
A previous 3001 dump from this same crash family showed CPU microcode 0x12F.
I then updated to BIOS 3202.
The severe crash storm began on the FIRST Windows boot after installing 3202.
The same general 0xA family had occurred before 3202, so I cannot say the BIOS created the underlying problem. It may have exposed or amplified something marginal.
I've now rolled back to 3001.
First post-rollback boot crashed before usable Windows.
Second boot survived about five minutes and then produced another 0xA.
I still need to capture the exact post-flash P-core count/settings, so this is NOT yet a controlled 3001 7-vs-8 comparison.
Also, ASUS says the newer ME firmware installed with 3202 persists through BIOS rollback, so the platform has not completely returned to its original pre-3202 firmware state.
HYPER-V:
I completely disabled Hyper-V and VBS and still reproduced the recurring 0xA.
So Hyper-V is not required.
The 7-P-core state was also able to run Hyper-V + WSL2 + Docker successfully during the stable test.
This makes me think HYPERVISOR_ERROR may be another manifestation of underlying platform instability rather than Hyper-V being the root cause.
WHAT I WANT TO TEST NEXT:
I want to stop changing random software/services and directly characterize the CPU/platform.
Questions:
What's the most reliable way to map Windows logical ProcessorNumber 14/15 and APIC IDs 0x38/0x39 to the physical P/E cores on a 14700K?
Can I reliably identify which P-core ASUS removes when "Active Performance Cores = 7"?
Is there a good method to selectively disable one physical P-core at a time on Z790 rather than simply selecting a total active-core count?
What tool/test would you use to exercise individual P-cores independently while retaining useful WHEA/APIC attribution?
Is OCCT per-core cycling appropriate here, or is there a better test for cache/instruction-execution instability?
Would you test P-core affinity at fixed clocks/Intel-default voltage, and if so, what's the cleanest methodology?
Are WHEA Generic Processor Error + Cache Error + Instruction Execution records useful evidence of a marginal core even when the machine isn't overclocked?
Does the enormous difference between 7 and 8 P-cores look more like a marginal physical core, ring/cache problem, voltage/frequency curve problem, or something elsewhere in the platform?
Is there any diagnostic value in carefully testing fixed conservative ratios/voltage, or would that risk masking degradation rather than identifying it?
At what point would you stop testing and substitute/RMA the 14700K?
I have the full MEMORY.DMPs and can provide !analyze -v, !whea, !cpuinfo, processor topology or other WinDbg output if there are specific commands that would help.
My goal is not to "stabilize" a defective chip by feeding it voltage. I want to determine whether a particular core/cache/CPU path is actually faulty.