¡BSOD! Aprende a interpretar los pantallazos azules de Windows

Un BSOD o Blue Screen of Death (pantallazo azul de la muerte) es algo que a nadie le gusta encontrarse. Cuando lo ves sabes que algo no va bien porque, para empezar, el sistema deja de responderte y además muestra una amenazante pantalla azul con cosas que no entiendes.

Normalmente un BSOD -también conocido como STOP Error- aparece cuando un problema es demasiado grave como para continuar con la ejecución normal del sistema operativo.

Casos típicos que provoquen esta situación son los drivers de dispositivos que hemos instalado recientemente, programas que han modificado archivos de sistema o el registro de Windows, aplicaciones que o han funcionado correctamente (por ejemplo, dos driver usan la misma librería al mismo tiempo y el Kernel de Windows se proteje) y otros problemas.

Consideraciones respecto a los BSOD

Cuando tenemos una Blue Screen of Death conviene recordar lo siguiente:

• Un pantallazo azul que sucede de forma espontánea y no se repite no tiene mayor importancia.
• Se proporcionará un código STOP o código de error alfanumérico, compuesto de 4 bloques separados por comas. Dependiendo de la versión, veremos también un nombre de driver / dispositivo afectado.

• Si tenemos habilitada la opción de volcado de memoria en caso de fallo de Windows, se creará un archivo .DMP o .DUMP que nos permitirá más adelante investigar a fondo el culpable, ya que no es siempre fácil de ver.

Habilitar el volcado de memoria en Windows

Ya que estamos, vamos a comentar brevemente como habilitar este volcado, ya que si tenéis un ciclo interminable de reinicios con pantallazo azul os frustraréis y al final terminaréis formateando el equipo.

• Abriremos la ventana de Ejecutar con tecla WINDOWS + R
• Escribiremos control system

• En el Panel de Control buscaremos Configuración Avanzada de sistema y nos llevará a esta ventana:

• Tras pulsar sobre Inicio y Recuperación veremos algunas opciones. Os recomiendo dejarlas como sigue:

1. Reiniciar automáticamente: inactivo
2. Escribir información de depuración (desplegable): Volcado de memoria automático

IMPORTANTE: si tenéis habilitado el archivo de paginación de Windows es imprescindible que tengáis dicho archivo establecido en la misma partición que el propio sistema operativo (C:\Windows) para que funcione.

Métodos para diagnosticar BSOD en Windows

Empecemos ahora con un caso práctico que he investigado recientemente. Os podríais encontrar con lo siguiente:

La zona que he resaltado en rojo es la que nos indica que se está creando un archivo de volcado. Conviene como he dicho tener esta opción activa porque sin ella será casi imposible saber qué provocó el fallo.

Podremos empezar a realizar ahora los típicos pasos de diagnóstico:

• Desinstalar programas recientemente instalados
• Retirar cualquier dispositivo de hardware recién instalado
• Revertir el sistema a un estado anterior (ya sea restableciendo un backup del registro / usando Restaurar Sistema)
• Realizar un intento de arranque a prueba de fallos o un arranque limpio (desactivando todos los servicios no Windows)

Sin perjuicio de lo anterior -que evidentemente es útil cuando tenemos un sistema que se bloquea constantemente- lo que vamos a hacer es ir un poco más allá y usar unas herramientas que lean el registro DMP/DUMP previamente creado por el sistema cuando colapsó.

Herramientas útiles

• BlueScreenView: herramienta de Nirsoft que permite leer algunos datos del volcado
• Windbg: herramienta para desarrolladores de Microsoft (más potente y fiable que la anterior)
• Osronline: servicio web que nos permite leer minidumps

Leer los Minidumps

BlueScreenView

Empezaremos mostrando el primer programa. Abriremos BlueScreenView y desde el menú «File» apuntaremos a la ruta del volcado.

Típicamente, los volcados de memoria se guardan en la ruta C:\Windows\Minidump. En Windows 10 su ubicación cambia ligeramente: %systemroot%\MEMORY.DMP.

En seguida llama nuestra atención un color rojo sobre un nombre de archivo en la zona inferior. Se trata del módulo de Windows que sufrió el bloqueo. A simple vista no hay mucho más, así que con el botón derecho mostramos las propiedades de ntoskrnl.exe.

Se puede apreciar que la parada del sistema la ha provocado el kernel de Windows. Una actividad no aprobada sobre el mismo provoca que se proteja inmediatamente.

Lo malo de usar BlueScreenView es que no siempre identifica bien el objeto afectado y además nos faltan algunos datos relevantes. Tampoco ayuda el Visor de Eventos de Windows, dado que solo nos muestra la fecha del bloqueo, pero no muestra ningún dato relevante y por supuesto nada referente al volcado de memoria.

WinDbg

Entre las herramientas para desarrolladores de Windows encontraremos WinDbg, incluido dentro del SDK de Microsoft. Hay otros depuradores diferentes, pero este funciona bien y de forma simple.

Primero instalaremos el sdk. No hace falta consumir los 2,3 GB de disco que marca la imagen, porque posteriormente escogeremos los componentes y basta con instalar lo siguiente dependiendo de la versión:

• X86 Debuggers And Tools-x86_en-us.msi
• X64 Debuggers And Tools-x64_en-us.msi

Configuración previa

No es estrictamente necesario, pero conviene que antes de continuar instalemos los ficheros de símbolos del programa. Solo instalaremos los de Microsoft dado que los fabricantes no suelen darlos, pero con los de Windows suele ser suficiente. Si no hacemos esto, la herramienta descargará estrictamente los necesarios para el volcado en cuestión.

Para añadir los símbolos iremos al menú File > Symbol File Path y allí colocaremos esto:

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

Marcamos el botón reload y aplicamos los cambios.

Ahora que tenemos el programa listo, abriremos nuestro archivo .DMP. Menú File > Open Crash Dump

Veréis algo muy similar a esto:

La información hasta este punto es muy limitada, así que ejecutaremos el siguiente comando seguido de Intro para ampliarla:

!analyze -v

Aparecerán nuevos datos:

Encontraremos el nombre del proceso responsable, asignación de recursos, etc:

También encontraremos el «Symbol name» a modo de código de fallo, el nombre de módulo y demás detalles.

Osronline 

Finalmente nos queda hablar de este servicio web que, con las mismas capacidades que Windbg, nos permite obtener los datos escritos en el .DMP o .DUMP sin tener software instalado en nuestro equipo. Solo deberemos subir el fichero a la web y veremos los resultados.

El pase de diapositivas requiere JavaScript.

Conclusiones

Los métodos anteriormente comentados nos permitirán averiguar los causantes de pantallazos azules de la muerte (BSOD) además de causas de cuelgues, reinicios inesperados y problemas de ese tipo. Todo deja huella en el sistema. Si bien es cierto que muchas veces no nos darán la respuesta directamente, allanarán enormemente el camino para encontrarla y sabremos cual es el proceso, driver o librería responsable.