Los reinicios inesperados en Windows Server 2016 debidos al bug check 0x133 DPCWATCHDOGVIOLATION pueden detener operaciones críticas de negocio. Esta guía práctica describe en detalle cómo identificar la causa y aplicar una solución fiable y definitiva.
Descripción del problema
El kernel de Windows incluye un “perro guardián” (watchdog) encargado de vigilar que los Deferred Procedure Calls (DPC) no se eternicen a nivel de interrupción. Si un DPC se mantiene demasiado tiempo en IRQL ≥ DISPATCH_LEVEL (generalmente más de 100 µs continuos o 140 s acumulados), el sistema concluye que algo mantiene a la CPU “secuestrada” y detona un BSOD con el código 0x133. En el volcado, el proceso activo suele ser el que estaba usando el procesador (por ejemplo, sqlservr.exe), pero rara vez es el verdadero culpable.
Señales y síntomas
- Eventos Event ID 41 (Kernel‑Power) sin apagado limpio.
- Registro de errores SQL advirtiendo de un apagado inesperado al mismo segundo del BSOD.
- Eventos Event ID 129 (storahci) o Event ID 11 (disk) señalando tiempo de espera en el subsistema I/O.
- Advertencias de temporizador HPET o ACPI en el registro del sistema.
- Descenso puntual de rendimiento antes del reinicio: picos de latencia DPC > 100 µs medidos con LatencyMon o Windows Performance Toolkit.
Cómo interpretar el volcado de memoria
Con WinDbg_preview (o el kit de depuración clásico) carga el volcado y ejecuta:
!analyze -v
!dpc
!irql
!stacks 0 1fObserva el módulo señalado en la sección “IMAGE_NAME” y busca InterruptServiceRoutine que se repite. Si el volcado es minidump, la información puede ser incompleta; más abajo verás cómo activar un volcado de memoria de kernel completo.
Solución recomendada paso a paso
| Prioridad | Acción | Detalle / Herramienta |
|---|---|---|
| 1 | Actualizar controladores y firmware | Almacenamiento (controlador AHCI/RAID y firmware SSD). Red. Vídeo (aunque sea servidor, drivers desactualizados pueden provocar DPC largos). |
| 2 | Aplicar todas las actualizaciones de Windows | Asegura que el kernel y HAL tengan las correcciones más recientes. |
| 3 | Analizar volcados con WinDbg | Usa !analyze -v, !dpc, !irql y !stacks para identificar el controlador que monopoliza CPU. Configura símbolos correctos (srv*). |
| 4 | Comprobar integridad del sistema | sfc /scannowDISM /Online /Cleanup-Image /RestoreHealth |
| 5 | Verificar disco | chkdsk /f /r y herramientas del fabricante (SMART). |
| 6 | Prueba de memoria | Ejecuta Windows Memory Diagnostic o MemTest86 durante varias pasadas. |
| 7 | Revisar software reciente y cargas de trabajo | Controladores de antivirus, backup o filtrado de red pueden generar DPC extensos. Confirma si las tareas SQL (copias, indexaciones, etc.) coinciden con el momento del fallo. |
| 8 | Optimizar energía y arranque | Desactiva Fast Startup. Configura plan Alto rendimiento para evitar cambios de energía agresivos en CPU/PCIe. |
| 9 | Habilitar volcado de memoria kernel completo | Un minidump puede ocultar el verdadero driver; con un volcado completo el análisis es más preciso. |
| 10 | Monitorizar latencia DPC en tiempo real | Herramientas como LatencyMon ayudan a detectar picos antes de que ocurra el BSOD. |
Desglose detallado de cada prioridad
Actualizar controladores y firmware
Empieza siempre por el almacenamiento: versiones antiguas del controlador AHCI o RAID (especialmente los nativos Standard SATA) provocan espera activa prolongada en StorPort. Si usas controladora SAS, instala el fichero .BIN de firmware y el paquete INF más reciente. Con SSD NVMe, revisa los microcódigos del fabricante: un salto de firmware puede reducir drásticamente la latencia de escritura y con ello los DPC.
En controladoras de red, busca versiones que incorporen la instrucción Large Send Offload v2 corregida. Algunos chipsets Intel I350 e I219-V producen picos cuando el adaptador intenta descargar el cálculo de checksum IPv6.
Respecto a vídeo, aun sin salida gráfica activa, los drivers WDDM malos reservan tiempo de CPU en dxgkrnl.sys. Si no necesitas aceleración, deja el controlador “Microsoft Basic Display Adapter”.
Aplicar actualizaciones de Windows
El build 14393.7070 es ya elevado, pero comprueba que todos los cumulative updates posteriores a noviembre 2024 estén instalados. Se han publicado parches que ajustan los temporizadores precisos de los DPC y corrigen regresiones en el High Precision Event Timer.
Analizar volcados con WinDbg
Usa un símbolo de servidor: srvc:\symbolshttps://msdl.microsoft.com/download/symbols. Ejecuta .symfix y .reload antes de analizar. Si PROCESS_NAME: sqlservr.exe te despista, mira la pila de interrupciones en !dpc. El nombre del controlador que aparece con “isr” repetido suele ser el responsable.
Comprobar integridad del sistema
sfc /scannow repara bibliotecas de sistema dañadas. Si encuentra archivos ilegibles, el paso 5 (verificación de disco) cobra más fuerza. DISM rehidrata componentes desde %WinDir%\WinSxS; no lo omitas.
Verificar disco
Ejecútalo en ventana de mantenimiento nocturno. El modificador /r localiza sectores débiles; en un clúster dañino el sistema queda atrapado esperando I/O, lo que eleva IRQL y dispara el watchdog.
Prueba de memoria
Errores intermitentes de RAM provocan corrupciones que confunden al controlador de almacenamiento. Usa MemTest86 en modo UEFI y deja al menos cuatro pasadas seguidas; los fallos bit‑flip asociados a temperatura aparecen con pruebas prolongadas.
Revisar software reciente y cargas de trabajo
Herramientas de copia “hot” que instalan filtros en volsnap.sys o fltMgr.sys son sospechosas. Desinstala temporalmente el antivirus o, si no es viable, desactiva módulos de inspección HTTPS y reintenta. Compáralo con el plan de mantenimiento de SQL: el índice fill factor agresivo dispara I/O intensivo tras backups.
Optimizar energía y arranque
El plan “Equilibrado” habilita escalado dinámico; si el procesador entra en p‑states profundos, la transición de C‑state a D0 puede demorar una petición DPC. Fija “Alto Rendimiento” y, en BIOS, deshabilita C‑States excesivos (C6, C7) para pruebas.
Habilitar volcado de memoria kernel completo
En System Properties → Startup and Recovery selecciona “Kernel memory dump” y define destino en una unidad con al menos el tamaño de la RAM libre. Desactiva “Overwrite any existing file” para conservar historial.
Monitorizar latencia DPC en tiempo real
LatencyMon muestra en rojo el controlador que supera el umbral. Configura una traza circular de 1 GB con Windows Performance Recorder para capturar 30 s antes de la caída y correlacionar con el stack trace.
Variables que agravan el problema
- Virtualización: en Hyper‑V 2012 R2 con características de máquina virtual antiguas, actualiza las Integration Services. En VMware, pasa de LSI SAS a VMware Paravirtual y habilita Hardware version 17.
- Firmware antiguo de BIOS: microcódigos viejos gestionan mal la cola APIC.
- Overclock inadvertido: servidores con perfiles “Performance” elevan BCLK y afectan a la temporización del watchdog.
Buenas prácticas de prevención a largo plazo
Implementa un ciclo de vida de drivers: valida firmwares en un entorno de ensayo, documenta el número de versión y fija un recordatorio semestral para revisar boletines de seguridad. Programa pruebas automáticas de estrés (DiskSpd + CPUStres) fuera del horario de producción. Habilita Alertas en SQL Server para el Error Number 832 (páginas de búfer en espera) que a menudo antecede al 0x133.
Preguntas frecuentes
¿Es siempre culpable SQL Server?
No; SQL estaba activo y su subproceso quedó atrapado en CPU. El causante suele ser un controlador de kernel debajo del servicio.
¿Puedo ignorar los eventos ID 41 si el servidor “parece” estable?
No. Cada ID 41 implica que el estado de NTFS no se cerró correctamente, lo que degrada la consistencia con el tiempo.
¿Son fiables herramientas de “driver booster” genéricas?
Evítalas. Descarga siempre controladores del fabricante y verifica SHA‑256 contra el catálogo oficial de Microsoft.
Conclusión
El bug check 0x133 es exigente pero no aleatorio. Siguiendo el plano de acción —actualizar controladores, aplicar parches, analizar volcados y reforzar energía— la gran mayoría de reinicios desaparece. Dedica tiempo a sentar mecanismos preventivos y tu infraestructura Windows Server 2016 operará con la solidez que espera tu negocio.