BSOD 0x7F Double Fault en Windows Server 2019 con dns.exe y epfw: diagnóstico y solución

¿Tu servidor con Windows Server 2019 reinicia con UNEXPECTEDKERNELMODE_TRAP (0x7F) y parámetro 1 = 0x8 mientras el proceso activo es dns.exe? Este artículo guía el diagnóstico y la mitigación, con foco en un posible filtro de red/seguridad (epfw, común en ESET) y buenas prácticas para estabilizar la carga DNS.

Índice

Resumen del caso

Entorno con Windows Server 2019 (build 17763), rol DNS, ejecución bajo hipervisor, y caídas esporádicas con bugcheck UNEXPECTEDKERNELMODE_TRAP (0x7F). El primer argumento del bugcheck es 0x8, que corresponde a double fault. El volcado identifica al proceso dns.exe y la traza muestra un módulo epfw al final de la pila, lo que sugiere intervención de un filtro de seguridad en la ruta de red. Se solicita una ruta de diagnóstico y una solución reproducible.

Síntomas y contexto

Reinicio inesperado del servidor con pantalla azul.
Código de detención: UNEXPECTEDKERNELMODE_TRAP (0x7F).
Arg1 = 0x8 indicando double fault o desbordamiento de pila en kernel.
Proceso activo: dns.exe durante o inmediatamente antes de la caída.
Presencia de controladores de filtrado de red/seguridad; aparece epfw en la pila.
Máquina virtual, con herramientas de integración instaladas.

Causa probable

En una línea: double fault por desbordamiento de pila del kernel o error en un controlador en modo kernel —muy probablemente un filtro de red/seguridad (p. ej., epfw)— activado bajo carga del servicio DNS. Mucho menos probable: hardware defectuoso o un fallo del propio sistema operativo.

Significado del bugcheck

El bugcheck 0x7F es un atrapamiento inesperado en modo kernel. El argumento 1 con valor 0x8 denota un double fault, que suele generarse cuando una excepción ocurre mientras se maneja otra, sin pila válida para continuar (patrón típico de desbordamiento de pila o corrupción de contexto). En servidores DNS, un filtro de red en profundidad (firewall, EDR, inspección SSL/HTTP, DPI) puede introducir rutas de llamada más largas y consumo de pila adicional.

Indicador	Interpretación práctica	Acción sugerida
0x7F con Arg1 = 0x8	Double fault / stack overflow en kernel	Revisar filtros, reducir profundidad de llamadas, habilitar dumps de kernel
Pila termina en `... → epfw+0x62c7`	Filtro de seguridad en la ruta de ejecución	Actualizar, deshabilitar o desinstalar temporalmente para aislamiento
Proceso activo `dns.exe`	Activación bajo tráfico DNS	Reproducir con carga controlada, revisar WFP, capturas ETW

Acciones inmediatas

Aislar o actualizar el controlador de seguridad. Actualiza el producto asociado a epfw (habitualmente ESET Endpoint/Server Security). Si no es posible de inmediato, desactiva temporalmente el módulo de firewall/inspección o desinstala para probar estabilidad. Reinicia y monitoriza.
Aplicar actualizaciones del sistema. Instala la última actualización acumulativa (LCU) y el último servicio de pila (SSU) de Windows Server 2019 en ventana de mantenimiento.
Reducir la cadena de filtros. Evita convivir con múltiples filtros simultáneos en la ruta de red (firewall, EDR, DLP, backup en línea). En servidores con rol DNS, mantén solo lo imprescindible.
Actualizar el stack de red de la máquina virtual. Actualiza el adaptador de red virtual (vmxnet3 o sintético), VMware Tools o componentes de integración de Hyper‑V, y aplica parches al host de virtualización.
Verificaciones de hardware o del host. Si es físico, test de RAM/CPU/NIC. En entornos virtuales, revisa en el hipervisor los eventos de memoria/CPU y posibles overcommit.

Procedimiento recomendado

Recopilar evidencias

Configura kernel memory dump (el minidump limita el análisis).
Asegura archivo de paginación en la unidad del sistema (tamaño administrado por el sistema o adecuado para volcados de kernel).
Registra hora del incidente, carga y cambios recientes en drivers/firmware.

:: Confirmar tipo de volcado (2 = Kernel)
wmic RECOVEROS get DebugInfoType

:: Establecer volcado de memoria del kernel
wmic RECOVEROS set DebugInfoType = 2

:: Verificar que el volcado <span>&lt;</span>SystemRoot<span>&gt;</span>\MEMORY.DMP se genere
reg query "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl"

:: Habilitar reinicio y registro
bcdedit /set {current} recoveryenabled Yes
bcdedit /set {current} bootstatuspolicy IgnoreAllFailures

Reducir variabilidad

