Guía completa de análisis de BSOD y kernel dump en Windows

Informatec Digital » Recursos » Guía completa de análisis de BSOD y kernel dump en Windows

Cuando un equipo Windows se queda clavado con una pantalla azul, no solo es molesto: suele haber información muy valiosa escondida en el volcado de memoria que nos dice qué ha pasado exactamente en el kernel. En lugar de culpar a la RAM, a la BIOS o de formatear a la primera de cambio, merece la pena aprender a leer esos datos.

Con un poco de práctica, herramientas como WinDbg y funciones como !analyze -v, .bugcheck o el uso correcto de los símbolos nos permiten pasar de “me sale un pantallazo” a “sé qué driver, recurso o dispositivo ha provocado el BSOD”. En este artículo vamos a desgranar, paso a paso y con bastante detalle, cómo analizar un BSOD mediante su kernel dump, qué tipos de volcados existen, cómo prepararlo todo y qué comandos usar para sacar chicha del análisis.

Qué es un BSOD y qué información esconde

Cuando Windows se topa con una condición que pone en riesgo la integridad del sistema y no puede recuperarse de forma segura, realiza una llamada interna al kernel llamada KeBugCheckEx. Esa llamada es la que dispara la famosa pantalla azul (BSOD: Blue Screen of Death).

KeBugCheckEx recibe siempre cinco argumentos: un código de STOP (bugcheck code) y cuatro parámetros adicionales que dan contexto técnico al fallo. Esos mismos datos son los que luego podemos consultar:

• En la pantalla azul clásica, si el sistema no está configurado para reiniciar automáticamente.
• En el registro de eventos de Windows, dentro del Visor de eventos (log de sistema).
• En el fichero de volcado de memoria (minidump, kernel dump o volcado completo), usando WinDbg y comandos como !analyze -v o .bugcheck.

Cada código de comprobación de errores (bugcheck) tiene un nombre simbólico y un valor hexadecimal asociado. Por ejemplo, el bugcheck DRIVER_POWER_STATE_FAILURE tiene el código 0x9F, mientras que RESOURCE_NOT_OWNED corresponde a 0xE3. Estos códigos y sus parámetros están documentados en la referencia de códigos de comprobación de errores de Microsoft, que conviene tener siempre localizada.

Además del código, la pantalla azul puede mostrar el nombre de un driver .sys presuntamente implicado. Si se trata de un driver de terceros (antivirus, tarjeta de red, gráfica, etc.), muchas veces ya tenemos un sospechoso claro. Si lo que aparece es un componente genérico del sistema (ntoskrnl.exe, win32k.sys…) o no aparece nada, tocará tirar de volcado de memoria y WinDbg para ir más al fondo.

Tipos de volcado de memoria en Windows

Para poder analizar un BSOD con cierta profundidad necesitamos que Windows genere un archivo de volcado de memoria (DMP) cuando se produce el fallo. Ese archivo captura el estado del sistema en el momento del error y puede ser de distintos tipos.

En las opciones de “Inicio y recuperación” (clic derecho en “Este equipo / Mi PC” → Propiedades → Configuración avanzada del sistema → pestaña “Opciones avanzadas” → botón “Configuración” en “Inicio y recuperación”) podemos elegir entre varios tipos de dump. Cada uno tiene sus ventajas e inconvenientes.

Small Memory Dump (Minidump)

El minidump es el formato más pequeño (unos 64 KB) y también el más limitado para depuración avanzada. No obstante, sigue siendo útil para obtener un diagnóstico rápido en muchos escenarios de BSOD.

En un minidump se almacena, entre otros datos:

• El mensaje de detención, el código de bugcheck y sus parámetros.
• El contexto del procesador (PRCB) del procesador que provocó el fallo.
• La información de proceso en kernel (EPROCESS) del proceso activo en el momento del crash.
• La información del hilo en kernel (ETHREAD) del thread que causó el colapso.
• La pila de llamadas en modo kernel para ese hilo (hasta 16 KB).
• Lista de controladores cargados en el momento del fallo.
• Lista de módulos cargados y descargados.
• Un bloque de datos de depuración con información básica del sistema.

