Cómo solucionar errores de pantalla azul analizando archivos dump

Ver aparecer una pantalla azul de la muerte justo cuando estabas terminando un trabajo importante es una de esas cosas que te arruinan el día. De repente, el equipo se reinicia, ves un código de error raro (si necesitas interpretar los códigos de error), quizás menciona algo como pci.sys, MEMORY_MANAGEMENT o DRIVER_POWER_STATE_FAILURE, y no tienes ni idea de por dónde empezar. Y para rematar, muchas veces el sistema se recupera solo y no vuelve a salir el fallo en un buen rato, lo que complica todavía más averiguar qué ha pasado.

La buena noticia es que Windows deja mucha más información de lo que parece a simple vista. Cada BSOD genera uno o varios archivos de volcado (dump) que podemos analizar con herramientas como WinDbg, WhoCrashed o BlueScreenView para saber qué controlador, componente o archivo del sistema ha provocado realmente el problema. Combinando ese análisis con algunas pruebas de hardware y comandos de reparación del sistema, es posible diagnosticar con bastante precisión el origen de la mayoría de pantallas azules.

Qué es realmente un BSOD y por qué se produce

Cuando aparece un BSOD, lo que ha pasado por debajo es que Windows ha detectado una situación tan grave que no puede seguir ejecutándose de forma segura. En lugar de continuar y corromper datos, decide detener todo, mostrar la pantalla azul y crear un volcado de memoria con el estado interno del sistema en ese momento.

En la parte inferior de la pantalla azul suele aparecer un código de detención (bug check) y, en muchos casos, un archivo involucrado, por ejemplo pci.sys, hidusb.sys o ntfs.sys. Ese código tiene siempre cuatro parámetros asociados (valores hexadecimales) que dan más contexto sobre el fallo. Aunque en la pantalla solo vemos un resumen, estos datos quedan guardados en el sistema y en los archivos dump.

Es muy habitual que la causa del BSOD sea un controlador defectuoso, mal programado o desactualizado. De hecho, se estima que tres de cada cuatro pantallazos azules tienen que ver con drivers. El resto suelen provenir de fallos de hardware (RAM, disco, tarjeta gráfica, placa base), problemas de alimentación o de temperatura, o incluso archivos de sistema corruptos.

Hay casos en los que el error está claramente asociado a un archivo concreto, por ejemplo un driver gráfico que falla en un portátil gaming y provoca BSOD cuando se cargan los controladores de la GPU. O errores donde se indica que el componente culpable es pci.sys, el controlador del bus PCI que coordina la comunicación entre el hardware y Windows.

Dónde se guardan los archivos dump del BSOD

Cada vez que el sistema se encuentra con un error crítico, Windows crea uno o varios archivos de volcado en los que guarda información del fallo. Lo normal es que tengas al menos un minidump en la ruta C:\Windows\Minidump. Estos archivos suelen tener nombres con fecha, lo que permite localizar cuál corresponde al último pantallazo azul.

Además del minidump, puede generarse un volcado más grande (kernel o completo) que se guarda en C:\Windows\MEMORY.DMP. Este fichero es más pesado pero ofrece más detalle para una depuración en profundidad con herramientas avanzadas como WinDbg.

En algunas herramientas de diagnóstico o asistentes de error de Windows, también se utilizan ficheros temporales almacenados en rutas del usuario, por ejemplo en C:\Users\TuUsuario\AppData\Local\Temp, donde se recopila información adicional sobre el cuelgue para informes automáticos.

Si quieres que la pantalla azul no desaparezca sola, es recomendable desactivar el reinicio automático. Desde las opciones avanzadas de sistema puedes quitar la casilla de Reiniciar automáticamente en caso de error. Así tendrás tiempo para anotar el código de detención y asegurarte de que se genere el volcado al 100 %.

Interpretar un BSOD analizando los archivos dump con WinDbg

La forma más potente de entender un pantallazo azul es cargar el archivo dump en las herramientas de depuración de Microsoft. Con ellas podemos ver exactamente qué código se estaba ejecutando, qué controlador estaba implicado y qué parámetros tenía el error, en lugar de quedarnos solo con el mensaje genérico que sale en pantalla.

Microsoft ofrece las Debugging Tools for Windows como parte de su kit de desarrollo. Dentro de ese paquete encontramos WinDbg, el depurador principal que permite abrir volcados tanto de modo usuario como de modo kernel. Hay versiones para sistemas de 32 y 64 bits, así que hay que descargar la adecuada para tu instalación de Windows.

