Problema

En plataformas con procesadores Intel híbridos (P‑cores + E‑cores) y placas base Z790, es frecuente observar reinicios inesperados bajo Windows 11. Los síntomas típicos incluyen:

  • BSOD con código IRQL_NOT_LESS_OR_EQUAL (0xA) cuyo stack apunta a nt!KiUpdateThreadHgsFeedback.
  • BSOD con HYPERVISOR_ERROR (0x20001).
  • Eventos WHEA que reportan Generic Processor Error y Cache Error en los niveles de ejecución de instrucción.

Los fallos aparecen cuando los ocho P‑cores están activos, pero desaparecen al desactivar uno de ellos (reducción a 7 P‑cores → 26 hilos lógicos). La inestabilidad persiste pese a desactivar Hyper‑V, limpiar servicios de terceros y ejecutar pruebas en modo seguro.

El objetivo es determinar si la raíz está en el propio CPU, en la placa base/firmware o en una interacción de bajo nivel con el kernel, y obtener un método reproducible de aislamiento.

Causa

Los eventos WHEA Generic Processor Error con Cache Error pueden originarse en tres áreas principales:

  1. Defecto del núcleo o caché – errores de corrección de ECC, problemas de timing interno o degradación física del silicio. Suelen aparecer como fallos reproducibles en un mismo hilo o core y se acompañan de direcciones de memoria que no coinciden con el código del kernel.
  2. Instabilidad del VRM o de la alimentación del socket – fluctuaciones de Vcore o VTT que afectan solo a los P‑cores cuando el controlador de energía del BIOS los habilita simultáneamente. Los cambios de carga (por ejemplo, al habilitar todos los P‑cores) pueden desencadenar picos que el regulador no soporta.
  3. Firmware/IMC defectuoso – errores en la tabla de asignación de APIC IDs, en la gestión de la caché L2/L3 o en la sincronización de los hilos híbridos. Un BIOS que modifica la topología sin actualizar correctamente la tabla de micro‑código puede producir WHEA falsos positivos.

En la práctica, la combinación de IRQL_NOT_LESS_OR_EQUAL y WHEA Cache Error indica corrupción de datos en tiempo de ejecución, lo que sugiere una causa de hardware más que un driver. Sin embargo, un driver que accede directamente a MSRs o a registros de energía puede amplificar una marginalidad existente.

Solución

1. Mapear APIC ID → Core físico

Windows expone la relación mediante Get-LogicalProcessorInformationEx. El siguiente script muestra la tabla y permite identificar qué APIC ID corresponde a cada P‑core:

powershell -NoProfile -Command ^
"$info = Get-LogicalProcessorInformationEx -Relationship Processor; ^
foreach ($p in $info) { ^
  $core = $p.Processor.GroupMask[0]; ^
  $apic = $p.Processor.GroupMask[0].Mask; ^
  Write-Host ('Core {0} – APIC 0x{1:X2}' -f $p.Processor.Group, $apic) ^
}"

Anote los IDs que aparecen en los eventos WHEA (por ejemplo, 0x38 y 0x39) y correlaciónelos con los núcleos listados. Esa información es esencial para dirigir pruebas a un solo P‑core.

2. Aislar un P‑core con afinidad y stress

Una vez identificado el core problemático, use Start-Process con la opción -ProcessorAffinity. Combine con una carga de trabajo que ejerza presión sobre la caché L1/L2, como Prime95 en modo “Blend” o IntelBurnTest.

powershell -NoProfile -Command ^
"$pid = (Start-Process -FilePath 'prime95.exe' -ArgumentList '-t' -PassThru).Id; ^
Set-ProcessAffinityMask -Id $pid -Mask 0x00000004"   # máscara para el core 2

Ejecute la carga durante al menos 30 minutos y monitorice:

  • Event Viewer → System para nuevos eventos WHEA.
  • Performance Monitor (contadores Cache\L1 Cache Misses y Processor\% Processor Time del core aislado).
  • HWMonitor o la herramienta de la placa para voltajes Vcore y VTT.

Si el BSOD reaparece exclusivamente cuando el core aislado está bajo carga, la evidencia apunta a un defecto del núcleo o de la caché.

3. Probar con un BIOS “stock” y sin micro‑código personalizado

Flash el BIOS a la versión más antigua disponible que no incluya actualizaciones de Intel Management Engine. Después del flash, desactive Load Optimized Defaults, habilite CPU Core Count a 8 y desactive XMP. Reinicie y repita la prueba de afinidad. Si el problema persiste, descarta la hipótesis de firmware reciente.

4. Verificar la alimentación del VRM

Utilice un osciloscopio o un multímetro de alta frecuencia para capturar el ripple de Vcore mientras los ocho P‑cores están activos. Valores de ripple superiores a 30 mV a 1 kHz son sospechosos. Si el ruido aumenta al habilitar el octavo core, la placa base o la fuente pueden estar al límite.

5. Ejecutar pruebas de memoria e IMC independientes

Aunque la falla parece centrada en la CPU, un controlador de memoria defectuoso puede generar errores de caché que se reportan como Processor Error. Use MemTest86 en modo “Extended” y, si la placa lo permite, habilite la opción “Test IMC” para forzar lecturas/writes al controlador de memoria mientras los cores están desactivados.

6. Comparar con hardware de referencia

Si dispone de un segundo socket Z790 o de una placa base compatible, instale el mismo CPU y repita la prueba de afinidad. La ausencia de BSOD confirma que la placa base original es la variable crítica. De forma inversa, usar otro CPU (por ejemplo, i7‑14700) en la placa original permite descartar la placa.

Cuándo aplicar esta solución

  • Síntomas: BSOD 0xA o 0x20001, eventos WHEA Cache Error, inestabilidad solo con todos los P‑cores activos.
  • Entorno: Windows 11, BIOS reciente, sin overclock manual.
  • No aplicar: Cuando la inestabilidad ocurre también con solo E‑cores activos o cuando los logs apuntan a drivers de terceros (por ejemplo, dxgkrnl.sys).

Verificación

  1. Ejecutar el script de mapeo APIC → Core y registrar los IDs.
  2. Aplicar afinidad a un solo core y lanzar Prime95 ≥ 30 min.
  3. Confirmar que:
    • No aparecen eventos WHEA ni BSOD.
    • Los contadores de caché permanecen estables.
  4. Repetir el paso 2 para cada core individualmente. Si sólo uno genera fallos, ese core es sospechoso.
  5. Si todos los cores pasan, flash al BIOS anterior y repetir la prueba completa de 8 cores. La ausencia de fallos indica firmware/VRM como causa.

Notas adicionales

  • La desactivación de Hyper‑V y VBS ayuda a reducir la superficie de ataque, pero no elimina la raíz del problema.
  • Algunos usuarios reportan que la opción “CPU Core Count” en BIOS desactiva el core con mayor consumo térmico; revisar la tabla de consumo TDP por core puede dar pistas.
  • Cuando se trabaja con dumps, el comando !whea -v en WinDbg muestra los campos ProcessorNumber y ApicId. Cruce esos valores con la tabla obtenida en PowerShell para confirmar la coincidencia.
  • Si el VRM muestra sobrecalentamiento bajo carga completa, considere mejorar la refrigeración del disipador de la placa o probar una fuente de alimentación de mayor capacidad, aunque la PSU actual (1300 W) suele ser suficiente.