Este tipo de volcado se guarda normalmente en %SystemRoot%\Minidump (por ejemplo, C:\Windows\Minidump). Para muchos casos de soporte o diagnóstico básico, un minidump bien analizado con !analyze -v puede ser más que suficiente.

Kernel Memory Dump

El kernel memory dump contiene el contenido de la memoria del kernel en el momento del crash, excluyendo los espacios de memoria de los procesos de usuario. Es un punto intermedio muy interesante entre tamaño y detalle, y suele ser la opción recomendada para diagnosticar la mayoría de BSOD.

Este volcado se guarda como MEMORY.DMP en %SystemRoot% (por defecto, C:\Windows\MEMORY.DMP). Su peso depende de la memoria usada por el kernel, pero suele ser bastante más grande que un minidump y bastante más manejable que un volcado completo.

Complete Memory Dump

El volcado de memoria completo guarda prácticamente todo el contenido de la RAM en el momento del error: kernel, procesos de usuario, etc. Es el más detallado pero también el que más espacio ocupa y el más exigente a nivel de configuración.

Para que un volcado completo sea válido hay que cumplir varios requisitos:

• El archivo de paginación debe estar en la misma partición donde está instalado Windows.
• Debe haber espacio en disco al menos igual al tamaño de la memoria física de la máquina.
• No mover el pagefile a otro disco físico si queremos evitar dumps corruptos.

En entornos de producción con mucha memoria RAM, un volcado completo puede ser poco práctico, pero para casos muy complejos o intermitentes puede marcar la diferencia a la hora de localizar el problema.

Configurar Windows para capturar y registrar BSOD

Antes de meternos en harina con WinDbg es imprescindible asegurarse de que el sistema está generando correctamente los volcados y registrando el evento del pantallazo azul.

En la ventana de “Inicio y recuperación” encontramos varias opciones relevantes:

• Escribir un evento en el registro del sistema: debe estar activada para que quede constancia del bugcheck en el Visor de eventos.
• Escribir información de depuración: aquí elegimos Minidump, Kernel memory dump o Complete memory dump.
• Ruta del archivo de volcado: por defecto %SystemRoot%\MEMORY.DMP para kernel/completo.
• Reiniciar automáticamente: conviene desmarcarla si queremos ver tranquilamente la pantalla azul y tomar nota de lo que aparece.

Para algunos fabricantes o departamentos de soporte, como en el caso de ciertos adaptadores de red, se pide al usuario que envíe el archivo de volcado. Suele estar en C:\Windows\memory.dmp y se recomienda localizarlo por fecha/hora para identificar el correspondiente al último fallo.

Si lo que queremos es poder forzar un dump incluso cuando el sistema está congelado (sin teclado ni ratón respondiendo), existe además un truco muy útil para teclados PS/2 (no USB/Bluetooth), que consiste en configurar el registro para provocar un volcado con una combinación de teclas.

Forzar un dump con teclado en caso de congelación

Para poder generar un volcado de memoria aunque la pantalla esté totalmente congelada, podemos usar la opción CrashOnCtrlScroll en teclados PS/2. Este método no es válido para teclados USB o Bluetooth.

En el registro, debemos crear o modificar la siguiente clave:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

Tras reiniciar, en cualquier momento (incluso con la pantalla congelada) podremos provocar un crash controlado y que el sistema genere el volcado de memoria pulsando la tecla CTRL derecha y, a continuación, dos veces la tecla Bloq Despl (Scroll Lock). Es muy útil para investigar cuelgues duros que no muestran BSOD por sí solos.

Introducción a WinDbg para analizar kernel dumps

WinDbg es la herramienta por excelencia de Microsoft para depuración de kernel y análisis de volcados de memoria. Está disponible gratuitamente (actualmente también en Microsoft Store como WinDbg Preview) y, aunque a primera vista asusta, para un análisis inicial de BSOD solo necesitamos manejar unas pocas opciones básicas.