Antes de experimentar, congela el estado: desactiva tareas intensivas, cesa cambios no relacionados y captura una línea base (rendimiento, conexiones DNS, latencias, uso de pila si es posible).

Aislamiento del filtro de seguridad

La experiencia muestra que los filtros de red profundos pueden agotar pila en escenarios de recursión/proxy DNS. Procede así:

Actualiza a la última versión disponible del producto asociado a epfw.
Si no puedes actualizar, deshabilita módulos de firewall/IDS/inspección de tráfico y prueba estabilidad.
Como último recurso de diagnóstico, desinstala temporalmente el producto y valida si cesan las caídas.

:: Enumerar controladores de red y filtros cargados
fltmc
sc query type= driver state= all

:: Registrar estado de WFP (útil para soporte del fabricante)
netsh wfp show state &gt; C:\Temp\wfp_state.txt

Actualizar sistema operativo

Aplica la LCU/SSU más recientes para Windows Server 2019. Reinicia en ventana y verifica:

Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

Actualizar pila de red en virtualización

En VMware: actualiza vmxnet3, VMware Tools y parches del host ESXi.
En Hyper‑V: verifica la versión de los Integration Services y el switch virtual.
Valida offloads y funcionalidades avanzadas; si sospechas de interacción, prueba deshabilitando temporalmente ciertas offloads.

Get-NetAdapter | Format-Table Name, Status, DriverInformation
Get-NetAdapterAdvancedProperty -Name "*" | Sort-Object Name

:: Ejemplo de prueba (revertir si no hay mejora)
Disable-NetAdapterChecksumOffload -Name "Ethernet" -TcpIPv4 -TcpIPv6 -UdpIPv4 -UdpIPv6

Verificación de hardware o del host

Si es físico: ejecuta diagnósticos de memoria, estresa CPU y revisa controladoras/NIC.
Si es VM: comprueba ballooning excesivo, overcommit y alertas del host.

Confirmación de la causa con próxima caída

Para elevar la precisión del diagnóstico:

Cambia a volcado de kernel (ya cubierto arriba).
Usa Driver Verifier de forma dirigida contra controladores sospechosos (por ejemplo epfw.sys). Ejecuta en ventana de mantenimiento, pues puede forzar BSOD de diagnóstico.

:: Activar Verifier para un controlador concreto
verifier /standard /driver epfw.sys

:: Comprobar estado
verifier /query

:: Desactivar Verifier
verifier /reset

Si el incidente reaparece, captura y conserva:

MEMORY.DMP o minidumps de %SystemRoot%\Minidump.
Registro de eventos del sistema y de aplicaciones exportados.
Estado de WFP (netsh wfp show state) y lista de controladores (fltmc, sc query).

Guía de análisis en WinDbg

Abre el volcado y ejecuta un análisis básico. Observa el patrón de pila y la proximidad de llamadas de filtros de red.

!analyze -v
r
kv
!thread
!process 0 1
!locks
lmv m epfw*

Ejemplo ilustrativo de un trazo compatible con el caso:

DRIVERIRQLNOTLESSOR_EQUAL (NO)
UNEXPECTEDKERNELMODE_TRAP (7f)
Arg1: 0000000000000008, EXCEPTIONDOUBLEFAULT
...
STACK_TEXT:
nt!KiDoubleFaultAbort
nt!KeBugCheckEx
nt!ExAllocatePoolWithTag
epfw+0x62c7
tcpip!FlSendNetBufferLists
ndis!NdisFSendNetBufferLists
dns!UnknownWorkItem
...

Para evaluar uso de pila y contextos:

!stackusage
!walkstack
.kn

Si sospechas de IRPs o llamadas filtradas:

!irpfind -e epfw
!wfpn

Revisión de filtros y cadena de controladores

Enumera filtros del Windows Filtering Platform y captura el estado para soporte del fabricante. Considera reducir temporalmente la cadena a lo mínimo viable para el rol DNS.

netsh wfp show state
netsh wfp capture start file=C:\Temp\wfp_cap.cab
:: Reproducir carga DNS...
netsh wfp capture stop

:: Captura de red con trazas de kernel
netsh trace start capture=yes scenario=NetConnection tracefile=C:\Temp\nettrace.etl
:: Reproducción...
netsh trace stop

:: Monitoreo de nivel paquete (útil y ligero)
pktmon filter add --udp --port 53
pktmon start --etw -p 0 -l real-time
:: Reproducir y observar
pktmon stop
pktmon format PktMon.etl -o dns.pcapng

Buenas prácticas y prevención

Mantén el rol DNS en servidores con mínimo software de terceros en kernel.
Aplica las exclusiones y recomendaciones del proveedor de seguridad para AD/DNS.
Mantén Windows y el software de seguridad actualizados y probados con las políticas de tu entorno.
Evita convivir con múltiples filtros redundantes en la ruta de red del servidor.
Planifica ventanas de mantenimiento y caminos de rollback antes de cambios de drivers.

