Cómo analizar minidumps en Windows y entender tus pantallas azules

Inicio » Software » Cómo analizar minidumps en Windows y entender tus pantallas azules

Cuando aparece una pantalla azul de la muerte (BSOD) en Windows, la sensación inicial suele ser de pánico: el equipo se reinicia de golpe, el mensaje apenas se ve unos segundos y no queda claro qué ha pasado. Sin embargo, Windows deja tras de sí una pista muy valiosa: los archivos de volcado de memoria, en especial los minidumps, que podemos analizar para entender el origen del problema.

Si aprendes a interpretar estos volcados con herramientas como WinDbg, KD, CDB o incluso Dumpchk, es mucho más fácil llegar al fondo de errores de memoria, drivers conflictivos o fallos de hardware. No hace falta ser ingeniero del kernel para sacarles partido: con unos cuantos comandos clave y sabiendo dónde mirar, puedes identificar controladores culpables, códigos de error y pistas concretas sobre por qué tu equipo se estrelló.

Qué es un minidump y qué información contiene

Un minidump o volcado de memoria pequeño es un archivo que Windows genera automáticamente cuando se produce un error grave en el sistema (BSOD). Está diseñado para ocupar poco espacio, pero aun así incluye datos críticos para el diagnóstico del fallo.

Frente a otros tipos de volcados más grandes (volcado de memoria del kernel o volcado completo), el minidump contiene la cantidad mínima de información útil para entender qué pasó, sin saturar el disco. Suele pesar unos cientos de KB (por ejemplo, 256 KB) y se guarda por defecto en la carpeta %SystemRoot%\Minidump (normalmente C:\Windows\Minidump).

En este archivo se almacena, entre otros datos, el código de detención (Stop) del BSOD y sus parámetros, junto con contexto de procesos y controladores en el momento del fallo. Aunque es menos completo que un volcado de kernel, en la práctica suele ser suficiente para detectar drivers defectuosos, conflictos de hardware o errores típicos de memoria.

Cada vez que el sistema se estrella y tiene activado este tipo de volcado, Windows crea un nuevo archivo minidump con fecha codificada en el nombre. Por ejemplo: Mini022900-01.dmp sería el primer volcado generado el 29 de febrero de 2000. De esta forma se conserva un historial de errores que se puede revisar con calma.

Conviene tener claro que, debido a su tamaño reducido, un minidump puede no reflejar problemas que se gestan fuera del hilo que estaba activo en el momento del BSOD. Aun así, para la mayoría de usuarios y escenarios reales es la opción más práctica, sobre todo cuando el espacio en disco está limitado.

Tipos de volcados de memoria en Windows y por qué elegir minidumps

Windows puede generar varios tipos de archivos de volcado de memoria cuando se produce un fallo crítico. Configurarlos bien marca la diferencia entre tener información accionable o quedarte a ciegas.

Entre las opciones habituales están el volcado de memoria pequeño (minidump), el volcado de memoria del kernel y el volcado de memoria completo. El minidump es el más ligero y el más recomendable para la mayoría de equipos de usuario y entornos de productividad, porque equilibra muy bien detalle y tamaño.

Para que Windows pueda crear cualquier tipo de volcado, necesita un archivo de paginación en el volumen de arranque de al menos 2 MB. Si no existe o es demasiado pequeño, el sistema puede no llegar a guardar el volcado antes de reiniciarse.

En versiones modernas de Windows (desde Windows 2000 en adelante, incluidas Windows 10, Windows 11 y Windows Server), cada fallo genera un nuevo archivo de volcado, conservando los anteriores. Esto permite analizar una serie histórica de BSOD para detectar patrones (por ejemplo, bloqueos que siempre apuntan al mismo driver gráfico o al mismo módulo de red).

En general, el minidump es ideal si quieres:

• Evitar ficheros enormes que llenen el disco.
• Tener un registro de múltiples fallos a lo largo del tiempo.
• Analizar errores típicos causados por drivers, memoria RAM o GPU sin complicarte demasiado.

Cómo configurar Windows para generar minidumps

Antes de ponerte a depurar, es fundamental asegurarse de que Windows está configurado para crear volcados de memoria pequeños. Si no, después de un BSOD puede que no haya nada que analizar.