Podemos instalar WinDbg en la propia máquina afectada o en cualquier otro equipo; el fichero .dmp se puede copiar por red, por USB o incluso comprimirlo en un archivo CAB. El procesador y la versión de Windows donde analicemos el dump no tienen por qué coincidir con los de la máquina que se ha colgado.

Arrancar WinDbg con un dump desde línea de comandos

Una forma clásica de abrir un volcado de memoria en WinDbg es usar la línea de comandos con el parámetro -z indicando la ruta del fichero de dump. Podemos combinarlo con otros parámetros como la ruta de símbolos o de binarios:

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

El modificador -v activa el modo detallado (verbose), que resulta muy útil para ver más contexto. Además de WinDbg, existe también kd.exe, una versión de depurador para consola que permite hacer prácticamente lo mismo pero sin interfaz gráfica:

kd.exe -z "Ruta\al\volcado.dmp" -y "Ruta\simbolos" -i "Ruta\busqueda\binarios"

Abrir un volcado desde la interfaz gráfica

Si ya tenemos WinDbg abierto en modo pasivo, podemos cargar un archivo de volcado mediante el menú File → Open Crash Dump o con el atajo Ctrl+D. Seleccionamos el archivo .dmp (o incluso un .cab que lo contenga) y WinDbg cargará la información del volcado.

Otra alternativa es lanzar WinDbg, y una vez dentro, ejecutar el comando .opendump indicando la ruta al fichero de volcado y, después, el comando g (Go) para iniciar la sesión de depuración del dump:

.opendump C:\Windows\Memory.dmp
g

WinDbg permite incluso depurar varios volcados a la vez, añadiendo varios parámetros -z en la línea de comandos o repitiendo .opendump con distintas rutas y gestionando la sesión de múltiple destino.

Configurar la ruta de símbolos en WinDbg

Sin símbolos, WinDbg va prácticamente a ciegas. Los símbolos (.pdb) contienen información de depuración sobre funciones, estructuras internas, variables, offsets, etc., y son imprescindibles para que el análisis sea fiable, sobre todo cuando trabajamos con el kernel.

Para usar los símbolos públicos de Microsoft sin tener que descargarlos a mano, la mejor práctica es configurar un symbol server apuntando al servidor oficial de Microsoft y a un directorio local de caché. Por ejemplo, podemos crear previamente una carpeta C:\symbols y después, en WinDbg, configurar la ruta de símbolos así:

SRV*c:\symbols*https://msdl.microsoft.com/download/symbols

Esto se puede hacer desde el menú File → Symbol File Path o, en WinDbg Preview, desde File → Settings → Debugging settings ajustando el “Default symbol path”. La primera vez que analicemos un dump de un sistema concreto, el depurador descargará automáticamente los símbolos necesarios desde Internet, lo que puede tardar unos minutos dependiendo de la conexión.

Hay que tener en cuenta que los símbolos públicos de Microsoft, en algunos casos, no incluyen toda la información de tipos interna, y veremos advertencias del estilo “Your debugger is not using the correct symbols” o referencias a tipos que no se pueden resolver. Para el análisis básico de BSOD suele ser suficiente con los símbolos públicos, pero si necesitamos más detalle, habrá límites.

Primer análisis: comandos básicos y bugcheck

Una vez que el volcado está cargado y los símbolos configurados, WinDbg suele mostrarnos un encabezado con información del sistema y un aviso tipo “Use !analyze -v to get detailed debugging information.”. Esa es nuestra primera parada para un análisis inicial.

El comando !analyze -v realiza un análisis automático del volcado y suele proporcionar:

• El código de bugcheck (por ejemplo, 0xE3, 0xD1, 0x9F, 0x44…).
• Los parámetros Arg1, Arg2, Arg3 y Arg4 del bugcheck.
• El módulo o driver más probable causante del fallo (Probably caused by).
• El proceso asociado en ese momento (por ejemplo, Teams.exe).
• La pila de llamadas (stack trace) del hilo que desencadenó el crash.
• Información de bucket y hashes de fallo, útil para correlacionar errores repetidos.