Checklist rápido

¿Volcado configurado como kernel y verificado?
¿Actualizado Windows Server 2019 a la última LCU/SSU?
¿Actualizado o aislado el filtro epfw u otros drivers de seguridad?
¿Reducida la cadena de filtros al mínimo?
¿Actualizado NIC virtual y herramientas de integración?
¿Capturado estado WFP y registros para trazabilidad?
¿Ejecutado Driver Verifier de forma dirigida si es necesario?

Preguntas frecuentes

¿Puede ser hardware? Sí, pero en VM es menos probable. Aun así, revisa RAM/CPU/NIC si es físico y el host si es virtual.

¿Por qué aparece dns.exe? Porque la carga DNS y sus llamadas de red activan la ruta donde opera el filtro. El proceso activo no implica culpabilidad directa del servicio DNS.

¿Puede ser un error de Windows? Siempre es posible, pero el patrón de double fault y la presencia de un filtro al final de la pila lo hacen menos probable en comparación con un controlador de terceros.

¿Es seguro usar Driver Verifier? Úsalo con cautela y en mantenimiento. Puede forzar una caída de diagnóstico más explícita, valiosa para confirmar el driver.

Plantillas de comandos

:: Exportar eventos
wevtutil epl System C:\Temp\System.evtx
wevtutil epl Application C:\Temp\Application.evtx

\:: Listar controladores firmados y fechas
pnputil /enum-drivers > C:\Temp\drivers.txt

\:: Inventario de controladores en PowerShell
Get-CimInstance Win32\_PnPSignedDriver |
Sort-Object DriverDate -Descending |
Select-Object DeviceName, DriverVersion, DriverDate, Manufacturer |
Out-File C:\Temp\drivers\_inventory.txt

\:: Estado de servicios relacionados
sc queryex dns
sc query type= driver | findstr /i "epfw ndis tcpip"

\:: Registro de red básico
Get-NetTCPConnection | Group-Object State | Format-Table Count, Name

Indicadores para escalar al fabricante

Versión exacta del producto de seguridad y del controlador (lmv m epfw* en WinDbg).
Archivos de volcado y salida de !analyze -v.
Estado WFP y trazas netsh trace/pktmon con marcas de tiempo.
Build de Windows (build 17763) y nivel de parche.
Topología de red y políticas aplicadas al servidor DNS.

Matriz de acciones y riesgos

Acción	Objetivo	Comando o ubicación	Riesgo	Cuándo revertir
Actualizar o deshabilitar módulo `epfw`	Reducir profundidad de llamadas y consumo de pila	Consola del producto / `sc`	Impacto temporal en inspección de tráfico	Si no hay cambio o afecta a la seguridad
LCU/SSU más recientes	Corregir defectos conocidos del kernel	Windows Update o catálogo offline	Reinicio requerido	Si aparece regresión tras parche
Actualizar herramientas de virtualización	Corregir interacción NIC/stack	Instalador de Tools o Integration Services	Breve corte de red	Si se observa inestabilidad nueva
Driver Verifier dirigido	Forzar evidencia del controlador defectuoso	`verifier`	Posible BSOD de diagnóstico	Tras obtener volcado suficiente

Diferencias entre físico y virtual

Virtual: menor probabilidad de fallas físicas directas; revisar sobreasignación, latencias del host, y versión de paravirtualización.
Físico: ejecuta pruebas de RAM extendidas, verifica NICs, firmware y controladoras.

Lecciones aprendidas

El rol DNS es sensible a inserciones profundas en la ruta de red; menos es más en kernel.
Los double faults suelen esconder desbordamientos de pila por cadenas de llamadas largas.
Los volcados de kernel y Verifier acortan drásticamente el tiempo de resolución.
La coordinación con el fabricante del filtro acelera una corrección definitiva.

Evidencias clave del volcado

BugCheck 0x7F con Arg1=0x8 indicando double fault o desbordamiento de pila en kernel.
Proceso activo dns.exe.
Pila que finaliza en nt!ExAllocatePoolWithTag → epfw+0x62c7 (driver de firewall/seguridad en la ruta).
Hipervisor presente, lo que reduce la probabilidad de fallo físico directo en la VM y refuerza la revisión de drivers/filtros.

Plan de cierre

Aplicar actualización o aislamiento de epfw.
Actualizar Windows y el stack de red de la VM.
Reducir la cadena de filtros a lo esencial.
Dejar configurado volcado de kernel y, si es necesario, Verifier dirigido.
Monitorear una ventana operativa completa bajo carga real.

Resultado esperado: estabilidad del servidor DNS sin nuevas caídas; en caso de persistir, volcado de kernel con evidencia clara del controlador responsable para escalar con el fabricante correspondiente.