En las versiones de escritorio de Windows (Windows 10, Windows 11) puedes ajustar esto desde las opciones de sistema avanzadas. El procedimiento típico es muy similar entre ediciones, cambiando solo algunos textos de los menús.

Los pasos generales serían:

1. Abre el Panel de control (o escribe “ver configuración avanzada del sistema” en el buscador de Windows).
2. Entra en Sistema > Configuración avanzada del sistema.
3. En el apartado Inicio y recuperación, pulsa en Configuración.
4. En la lista desplegable de Escribir información de depuración elige la opción Volcado de memoria pequeño (256 KB) o similar.

En esta misma ventana puedes cambiar la ruta donde se guardan los minidumps. Por defecto se usa el directorio %SystemRoot%\Minidump, pero si lo prefieres puedes redirigirlo a otra carpeta o a otra unidad con más espacio.

En servidores Windows o entornos más avanzados, las opciones son equivalentes, aunque conviene revisar también las políticas de grupo o scripts de arranque que puedan modificar el comportamiento de los volcados de memoria a nivel corporativo.

Una vez que el sistema está configurado, cada vez que aparezca una pantalla azul se generará automáticamente el archivo de volcado. Después bastará con abrirlo con la herramienta de depuración elegida y arrancar el análisis.

Herramientas para analizar minidumps: WinDbg, KD, CDB y Dumpchk

La utilidad más versátil que ofrece Microsoft para analizar volcados (tanto de kernel como de usuario) es el depurador de Windows WinDbg, disponible en la Microsoft Store y también como parte del paquete de Herramientas de depuración para Windows.

WinDbg se puede usar en modo gráfico o desde la línea de comandos, y permite abrir archivos minidump, volcados completos e incluso sesiones de depuración en vivo. No importa si el volcado se generó en otra versión de Windows o en una arquitectura de CPU distinta, mientras tengas los símbolos adecuados podrás analizarlo.

Junto con WinDbg tienes otras herramientas de consola como KD (Kernel Debugger) y CDB para depuración en modo usuario. Todas comparten sintaxis de comandos y aprovechan el mismo sistema de símbolos, de modo que el cambio entre una y otra es relativamente sencillo.

Además, existe la utilidad Dumpchk.exe (Dump Check Utility), que sirve para comprobar de forma rápida que un archivo de volcado de memoria no está corrupto y se ha creado correctamente. No ofrece un análisis tan detallado como WinDbg, pero es útil como primera verificación.

Instalación de las herramientas de depuración

Para instalar WinDbg y el resto de herramientas clásicas, lo más cómodo es descargar el paquete de Herramientas de depuración para Windows desde el sitio oficial de Microsoft o usar el SDK. En la instalación, una configuración típica suele ser suficiente.

Por defecto, el instalador acostumbra a crear un directorio similar a:

C:\Program Files\Debugging Tools for Windows

En esa carpeta encontrarás ejecutables como WinDbg.exe y KD.exe, además de la documentación de ayuda en formato CHM (por ejemplo, Debugger.chm), que resulta muy útil para profundizar en comandos y opciones avanzadas.

Si prefieres la versión moderna, puedes instalar WinDbg (Preview) directamente desde la Microsoft Store. Aunque la interfaz visual cambia, la lógica de análisis, el uso de símbolos y la mayoría de comandos básicos de depuración se mantienen.

Configurar la ruta de símbolos: clave para que el análisis tenga sentido

Para que el depurador pueda interpretar correctamente un minidump, es fundamental configurar un Symbol Path adecuado. Los símbolos le permiten traducir direcciones de memoria en nombres de funciones, variables y módulos, algo esencial para entender de verdad qué está pasando.

En WinDbg (nueva versión de la Store) puedes ir a File > Settings > Debugging settings y añadir una ruta por defecto de símbolos. Una de las configuraciones más habituales es usar el servidor público de símbolos de Microsoft con una caché local, por ejemplo:

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

Con esta cadena, WinDbg descargará automáticamente los símbolos necesarios desde los servidores de Microsoft y los guardará en C:\Symbols para reutilizarlos en análisis posteriores, reduciendo tiempo y tráfico.