Por ejemplo, en un caso real de bugcheck RESOURCE_NOT_OWNED (0xE3), el análisis puede indicar que un hilo ha intentado liberar un recurso que no posee, mostrando como proceso Teams.exe y señalando a win32kbase.sys en una función como DrvEnumDisplaySettings. Eso nos da una pista de que el hilo que ha fallado estaba consultando o manipulando la configuración de pantalla desde espacio de usuario a través de la capa gráfica de Windows.

Para profundizar un poco más en los detalles del código de parada y sus parámetros, disponemos además del comando .bugcheck, que vuelve a mostrar el bugcheck y los cuatro argumentos, lo que resulta útil si queremos repetir esa información sin volver a lanzar todo !analyze -v.

Casos prácticos: drivers y conflictos típicos

El análisis de BSOD suele girar en torno a identificar drivers defectuosos o que se comportan mal, conflictos entre controladores, acceso indebido a memoria, manejo incorrecto de IRP (I/O Request Packets), etc. Veamos algunos ejemplos prácticos extraídos de casos reales para entender mejor el proceso.

RESOURCE_NOT_OWNED (0xE3) asociado a Teams y win32kbase.sys

En un escenario de Windows 10 donde tras varios días de uptime aparece un BSOD con el bugcheck 0xE3 (RESOURCE_NOT_OWNED), el volcado minikernel muestra algo parecido a:

RESOURCE_NOT_OWNED (e3)
A thread tried to release a resource it did not own.
Arguments:
Arg1: <dirección recurso>
Arg2: <dirección thread>
Arg3: 0
Arg4: 0

PROCESS_NAME: Teams.exe

STACK_TEXT:
...
win32kbase!DrvEnumDisplaySettings+0x356
win32kbase!NtUserEnumDisplaySettings+0x59
win32k!NtUserEnumDisplaySettings+0x15
nt!KiSystemServiceCopyEnd+0x28
...

Aquí el depurador indica que el bugcheck lo dispara un hilo asociado a Teams.exe, pero el código que realmente está en la pila en el momento crítico pertenece a win32kbase.sys, concretamente a la función DrvEnumDisplaySettings. Eso no significa necesariamente que Teams sea el “culpable” directo, sino que desde Teams se está llamando a una API de usuario que termina en un bug de sincronización o liberación de recursos en el subsistema gráfico.

En este tipo de diagnósticos, muchas veces la conclusión es que se trata de un bug en el stack gráfico de Windows, en un driver de vídeo concreto o en la interacción entre la aplicación y los drivers. La solución real puede pasar por actualizar controladores de la GPU, actualizar Teams o incluso aplicar parches específicos de Windows, más allá de “esperar” a que se arregle solo.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) con NotMyFault

La utilidad NotMyFault de Sysinternals es una herramienta didáctica que permite generar fallos de kernel de forma controlada para aprender a analizar pantallazos. Por ejemplo, si lanzamos desde NotMyFault la opción High IRQL fault (kernel mode) y pulsamos “Do Bug”, forzaremos un DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1).

En la pantalla azul veremos algo como DRIVER_IRQL_NOT_LESS_OR_EQUAL y, posiblemente, un driver candidato (por ejemplo, MyFault.sys, el driver que usa la herramienta). Una vez generado el volcado y abierto con WinDbg, la salida inicial puede ser similar a:

Use !analyze -v to get detailed debugging information.
BugCheck D1, {e1071800, 1c, 0, f7cda403}
*** ERROR: Module load completed but symbols could not be loaded for myfault.sys
Probably caused by : memory_corruption
Followup: memory_corruption

Aunque el depurador apunta a memory_corruption, sabemos que el causante real está relacionado con NotMyFault y su driver. Para confirmarlo, podemos seguir rastreando con comandos como !thread para ver qué llamadas hace el hilo en el momento del fallo, y !irp para analizar el IRP implicado si el bugcheck está relacionado con operaciones de I/O.

