¿Ves picos de CPU aleatorios en Windows Server 2016 y el proceso “System (NT Kernel & System)” está siempre en la parte alta? Esta guía te lleva de la mano —de lo más rápido a lo más profundo— para diagnosticar DPC/ISR, drivers y firmware, y dejar la CPU estable.
Resumen de la situación
Un servidor con Windows Server 2016 experimenta picos de CPU frecuentes y no determinísticos. El consumo proviene de System (NT Kernel & System), por lo general indicio de trabajo en modo kernel (interrupciones y DPC) provocado por drivers de red, almacenamiento, antivirus, virtualización o firmware subyacente.
Qué significa que “System” consuma CPU
Cuando el proceso System sube en CPU, el tiempo está yéndose a % Privileged Time, que incluye ISR (rutinas de servicio de interrupción) y DPC (llamadas diferidas). El kernel planifica trabajo de drivers allí: paquetes de red (NDIS), E/S de disco (STORPORT), filtros del sistema de archivos, temporizadores de hardware (HAL/ACPI), virtualización (VMBus, drivers sintéticos) y más. El reto es atribuir el uso a un driver y corregir.
Plan de acción: de lo más rápido a lo más profundo
Higiene básica antes de medir
- Actualiza Windows (acumulativos de seguridad y calidad) y BIOS/UEFI del hardware.
- Drivers críticos al día: chipset, red (NIC), almacenamiento/RAID/HBA/NVMe y drivers sintéticos si es VM.
- Si es máquina virtual, actualiza VMware Tools o Hyper‑V Integration Services.
- Plan de energía: Alto rendimiento (
powercfg.cpl
o PowerShell) y reinicio en ventana de mantenimiento.
REM Ver planes disponibles y activar Alto rendimiento
powercfg /L
powercfg /S <GUID-AltoRendimiento>
Confirmar si los picos son por DPC/Interrupciones
Primero valida que el problema sí es de kernel/drivers.
- Administrador de tareas → pestaña Rendimiento. Abre Monitor de recursos (
resmon.exe
). Observa Interrupciones del sistema durante un pico. - PerfMon (perfmon.msc): crea un Data Collector Set por 10–15 minutos con contadores clave y muestreo de 5 s.
Contador PerfMon | Por qué importa | Umbral orientativo | Qué concluye |
---|---|---|---|
Processor(_Total)\% Privileged Time | Trabajo de kernel (drivers, DPC/ISR) | > 30–40% sostenido | Sobrecarga de drivers/firmware |
Processor(_Total)\% DPC Time , % Interrupt Time | DPC e ISR específicamente | Picos > 10–15% | Problema de interrupciones/DPC |
System\Context Switches/sec | Cambios de contexto por segundo | > 30–50k y creciente | Driver “chatter”/temporizadores agresivos |
Processor(*)\DPCs Queued/sec | Colas DPC por CPU | Picos altos al unísono | Driver que inunda DPC |
Process(System)\% Privileged Time | CPU de System en kernel | Correlaciona con picos | Aísla el proceso implicado |
Interpretación clave: Si % DPC y/o % Interrupt aumentan cuando la CPU sube, la causa es un driver o firmware. Si sube % User Time con otras apps (IIS/SQL), no es este caso.
Identificar el driver exacto
Process Explorer: hilos del proceso System
- Ejecuta Process Explorer (procexp.exe) como administrador.
- Haz doble clic en System → pestaña Threads.
- Ordena por CPU y anota Start Address y Module del hilo que más consume.
Módulo/Start Address típico | Subsistema probable | Próximo paso |
---|---|---|
ndis.sys!NdisMIndicateReceiveNetBufferLists | Red (NIC, offloads, RSS, VMQ) | Actualizar NIC, ajustar offloads, RSS/VMQ |
storport.sys!RaidUnitDpcRoutine / controlador HBA | Almacenamiento/RAID/NVMe/SAN | Actualizar HBA/RAID y firmware, revisar errores |
wdf01000.sys (KMDF) | Driver de 3.º apoyado en KMDF | Encontrar el driver asociado en la pila |
hal.dll!HalpHpetClockInterrupt | Temporizadores/ACPI/HPET | Ajustes de energía/BIOS, revisar timers |
wdfilter.sys / WdFilter.sys / otros AV | Antivirus/filtros | Exclusiones o desactivar temporalmente |
vmbus.sys / netvsc.sys / storvsc.sys | Drivers sintéticos (Hyper‑V) | Actualizar Integration Services, host y VM |
WPR/WPA (Windows Performance Recorder/Analyzer)
- Abre WPRUI.exe. Selecciona perfil General Profile con CPU usage habilitado (o Resource Analysis).
- Graba 2–5 min mientras ocurre el pico. Evita sesiones > 10 min para mantener ETL manejable.
- Detén la traza y ábrela en WPA.
- En Graph Explorer, abre CPU Usage (Sampled) y DPC/ISR. Cambia a vistas por Module y Stack. El módulo en la cima durante el pico es el sospechoso.
REM Alternativa por línea de comandos (xperf clásico)
xperf -on latency -stackwalk profile -buffersize 1024 -MaxFile 1024 -FileMode Circular -Start CPUTrace
REM Reproducir el pico 2–3 min
xperf -stop CPUTrace -d C:\Traces\cpu_dpc.etl
Corregir según el área culpable
Red (NDIS/NIC)
- Actualiza el driver de la NIC desde el fabricante del hardware (no solo Windows Update).
- Como prueba temporal, desactiva características de offload problemáticas una por una midiendo impacto (si no cambia, vuelve a activar): LSO, Checksum Offload, RSC. Ajusta Interrupt Moderation.
- RSS habilitado para distribuir carga entre CPUs. En entornos con VMQ (host/VM), prueba a deshabilitar VMQ si observas picos anómalos.
# Ver y ajustar propiedades avanzadas de la NIC (PowerShell)
Get-NetAdapterAdvancedProperty -Name "Ethernet*"
Ejemplos (usar nombres/valores exactos según NIC):
Set-NetAdapterAdvancedProperty -Name "Ethernet 1" -DisplayName "Large Send Offload v2 (IPv4)" -DisplayValue "Disabled"
Set-NetAdapterRss -Name "Ethernet 1" -Enabled $true
Deshabilitar RSC (si aplica)
Disable-NetAdapterRsc -Name "Ethernet 1"
Almacenamiento (STORPORT/HBA/RAID/NVMe)
- Actualiza driver y firmware de controladora/RAID/NVMe/HBA. Verifica compatibilidad con el modelo exacto.
- Revisa Visor de eventos → Sistema por eventos de disk, storport, ntfs, volsnap, iaStor, megaraid, etc.
- Correlaciona con software de backup (VSS, snapshots) en la ventana del pico.
- Comprueba latencias y colas de E/S. Asegura que MPIO y colas del HBA estén configuradas según el almacenamiento.
wevtutil qe System /q:"*[System[Provider[@Name='storport'] or Provider[@Name='disk'] or Provider[@Name='Ntfs']]]" /f:text /c:50
Antivirus / Filtros del sistema de archivos
- Lista filtros cargados y su orden para identificar candidatos que inyectan DPC/ISR.
fltmc filters
- Prueba en ventana controlada a desactivar temporalmente la protección en tiempo real o a aplicar exclusiones adecuadas (directorios de datos, logs, colas, bases de datos, binarios de la aplicación, rutas de backup/AV).
CPU/Hardware/Temporizadores/WHEA
- Busca WHEA‑Logger (eventos 17/18/19/20) que indiquen errores de hardware o bus PCIe.
- En BIOS/UEFI, valida C‑states, EIST/Boost y HPET. Con Alto rendimiento deberías reducir latencias de temporizador.
- Si ves
hal.dll!HalpHpetClockInterrupt
alto, audita apps que cambian la resolución de timer (servicios APM, monitores, agentes). Restablece a 15.6 ms cuando sea posible.
Virtualización
- En el hipervisor, revisa métricas de CPU Ready / Co‑Stop (VMware) y sobreasignación de vCPU. Evita asignar más vCPU de las físicas si el host ya está al límite.
- Actualiza drivers sintéticos (vNIC/vSCSI) y herramientas de integración. Ajusta VMQ en host/VM si causa latencia.
Flujo de diagnóstico práctico
- Captura evidencia (PerfMon + Process Explorer). Anota hora exacta y carga de trabajo concurrente.
- Confirma DPC/ISR con % DPC/Interrupt Time. Si no suben, reevalúa (puede ser una app en modo usuario).
- Asocia un módulo usando hilos de System o WPA.
- Aplica corrección focalizada (driver, offloads, firmware, exclusiones AV, ajustes VMQ/RSS).
- Valida con la misma carga: debe bajar % DPC/Interrupt y estabilizar System.
Casos frecuentes y “parches” rápidos
Patrón observado | Causa típica | Acción rápida |
---|---|---|
ndis.sys en cima; picos con tráfico | Offloads defectuosos o versión de NIC | Actualizar NIC; deshabilitar LSO/RSC; habilitar RSS; ajustar Interrupt Moderation |
storport.sys o driver HBA alto | Firmware/driver RAID/HBA, colas saturadas | Actualizar firmware y driver; revisar eventos disk/storport; ajustar colas |
WdFilter.sys / filtro AV en pila | Escaneo en caliente de I/O críticas | Exclusiones para datos de app/DB/logs; probar desactivar tiempo real |
hal.dll con ClockInterrupt | Timer resolution baja impuesta por app | Cerrar agente que fija 0.5–1 ms; Alto rendimiento; revisar HPET |
VM con picos sin carga real | VMQ/RSS mal combinados o CPU Ready | Deshabilitar VMQ en NIC de VM/host; revisar sobreasignación |
Cómo crear un Data Collector Set útil
- Abre perfmon.msc → Data Collector Sets → User Defined → New → Data Collector Set.
- Elige Create manually → Performance counter y agrega:
Processor(_Total)\% Privileged Time
,% DPC Time
,% Interrupt Time
Process(System)\% Privileged Time
System\Context Switches/sec
Processor(*)\DPCs Queued/sec
- Intervalo: 5 s; duración: hasta capturar el pico (10–15 min).
- Guarda en ruta dedicada (por ejemplo
D:\PerfLogs
). Al terminar, exporta el reporte.
Inventario y utilidades de diagnóstico
driverquery /v /fo table > C:\Temp\drivers.txt
wmic path Win32_PnPSignedDriver get DeviceName,DriverVersion,DriverDate /format:table
Enumerar y ordenar por timestamp de instalación
Get-WmiObject Win32_PnPSignedDriver | Select DeviceName, DriverVersion, DriverDate | Sort-Object DriverDate
Redes
Get-NetAdapter | Format-Table Name, Status, LinkSpeed
Get-NetAdapterAdvancedProperty -Name "Ethernet*" | Sort-Object DisplayName
TCP global (solo lectura)
netsh int tcp show global
Checklist de mitigación por área
Red
- Driver actualizado (versión exacta para tu NIC/modelo).
- Pruebas A/B de offloads: LSO, Checksum Offload, RSC (documenta cada cambio).
- RSS habilitado y tamaño de colas adecuado. Evaluar VMQ en hosts virtualizados.
- Evita teaming con modos no recomendados para tu driver si hay picos.
Almacenamiento
- Firmware/driver de HBA/RAID/NVMe al día.
- Sin errores en disk/ntfs/storport durante la ventana.
- Backup/VSS fuera de horas pico o con exclusiones correctas.
Antivirus/Filtros
- Exclusiones aplicadas a rutas de datos, temp, colas, DB, logs.
- Comprobación con tiempo real desactivado temporalmente en ventana de mantenimiento.
CPU/Hardware
- Plan Alto rendimiento. C‑states/HPET ajustados.
- Sin eventos WHEA en el periodo de prueba.
Virtualización
- Sin CPU Ready/Co‑Stop anómalos.
- Drivers sintéticos actualizados; VMQ revisado.
Señales de que quedó resuelto
- System estable por debajo de 1–5% en carga normal.
- % DPC Time y % Interrupt Time bajos y sin picos prolongados.
- Ausencia de nuevos errores en el Visor de eventos relacionados con red/almacenamiento/WHEA.
Errores comunes a evitar
- Actualizar múltiples drivers a la vez: dificulta atribución de causa.
- Olvidar reiniciar después de drivers/firmware que lo requieren.
- Deshabilitar todo de golpe (offloads, RSS, VMQ) sin método ni medición.
- Conclusiones con capturas de pocos segundos: toma ventanas representativas.
Plantilla de bitácora de cambios
Fecha/Hora:
Síntoma observado:
Carga de trabajo concurrente:
Evidencia (PerfMon/WPA/PE):
Driver/firmware ajustado (versión):
Cambio aplicado:
Resultado medido (%Privileged, %DPC, %Interrupt):
Siguiente paso:
Preguntas frecuentes
¿Puede ser malware? Es poco habitual que un malware se manifieste solo como DPC/ISR altos en “System”. Aun así, mantén AV actualizado y analiza. La mayoría de casos son drivers o firmware.
¿Y si la CPU la usa IIS/SQL? Si los contadores de % DPC/Interrupt no suben y ves procesos de usuario al frente, investiga la aplicación; esta guía se centra en kernel/drivers.
¿Cuánto dejar correr PerfMon? Lo suficiente para capturar varios picos (10–15 min típicamente). Evita archivos gigantes y guarda la hora exacta.
Playbook resumido
- Poner al día Windows/firmware/drivers + plan de energía alto rendimiento.
- Confirmar DPC/ISR con PerfMon y resmon.
- Localizar módulo con Process Explorer y/o WPA.
- Corregir: red (offloads/RSS/VMQ/driver), almacenamiento (driver/firmware/errores), filtros AV (exclusiones), temporizadores/BIOS, virtualización.
- Validar estabilidad y documentar resultados.
Apéndice: comandos útiles agrupados
PowerShell para red
# Ver NIC y vínculos
Get-NetAdapter | ft Name, Status, LinkSpeed
Propiedades avanzadas (exporta a CSV para revisión)
Get-NetAdapterAdvancedProperty | Export-Csv C:\Temp\nic-advanced.csv -NoTypeInformation
RSS
Get-NetAdapterRss
Set-NetAdapterRss -Name "Ethernet 1" -Enabled $true
RSC
Get-NetAdapterRsc
Disable-NetAdapterRsc -Name "Ethernet 1"
Almacenamiento y eventos
Get-EventLog -LogName System -Newest 200 |
Where-Object {$_.Source -in @('disk','storport','Ntfs','iaStorA','megaraid')} |
Format-Table TimeGenerated, Source, EventID, Message -Auto
Inventario de drivers
driverquery /si
driverquery /v /fo table
WPR rápido
wpr -start GeneralProfile -start CPU -filemode
REM Reproduce el pico…
wpr -stop C:\Traces\cpu.etl
Checklist final de cierre
- Capturas PerfMon antes/después guardadas y adjuntas a la incidencia.
- Versión exacta de drivers/firmware anotada.
- Cambios revertidos si no aportan mejora medible.
- Planes de mantenimiento y backups coordinados fuera de horas pico.
Conclusión
Los picos de CPU en System (NT Kernel & System) se resuelven en la mayoría de los casos al identificar el driver que dispara DPC/ISR y aplicar medidas quirúrgicas: actualización de NIC/HBA, ajuste de offloads, exclusiones de AV, y saneamiento de firmware y energía. Con el método de esta guía (PerfMon → PE/WPA → corrección focalizada) podrás estabilizar Windows Server 2016 y recuperar margen de CPU de forma reproducible.
Resumen operativo (copiable)
Qué implica: “System” alto = trabajo en kernel por drivers/interrupciones (red, almacenamiento, antivirus, virtualización, firmware).
Plan de acción:
- Higiene: Windows/firmware/drivers al día; plan Alto rendimiento.
- Confirmar DPC/ISR: Task Manager + resmon + PerfMon con contadores clave.
- Identificar driver: Process Explorer (System→Threads) y/o WPR/WPA.
- Corregir según área: red (offloads, RSS/VMQ, driver), almacenamiento (driver/firmware, eventos), AV (exclusiones), CPU/WHEA, virtualización.
- Validar y documentar: “System” < 1–5%, DPC/Interrupt bajos, sin eventos críticos.
Checklist de comandos y utilidades
perfmon.msc
→ crear DCS con contadores indicados.resmon.exe
→ confirmar Interrupciones del sistema.- Process Explorer → System → Threads (módulo/start address).
driverquery /v /fo table
→ inventario de drivers.fltmc filters
→ filtros de sistema de archivos.- WPRUI.exe / WPA.exe → traza y análisis de CPU/DPC/ISR.
Notas de seguridad y gobernanza
- Realiza cambios de drivers/firmware y pruebas de desactivación uno por vez y en ventanas de mantenimiento.
- Documenta cada ajuste con hora, versión y métrica de resultado.
- Cuenta con plan de reversión (rollback) y copias de seguridad antes de tocar firmware/BIOS.
Con estas prácticas, la mayoría de entornos estabiliza los picos de “System” sin reinstalar ni apagar servicios de negocio.