Una vez instalado, basta con ejecutar WinDbg, ir al menú File > Open Crash Dump y seleccionar el minidump más reciente en C:\Windows\Minidump. El programa cargará el archivo, consultará los símbolos (puede tardar un rato la primera vez) y mostrará una gran cantidad de información técnica sobre la causa del BSOD.

En la ventana de comandos de WinDbg puedes usar la extensión !analyze -v, que realiza un análisis detallado del volcado. Entre otros datos, verás el bug check, sus cuatro parámetros, y una línea muy interesante que suele decir algo como «Probably caused by: xxxx.sys». Ese archivo, normalmente un controlador, es el principal sospechoso del cuelgue. Para ejemplos de códigos y su interpretación también puedes consultar casos concretos como el error 0x0000000A.

En ciertos escenarios, el propio depurador muestra ejemplos como un bugcheck 0x9F (DRIVER_POWER_STATE_FAILURE) con parámetros similares a {3, ffffe000…, fffff803…, ffffe000…}, indicando que el controlador hidusb.sys (relacionado con dispositivos HID USB) ha provocado el fallo al gestionar un cambio de estado de energía. Esta información es oro puro para saber qué componente atacar primero.

Otras herramientas para analizar dumps sin complicarse la vida

No todo el mundo quiere pelearse con WinDbg y comandos avanzados. Por suerte, hay utilidades más sencillas que leen los mismos archivos de volcado y muestran un resumen comprensible, ideal para usuarios domésticos o técnicos que quieren ir rápido sin perderse en detalles de bajo nivel.

Una de las más conocidas es WhoCrashed. Esta aplicación analiza los minidumps y presenta un informe en lenguaje más humano, indicando qué dispositvo o driver es el más probable causante del crash. Traduce errores poco descriptivos del tipo IRQL_NOT_LESS_OR_EQUAL o similares y señala el ejecutable o archivo .sys implicado.

WhoCrashed permite ver un histórico de fallos, fechas de cada cuelgue y explicación breve de cada uno. Cuando ves, por ejemplo, que tres BSOD diferentes apuntan al mismo driver de red, controlador gráfico o módulo de antivirus, tienes ya una pista clara de por dónde empezar a desinstalar, actualizar o revisar.

Otra herramienta muy útil es BlueScreenView. Este programa escanea automáticamente todos los minidumps generados por Windows y los lista en una tabla con datos como la fecha, el código de error, los cuatro parámetros y los controladores cargados en el momento del fallo.

BlueScreenView marca en rojo los drivers que estaban presentes en la pila cuando se produjo el crash, lo que facilita localizar qué archivo .sys es sospechoso. También muestra el nombre del producto, la descripción, la versión del archivo, etc., lo que ayuda a identificar si corresponde a un driver de la placa base, de la tarjeta gráfica, de un USB concreto, y así sucesivamente.

Uso de Driver Verifier para cazar controladores problemáticos

Como buena parte de los BSOD se deben a drivers defectuosos, Windows incluye una herramienta específica para estresarlos y sacar a la luz comportamientos incorrectos. Se llama Driver Verifier y viene integrada en el sistema operativo, lista para usarse desde cualquier equipo Windows.

Para abrirla basta con escribir verifier en una consola o en el cuadro de búsqueda. Se abrirá un asistente en el que puedes crear una configuración estándar o personalizada. Una opción interesante es seleccionar los controladores no firmados, ya que suelen ser los más propensos a dar problemas, especialmente si proceden de fuentes poco fiables.

Driver Verifier añade comprobaciones adicionales al código de los drivers (uso de memoria, gestión de IRQL, etc.) y, si detecta un comportamiento ilegal, provoca de forma deliberada un BSOD con información específica para que el fallo pueda investigarse. Por eso es recomendable activar únicamente los controladores que quieras examinar, para evitar un impacto excesivo en el rendimiento del sistema.

Esta herramienta está más orientada a desarrolladores y técnicos, pero también puede servir para diagnosticar un equipo doméstico rebelde donde los pantallazos azules apuntan siempre a controladores de terceros o a software mal integrado.

Analizar códigos de detención y parámetros del bug check

Cada tipo de pantalla azul viene identificado por un nombre simbólico (por ejemplo DRIVER_POWER_STATE_FAILURE, MEMORY_MANAGEMENT, IRQL_NOT_LESS_OR_EQUAL…) y un valor numérico (BugCheck code) como 0x9F, 0x1A, 0xD1, etc. Ambos se encuentran documentados en la referencia oficial de códigos de comprobación de errores de Microsoft.