Por ejemplo, con !thread <dir_thread> podremos ver la traza de pila del hilo y localizar la instrucción donde aparece myfault+0x403, que nos indica dónde ha metido la pata el driver de prueba. A partir de ahí, podemos examinar IRP, estado de la memoria, etc., igual que haríamos con un bug real.

MULTIPLE_IRP_COMPLETE_REQUESTS (0x44) y conflictos en USB

Otro caso muy ilustrativo es el bugcheck MULTIPLE_IRP_COMPLETE_REQUESTS (0x44). Este error se produce cuando un IRP (I/O Request Packet) se completa más de una vez, normalmente porque dos drivers distintos creen que son los dueños del mismo IRP y ambos llaman a IoCompleteRequest().

El análisis con !analyze -v puede arrojar una descripción parecida a esta:

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed.
...
Arguments:
Arg1: <IRP_ADDRESS>
Arg2: 00000d75
Arg3: 00000000
Arg4: 00000000

Probably caused by : usbehci.sys

Inicialmente parece que el sospechoso es usbehci.sys, un driver de Microsoft para controladoras USB EHCI. Sin embargo, es relativamente raro que el bug lo cause realmente un driver nativo de Windows sin que haya interacción con terceros. Para ir al grano, usamos la dirección del IRP que nos ha dado el bugcheck (Arg1) y lanzamos !irp <IRP_ADDRESS>:

!irp 87e5a490
Irp is active with 3 stacks 3 is current (= 0x87e5a548)
...
> [ f, 0] 0 c0 8a055618 00000000 b69de300-00000000 Success Error
  \Driver\usbehci ax88172
Args: b70989c0 00000000 00220003 00000000

En la última línea vemos claramente la cadena \Driver\usbehci ax88172, lo que nos revela que el IRP ha pasado tanto por usbehci.sys como por un driver llamado ax88172.sys, asociado a un chipset de red USB concreto (AX88172). De esta forma, podemos concluir que el conflicto viene de ese driver de NIC USB de terceros, no del controlador EHCI genérico de Microsoft.

La solución pasa, en ese caso, por actualizar el driver del adaptador USB, sustituir el dispositivo o, si no queda otra, retirarlo. Este tipo de análisis mediante IRP es especialmente útil en BSOD relacionados con USB, almacenamiento, tarjetas de red y, en general, cualquier componente que utilice intensivamente I/O.

Comandos útiles de WinDbg en modo kernel

Más allá de !analyze -v y .bugcheck, existen varias extensiones y comandos de WinDbg que resultan muy prácticos cuando queremos profundizar un poco más en el volcado de kernel.

Algunos de los más habituales son:

• !thread: muestra información detallada sobre un hilo, incluyendo su pila de llamadas, estado, IRP asociados, etc. Permite ver las “últimas acciones” del thread que estaba ejecutándose al caer el sistema.
• !process 0 0: lista todos los procesos activos en el momento del crash. Es útil para identificar si había procesos sospechosos, servicios, EDR, antivirus, etc., corriendo en la máquina.
• !irp <dir_IRP>: analiza un IRP concreto y muestra la traza de los drivers por los que ha pasado, el comando de I/O, los flags, etc. Es clave en bugs relacionados con MULTIPLE_IRP_COMPLETE_REQUESTS y otros errores de I/O.
• !cpuinfo: proporciona información sobre el procesador (fabricante, MHz, firmas, características), útil para verificar entornos de hardware.
• !peb: muestra detalles del PEB (Process Environment Block), como nombre del equipo, ruta de instalación de Windows, número de procesadores, etc.
• !token: da información sobre tokens de seguridad, permisos y contexto de seguridad del proceso o hilo.
• .cls: limpia la ventana de comandos, como en una consola habitual.

Además, muchas extensiones específicas (por ejemplo, para sistemas de archivos, PnP, NTFS, etc.) permiten extraer aún más información de los volcados. En algunos casos, WinDbg indicará la presencia de BLACKBOX* (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON), que son bloques de datos adicionales capturados en el momento del bugcheck para facilitar el diagnóstico de áreas concretas del sistema.