Ten en cuenta que, para un análisis completo, además de los símbolos públicos de Windows podrías necesitar símbolos de aplicaciones de terceros o de tus propios binarios (si desarrollas software). En ese caso deberías extender el Symbol Path para incluir las ubicaciones de esos ficheros PDB.

En el caso de depurar volcados de procesos en modo usuario, es especialmente importante tener los símbolos de la aplicación o servicio que generó el volcado, ya que sin ellos el depurador solo mostrará direcciones sin nombres legibles.

Abrir un archivo minidump con WinDbg o KD desde la consola

Si te gusta trabajar con la línea de comandos, puedes cargar directamente un volcado de memoria en el depurador usando parámetros específicos. Normalmente se cambiará primero al directorio de instalación de las herramientas de depuración.

Por ejemplo, abre una ventana de CMD con privilegios de administrador y ejecuta:

cd "C:\Program Files\Debugging Tools for Windows"

A partir de ahí, tienes dos opciones principales:

• Usar WinDbg en modo gráfico:

windbg -y SymbolPath -i ImagePath -z DumpFilePath

• Usar KD en modo consola:

kd -y SymbolPath -i ImagePath -z DumpFilePath

En estos comandos, los parámetros más importantes son:

Marcador de posición	Descripción
SymbolPath	Ruta local o cadena de servidor de símbolos (por ejemplo, srv*C:\Symbols*https://msdl.microsoft.com/download/symbols) donde el depurador encontrará los archivos de símbolos necesarios.
ImagePath	Ruta donde se encuentran los binarios (archivos .exe, .sys, .dll) que estaban cargados cuando se generó el volcado. En Windows antiguos, muchos de ellos podían estar en la carpeta C:\Windows\I386 o en el medio de instalación.
DumpFilePath	Ruta completa y nombre del archivo de volcado que quieres examinar, por ejemplo C:\Windows\Minidump\Minidump.dmp.

Un ejemplo de comando real con KD, usando el servidor de símbolos de Microsoft y un minidump en la ruta por defecto, sería algo como:

kd -y srv*C:\Symbols*https://msdl.microsoft.com/download/symbols -i C:\Windows\I386 -z C:\Windows\Minidump\minidump.dmp

Si prefieres trabajar directamente con WinDbg en modo gráfico, basta con sustituir kd por windbg en el comando, manteniendo el resto de parámetros:

windbg -y srv*C:\Symbols*https://msdl.microsoft.com/download/symbols -i C:\Windows\I386 -z C:\Windows\Minidump\minidump.dmp

También puedes abrir WinDbg primero, y después usar el menú File > Open crash dump (o CTRL+D) para seleccionar el archivo minidump que quieras analizar.

Primeros pasos de análisis: comando !analyze -v y revisión de módulos

Una vez que el volcado está cargado en WinDbg, el siguiente movimiento casi obligatorio es lanzar el comando !analyze -v, que realiza un análisis detallado y genera un informe bastante legible sobre el BSOD.

En el panel de comandos (o en la caja donde aparece “kd >”), escribe:

!analyze -v

y pulsa Intro. El depurador descargará símbolos si es necesario y, tras unos segundos, mostrará un resumen exhaustivo: código de comprobación de errores (bugcheck), parámetros, módulo sospechoso, pila de llamadas, hilo implicado, etc.

Dentro de ese informe, conviene fijarse en campos como MODULE_NAME e IMAGE_NAME, que suelen apuntar al controlador o archivo culpable. Por ejemplo, podrías encontrar algo como un driver de tarjeta gráfica AMD, un módulo de USB de Sandisk o un fichero de un antivirus/EDR como CrowdStrike en escenarios similares al incidente masivo que afectó a muchos equipos.

Si WinDbg no reconoce el módulo y ves mensajes del tipo “módulo desconocido” o te ofrece “explorar lista completa de módulos”, es posible que faltan símbolos adecuados o que el componente pertenece a un software de terceros sin símbolos públicos. En ese caso, revisar manualmente la lista de controladores cargados y sus rutas puede dar pistas (por ejemplo, drivers en C:\Program Files\VendorX).

Otra orden útil es:

!analyze -show

que muestra el código Stop y sus parámetros sin todo el detalle extendido, ideal para una primera mirada rápida si vas al grano.

Además, con el comando:

lm N T

puedes listar los módulos cargados, su estado y su ruta. Si sospechas de un determinado controlador (por ejemplo, el de la GPU, la tarjeta de red o el chipset), este listado te ayudará a confirmar versiones, fechas y ubicaciones.

Casos reales: BSOD tras instalar drivers, fallos intermitentes y hardware sospechoso

En la práctica, muchos usuarios se encuentran con pantallas azules en momentos delicados, como instalar un driver del chipset, actualizar la GPU o aplicar parches de Windows. Es relativamente frecuente que, tras un reinicio forzado, el error no se repita de inmediato, lo que complica saber si se trata de algo puntual o de un problema de fondo.

Un ejemplo típico es el de alguien que instala drivers de chipset, pulsa reiniciar y, justo en el arranque, aparece un BSOD con error de memoria. Después de volver a iniciar el sistema, todo parece correcto, pero el minidump queda en el disco. Analizándolo con WinDbg se puede comprobar si el bugcheck apunta a acceso inválido a memoria por parte del nuevo driver, conflicto con otro controlador o incluso un módulo de seguridad que ha interceptado llamadas del kernel.

En otros casos, los bloqueos se dan tras muchas horas de uso, a veces sin carga alta: el PC puede estar “tirado navegando” o con el escritorio en reposo y, de repente, otro BSOD. Un usuario con un equipo moderno (por ejemplo, Ryzen 5, placa B650, RAM DDR5, GPU dedicada potente y Windows 11) puede haber probado de todo: reinstalar el sistema, actualizar BIOS, cambiar GPU, desactivar perfiles EXPO, pasar MemTest durante múltiples ciclos, cambiar cables y aún así seguir sufriendo cuelgues cada 6-7 horas de uptime.

En escenarios así, el análisis de un conjunto de minidumps es clave. Al revisar varios volcados con !analyze -v puedes descubrir que todos apuntan al mismo patrón: quizá un driver de la controladora USB, un módulo de la tarjeta de red, una librería de un EDR/antivirus o incluso indicios de errores aleatorios que coinciden con fallos de RAM o placa base.

En el contexto de incidentes como el de CrowdStrike Falcon, muchas preguntas giraron alrededor de cómo saber si el BSOD había sido provocado por ese agente de seguridad. En esos casos, WinDbg y los minidumps permiten verificar si el módulo en cuestión aparece en la pila de llamadas o marcado como probable causante.

Crear un archivo por lotes para simplificar el análisis de minidumps

Si te toca revisar volcados con cierta frecuencia, puede resultar muy cómodo crear un script por lotes (.bat) que abra automáticamente el minidump con KD o WinDbg, ya con el SymbolPath e ImagePath configurados.

Por ejemplo, podrías crear un fichero de nombre dump.bat en la carpeta de instalación de las herramientas de depuración con un contenido similar a:

cd "C:\Program Files\Debugging Tools for Windows"
kd -y srv*C:\Symbols*https://msdl.microsoft.com/download/symbols -i C:\Windows\I386 -z %1

De esta forma, cada vez que quieras analizar un minidump, solo tienes que abrir una consola y escribir:

dump C:\Windows\Minidump\minidump.dmp

El script cambia al directorio correcto, configura el servidor de símbolos y carga el archivo que le pases como parámetro. A partir de ahí, bastará con lanzar !analyze -v y comenzar la investigación de la pantalla azul.

Depuración de volcados en modo usuario: minidumps y dumps completos

Además de fallos del sistema (BSOD), Windows puede generar archivos de volcado de procesos en modo usuario, por ejemplo cuando una aplicación se cuelga o se cierra de forma inesperada. Estos volcados se pueden analizar con las mismas herramientas: WinDbg, CDB y KD, aunque en este contexto se trabaja a nivel de proceso y no de kernel.

Para abrir un volcado de usuario con WinDbg desde línea de comandos se emplea, de nuevo, la opción -z:

windbg -y SymbolPath -i ImagePath -z DumpFileName

y es muy recomendable añadir el modificador -v para activar el modo detallado. Si WinDbg ya está abierto e inactivo, también se puede usar el menú File > Open dump file o el comando .opendump, seguido de g para comenzar la ejecución de la sesión de depuración sobre el volcado.

En el caso de CDB, el patrón es muy similar:

cdb -y SymbolPath -i ImagePath -z DumpFileName

Estos volcados de usuario pueden ser completos o minidumps. Los completos conservan mucha más memoria del proceso (pilas, heaps, regiones mapeadas), mientras que los minidumps de usuario son más ligeros y se centran en estado de hilos y call stacks. Igual que en kernel, los comandos que intenten leer memoria no incluida en el archivo fallarán o devolverán datos incompletos.

Un detalle interesante es que muchos volcados se distribuyen comprimidos en archivos .cab. WinDbg y CDB son capaces de abrir directamente un dump que esté dentro de un CAB si se especifica el nombre de este con la opción -z. No obstante, si hay varios volcados dentro del mismo CAB, el depurador solo tratará con uno de ellos; el resto de archivos (otros dumps, símbolos o ejecutables) no se procesan automáticamente.

Técnicas adicionales: extraer información específica de un minidump

Más allá del clásico !analyze -v, WinDbg ofrece una enorme colección de comandos y extensiones para extraer información muy específica de un archivo de volcado. Puedes examinar estructuras del kernel, colas de trabajo, bloqueos de hilos, listas de procesos o incluso estructuras internas de controladores concretos.

Entre las técnicas comunes están:

• Revisar la lista de procesos activos en el momento del fallo para ver qué se estaba ejecutando.
• Consultar el estado de los hilos del proceso afectado y su pila de llamadas.
• Analizar estructuras relacionadas con sincronización, bloqueos o deadlocks.
• Inspeccionar campos concretos en estructuras de datos del kernel o de un driver determinado.

La documentación oficial de WinDbg (referencia de comandos y guías de ejemplo) detalla cómo usar cada comando y qué sintaxis emplear en escenarios avanzados. Para proyectos propios, disponer de símbolos completos acelera muchísimo este tipo de análisis.

Por qué los controladores causan tantos BSOD y cómo usar Driver Verifier

Una parte considerable de las pantallas azules en Windows —se estima que en torno a un 75 % de los casos— está relacionada con drivers defectuosos, mal escritos o en conflicto. No es de extrañar: un controlador en modo kernel tiene acceso privilegiado y cualquier acceso incorrecto a memoria, puntero nulo o condición de carrera puede tumbar todo el sistema.

Para ayudar a detectar este tipo de problemas, Windows incluye la herramienta Driver Verifier (Verificador de controladores), que se ejecuta en tiempo real y vigila el comportamiento de determinados drivers. Es ideal cuando el análisis de minidumps sugiere que hay algo raro en un controlador, pero no queda claro cuál es el culpable.

Para iniciar Driver Verifier:

1. Escribe CMD en el buscador de la barra de tareas, haz clic derecho sobre Símbolo del sistema y elige Ejecutar como administrador.
2. En la consola elevada, escribe verifier y pulsa Intro.
3. Selecciona los controladores que quieres monitorizar. Lo recomendable es verificar solo un subconjunto reducido, centrado en los sospechosos, porque Driver Verifier añade carga al sistema.

El propio sistema irá sometiendo a estrés esos controladores: inyección de fallos, comprobación de IRQL, verificación de uso de memoria, etc. Si alguno se comporta mal, es muy probable que se produzca un nuevo BSOD, pero esta vez con información más clara en el minidump sobre el driver infractor.

La documentación oficial del Verificador de controladores explica en detalle qué opciones activar, cómo interpretar los nuevos volcados y cómo desactivar la herramienta cuando hayas terminado de recopilar datos.

Tras todo lo anterior, se ve que analizar minidumps en Windows no es brujería sino cuestión de combinar buena configuración de volcados, símbolos correctos, herramientas adecuadas y algo de método. Tanto si te ha explotado un driver de chipset al reiniciar, como si llevas meses peleando con pantallas azules intermitentes o quieres entender mejor incidentes como el de CrowdStrike, contar con WinDbg, KD o CDB y saber usar comandos como !analyze -v, lm o Driver Verifier te coloca en una posición mucho más fuerte para diagnosticar y solucionar el problema en vez de limitarte a reinstalar Windows a ciegas.