Junto a ese código aparecen cuatro parámetros hexadecimales que aportan más contexto. Estos parámetros pueden indicar la dirección de memoria implicada, el tipo de operación que falló, el objeto afectado o el estado del dispositivo. Toda esa información se muestra tanto en el depurador como en el registro de eventos de Windows.

Si no quieres abrir un dump, también puedes entrar en el Visor de eventos (eventvwr.msc), ir al registro del sistema y buscar eventos de tipo BugCheck. En las propiedades del evento verás el código de detención y sus parámetros, lo que te permite, al menos, saber qué tipo de error se produjo y buscarlo en la base de datos de Microsoft o en internet.

Cuando un depurador está conectado en modo kernel, el sistema se detiene directamente en él al producirse la comprobación de errores. En esos casos, puede que ni siquiera veas la pantalla azul tradicional. En su lugar, tendrás todos los detalles del fallo en la ventana del depurador y podrás repetir la información con comandos como .bugcheck o !analyze -v.

BSOD relacionados con la RAM y el arranque del sistema

Un motivo muy común de pantallas azules son los problemas de memoria RAM. Durante el arranque, el POST de la BIOS realiza una comprobación superficial de los módulos y, si detecta algo raro, puede impedir que el sistema arranque o provocar errores una vez que Windows está cargando. También pueden aparecer fallos en reinicios rápidos cuando la RAM no se ha descargado completamente y quedan datos corruptos residentes.

En muchos escenarios, aunque veas al principio un error de gestión de memoria, el PC acaba iniciando después de uno o dos intentos. Eso no significa que todo vaya bien: es posible que durante el uso normal aparezcan otros BSOD aleatorios o cuelgues aparentemente sin relación, todos provocados por la misma memoria defectuosa.

Además, hay que tener en cuenta que una configuración de overclock agresivo, tanto en la RAM como en el controlador de memoria del procesador (IMC), puede desencadenar fallos intermitentes de estabilidad. A veces el PC parece estable y solo falla al arrancar, o mientras el sistema intenta cargar algo crítico en memoria.

Por otro lado, aunque mucha gente sospecha primero de la placa base, un defecto serio en un slot de memoria suele evitar incluso que el equipo arranque o haga POST, de modo que en muchos casos los problemas de BSOD asociados a Memory Management apuntan más a módulos dañados, configuraciones incorrectas o overclock inestable.

Cómo comprobar la memoria RAM cuando aparecen BSOD

Lo primero que conviene hacer si sospechas que la memoria puede estar implicada en tus pantallazos azules es ejecutar una prueba específica de RAM. Windows incluye su propia herramienta y, además, existen utilidades de terceros mucho más exhaustivas que se ejecutan antes de que cargue el sistema operativo.

La opción integrada en el sistema se llama Diagnóstico de memoria de Windows. Puedes abrirla escribiendo «Diagnóstico de memoria» o «mdsched» en el buscador. Al ejecutarla, te ofrecerá reiniciar el equipo inmediatamente para hacer la prueba, o bien programarla para el próximo inicio. Si ya estás sufriendo BSOD, lo más recomendable es reiniciar ahora y lanzar el test.

Durante el reinicio verás una pantalla azul y gris con la herramienta funcionando. Permite elegir entre varios modos de comprobación: Básico (rápido pero poco profundo), Estándar y Extendido. Si quieres ir sobre seguro, es mejor seleccionar al menos el modo Estándar, o directamente el Extendido si no te importa que tarde bastante más.

Cuando la prueba termine, Windows se reiniciará de nuevo y, al iniciar sesión, deberías ver una notificación con el resultado del análisis. Si indica que se han detectado errores de memoria, es muy probable que tengas uno o varios módulos estropeados y toque plantearse su sustitución.

Para localizar exactamente qué módulo falla, puedes apagar el equipo, quitar uno de los sticks de RAM y repetir las pruebas módulo a módulo. Si el sistema va perfecto con uno y se vuelve inestable al poner el otro, ya tienes identificado al culpable y solo tendrás que reemplazar esa unidad por otra con las mismas especificaciones compatibles con tu placa base.

Memtest86 y otras pruebas avanzadas de RAM

Si la herramienta de Windows no muestra fallos pero sigues teniendo pantallazos azules sospechosos, conviene usar un test de memoria más completo como Memtest86. Esta utilidad se ejecuta desde un pendrive USB de arranque, de forma que la comprobación se hace antes de cargar el sistema operativo y con la RAM totalmente libre.