Uso del Driver Verifier para cazar drivers problemáticos

Una altísima proporción de los errores de código de detención (BSOD) en Windows se deben a drivers defectuosos o mal programados. Para cazar este tipo de problemas de forma proactiva, el sistema incorpora una herramienta muy potente: Driver Verifier.

El Comprobador de controladores (Verifier) se ejecuta en tiempo real y somete a los drivers seleccionados a una serie de pruebas y estrés: verifica el uso correcto de memoria, de pools de kernel, IRQL, IRP, etc.. Si detecta que un driver hace algo indebido, puede forzar un BSOD controlado para que podamos analizar un dump mucho más claro, donde el culpable suele salir muy señalado.

Para lanzar el administrador de Driver Verifier basta con abrir un símbolo del sistema con permisos de administrador y escribir:

verifier

Desde ahí podemos escoger qué controladores queremos someter a verificación. Conviene ser prudentes: el Verifier añade sobrecarga al sistema y puede degradar el rendimiento, así que es recomendable activar la verificación solo para el mínimo número de drivers sospechosos en lugar de marcarlo todo alegremente.

Una vez que Verifier provoque un BSOD al detectar un comportamiento incorrecto, podremos analizar el kernel dump con WinDbg y, con suerte, ver claramente qué driver ha sido cazado y qué ha hecho mal. Los artículos de referencia de Microsoft sobre Driver Verifier explican en detalle las distintas opciones y estrategias de uso.

Consejos prácticos para ingenieros y técnicos

Si eres desarrollador de drivers, software que interactúa con el kernel o simplemente el técnico de referencia al que le llegan todos los pantallazos, hay algunas pautas que conviene interiorizar para no perderse en la jungla de los BSOD.

Lo primero es, cuando el error esté relacionado con código propio, usar sistemáticamente el depurador de kernel para reproducir y analizar el problema. Conectando un depurador al equipo de destino (via red, serie, etc.), un bugcheck hará que el sistema se detenga dentro del depurador en lugar de mostrar la pantalla azul directamente. Desde ahí es posible inspeccionar memoria, pilas, estructuras y corregir el código.

En otros escenarios, los bugcheck pueden deberse a drivers, hardware o software de terceros que no controlamos. En esos casos, el objetivo pasa de “arreglar el código” a aislar y mitigar el problema:

• Identificar el driver o componente de hardware sospechoso mediante WinDbg y el análisis de dumps.
• Actualizar o revertir versiones de drivers, BIOS, firmware o aplicaciones relacionadas.
• Retirar o sustituir dispositivos USB, tarjetas gráficas, adaptadores de red conflictivos.
• Apoyarse en el Visor de eventos, Sysinternals, herramientas de monitorización y análisis de red para obtener contexto adicional.

Muchos problemas aparentemente misteriosos se resuelven con procedimientos básicos de troubleshooting: revisar documentación, comprobar versiones de archivo y fechas, reinstalar componentes clave o desactivar módulos conflictivos. El análisis del volcado nos da una dirección clara hacia donde mirar y, muchas veces, nos ahorra horas de prueba y error.

También hay que recordar que, en entornos como el que provocó el incidente de CrowdStrike Falcon y otros EDR, las preguntas más habituales giran en torno a qué ha detonado el BSOD y cómo identificarlo rápido. Disponer de WinDbg correctamente configurado, con símbolos y un procedimiento claro para abrir y analizar los dumps, permite acotar en minutos lo que de otro modo puede terminar en un “formatea y reinstala” sin entender realmente la causa.

En definitiva, combinar una buena configuración de volcados de memoria, el uso disciplinado de herramientas como WinDbg, Driver Verifier y Sysinternals, y la costumbre de revisar logs y stacks de forma metódica convierte los pantallazos azules de un enemigo imprevisible en una fuente de información muy precisa sobre lo que ha fallado en el kernel, ayudándonos a tomar decisiones técnicas mucho más fundamentadas.