El procedimiento típico es descargar la imagen de Memtest86, grabarla en una memoria USB, seleccionar en la BIOS el arranque desde ese dispositivo y dejar que el programa realice varios pases. Va repasando todas las direcciones de memoria, aplicando distintos patrones de lectura y escritura para intentar forzar errores que una prueba superficial podría pasar por alto.

Si Memtest86 o el diagnóstico de Windows muestran errores, es casi seguro que hay un problema físico en la RAM o que el overclock es excesivo. En ese caso es recomendable desactivar cualquier perfil XMP/EXPO o frecuencia personalizada y volver a las especificaciones de fábrica para repetir las pruebas y ver si la inestabilidad desaparece.

También puedes repetir el mismo método de prueba por módulos individuales, arrancando el PC solo con un stick cada vez y dejando que Memtest86 haga su trabajo. Es lento, pero muy efectivo para aislar el componente defectuoso y olvidarte de BSOD recurrentes relacionados con la memoria.

Revisar hardware físico: RAM, discos, gráfica y refrigeración

Aunque los dump files den mucha información, nunca está de más echar un vistazo físico al interior del equipo. Un simple conector flojo, polvo acumulado o un disipador mal montado puede desencadenar errores de todo tipo, incluidos pantallazos azules que a priori parecen misteriosos.

Empieza por asegurarte de que todas las conexiones internas están firmes: módulos de RAM bien encajados, cables SATA y de alimentación sin holguras, tarjeta gráfica asentada en su slot PCIe, etc. Cualquier falso contacto puede hacer que un dispositivo desaparezca momentáneamente y cause errores en los controladores.

La temperatura también es un factor clave. Un procesador o una gráfica que se calientan en exceso pueden provocar cuelgues, reinicios y pantallas azules. Conviene limpiar el polvo del interior, revisar que los ventiladores giran correctamente y que el disipador del procesador está bien fijado con su pasta térmica renovada si lleva muchos años puesta.

Si sospechas de un disco duro o SSD, puedes utilizar herramientas como chkdsk y las utilidades del propio fabricante para comprobar sectores dañados y el estado SMART, además de revisar errores como WHEA Uncorrectable Error. En casos extremos, por ejemplo en un RAID 0 donde se desconecta un disco de golpe, el BSOD puede apuntar a problemas de hardware relacionados con la tabla de archivos NTFS y dejar claro que la raíz está en el almacenamiento.

Desde el Administrador de dispositivos (devmgmt.msc) puedes revisar si hay dispositivos con iconos de advertencia amarillos. Esos símbolos indican que el sistema ha detectado conflictos o controladores problemáticos. Haciendo clic derecho podrás intentar actualizar drivers, deshabilitar temporalmente el dispositivo o ejecutar el solucionador de problemas integrado.

Comprobación y reparación de archivos de sistema

Cuando las pruebas de memoria salen limpias y el hardware parece en orden, hay que empezar a mirar hacia Windows en sí. Un archivo de sistema corrupto o dañado puede causar desde errores leves hasta BSOD completos, especialmente durante el arranque o al cargar determinados controladores.

Windows incorpora varios comandos para examinar y reparar tanto la imagen del sistema como los archivos individuales. Una combinación muy efectiva es usar primero DISM para revisar la imagen y después SFC para comprobar la integridad de los ficheros. Todo esto se hace desde una consola con privilegios de administrador.

Para empezar, abre el Símbolo del sistema como administrador y ejecuta los siguientes comandos uno detrás de otro, esperando a que terminen antes de lanzar el siguiente:

DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /RestoreHealth
SFC /scannow

DISM se encarga de revisar y, si es necesario, reparar la imagen de Windows que se usa como base para restaurar componentes. Una vez que la imagen está sana, SFC analiza cada archivo de sistema y, si detecta alguno corrupto, lo reemplaza automáticamente. Es un proceso que puede tardar, pero soluciona muchos problemas de estabilidad relacionados con BSOD aparentemente aleatorios.

Además de DISM y SFC, resulta interesante ejecutar un análisis de disco con chkdsk /f /r. Este comando revisa la estructura lógica del disco, marca sectores defectuosos y reubica datos si es posible. Como no puede realizar todas las operaciones con Windows arrancado, te preguntará si quieres programar la comprobación para el siguiente reinicio, a lo que deberías responder que sí.

Errores Memory Management y otras pantallas azules persistentes

Los BSOD de tipo MEMORY_MANAGEMENT son de los más temidos porque pueden tener múltiples orígenes. Pueden venir de un módulo de RAM defectuoso, de un controlador que gestiona mal la memoria, de un overclock agresivo o de corrupción en archivos de sistema. De ahí que sea tan importante seguir un proceso ordenado de diagnóstico: comprobar RAM, revisar hardware, pasar herramientas de reparación y, si nada funciona, plantear cambios más drásticos.

Si tras todas las pruebas de memoria y de sistema sigues experimentando este tipo de pantallazos, es buena idea probar con otro kit de RAM diferente, aunque sea prestado, para descartar al 100 % que el problema está en los módulos actuales. También puedes resetear la BIOS a valores por defecto, desactivar perfiles de overclock y asegurarte de que las frecuencias y voltajes están dentro de las especificaciones oficiales del procesador y la placa.

En escenarios muy rebeldes, el origen puede estar en el controlador de memoria integrado en la CPU (IMC), especialmente cuando se trabaja con memorias de muy alta frecuencia o con configuraciones fuera de lo soportado oficialmente. A veces se soluciona subiendo ligeramente el voltaje correspondiente; en otras, toca bajar la velocidad de la RAM para estabilizar el conjunto.

Como último cartucho antes de volverte loco, siempre queda la opción de restaurar o reinstalar Windows. Si tras una instalación limpia sigues viendo los mismos errores de memoria, ya puedes centrarte casi con total seguridad en hardware (RAM, CPU o placa) como responsables principales.

Impacto de las actualizaciones de Windows en los BSOD

Windows está diseñado para funcionar en un abanico enorme de configuraciones de hardware, a diferencia de sistemas más cerrados como macOS. Eso implica que una actualización que va perfecta en un equipo puede provocar inestabilidad en otro con drivers antiguos, BIOS desactualizada o componentes muy particulares.

No es raro que una pantalla azul empiece a aparecer justo después de instalar un parche concreto de Windows Update. Si has detectado esa relación temporal, puede ser una buena idea revisar el historial de actualizaciones y desinstalar la última que se instaló antes de que empezaran los problemas.

Para ello ve a Configuración > Actualización y seguridad > Windows Update y entra en Ver historial de actualizaciones > Desinstalar actualizaciones. Allí verás una lista con todas las actualizaciones instaladas y su fecha. Identifica la más reciente, haz clic derecho sobre ella y elige Desinstalar.

Cuando termine el proceso, conviene reiniciar el equipo aunque Windows no lo pida expresamente. Así te aseguras de que se limpian todos los restos de esa actualización y de que el sistema arranca con el estado anterior. Si los BSOD desaparecen tras quitar un parche, ya tienes claro qué lo estaba provocando y puedes decidir si esperas a un nuevo parche o buscas un controlador actualizado que lo haga compatible.

Consejos adicionales para técnicos y desarrolladores

Si te dedicas al desarrollo de controladores o software muy cercano al sistema, tarde o temprano te encontrarás con pantallas azules provocadas por tu propio código. En ese contexto, la herramienta esencial es el depurador de kernel (WinDbg en modo kernel) conectado a la máquina de pruebas, ya sea por red, USB o puerto serie.

Cuando se produce un bug check en estas condiciones, el sistema no muestra necesariamente la pantalla azul al usuario, sino que se detiene dentro del depurador con toda la información del error disponible al instante. A partir de ahí puedes poner breakpoints antes del punto crítico, revisar la pila de llamadas, examinar estructuras internas y corregir el código que lleva a la violación.

También conviene apoyarse en herramientas como Driver Verifier para forzar escenarios extremos de consumo de memoria y uso de recursos. Si tu controlador no pasa bien esas pruebas, es cuestión de tiempo que un usuario real acabe sufriendo un BSOD por tu culpa, así que es mejor provocar y corregir esos fallos en laboratorio.

Para problemas que no dependen de tu propio código, lo ideal es aislar y retirar el componente de software o hardware que realmente esté causando el problema. Muchas veces basta con procedimientos básicos de diagnóstico: revisar fechas de archivos, volver a instalar controladores, desactivar programas de terceros (por ejemplo Voicemeeter) y utilizar herramientas como Sysinternals, el Visor de eventos o monitores de red para acotar la causa real.

Al final, entender y analizar los archivos dump de un BSOD te permite pasar de un simple «el PC se ha colgado» a saber si el culpable es un driver concreto, una RAM defectuosa, un disco con sectores dañados, una actualización conflictiva o un overclock pasado de rosca; con esa información en la mano, las posibilidades de devolver la estabilidad al equipo y evitar que el pantallazo azul se convierta en tu nuevo compañero habitual aumentan de forma notable.