BSOD - Pantalla azul error Windows (BSOD: Blue Screen of Death)

Una pantalla azul de Windows (BSOD, Blue Screen of Death), un bloqueo completo del sistema o un reinicio inesperado pueden tener causas muy diferentes: controladores defectuosos, problemas de memoria, errores de hardware, incompatibilidades de software o fallos en componentes esenciales del sistema operativo.

Para identificar el origen del problema, no siempre basta con leer el mensaje que aparece en pantalla. Windows puede generar un archivo de volcado de memoria que conserva información técnica sobre el estado del sistema cuando se produjo el error. Su análisis permite investigar las circunstancias del fallo y buscar indicios que ayuden a determinar su causa.

En este artículo veremos cómo interpretar una pantalla azul, investigar los reinicios inesperados, configurar los volcados de memoria y utilizar WinDbg para analizar un caso práctico. También distinguiremos los procedimientos históricos de Windows XP y Windows Server 2003 de las recomendaciones aplicables a los sistemas actuales.

Reinicios espontáneos

En Windows XP, una causa habitual de que una pantalla azul pasara inadvertida era tener activada la opción Reiniciar automáticamente. El sistema se reiniciaba después de determinados errores críticos sin dejar tiempo para leer el código de detención.

En aquella versión, se podía desactivar desde las propiedades de Mi PC, en la pestaña Opciones avanzadas, dentro del apartado Inicio y recuperación. Bastaba con desmarcar la opción correspondiente.

En las versiones actuales de Windows, se puede acceder a una configuración equivalente desde las opciones avanzadas del sistema, en el apartado Inicio y recuperación.

Desactivar el reinicio automático permite observar el código de detención y los datos que aparecen en la pantalla azul, pero no soluciona el problema. Si el equipo continúa reiniciándose, conviene investigar otras posibilidades:

Problemas de alimentación eléctrica, fuente de alimentación o batería.
Temperaturas excesivas del procesador u otros componentes.
Errores de memoria RAM, almacenamiento o placa base.
Fallos de controladores, firmware o software que trabaja a bajo nivel.
Pérdidas de alimentación o bloqueos que impiden generar un volcado de memoria.

Que los reinicios continúen después de desactivar esta opción no demuestra por sí solo que exista un fallo grave de hardware. Para determinar la causa, es necesario reunir más información y comprobar en qué circunstancias se produce el problema.

Pantalla azul: cómo interpretar el error

Cuando Windows muestra una pantalla azul, normalmente presenta un código de detención (Stop code) que identifica la clase de error detectado. En determinadas circunstancias también puede indicar un archivo relacionado con el fallo.

Si aparece un controlador de terceros, como un archivo .sys perteneciente a un dispositivo, un antivirus o un programa que instala componentes de bajo nivel, tendremos una primera pista para investigar.

Conviene comprobar si existe una versión más reciente del controlador, si el problema comenzó después de instalar o actualizar el programa y si desaparece al retirar temporalmente el componente afectado, siempre que sea seguro hacerlo.

Sin embargo, el archivo que aparece en la pantalla azul no es necesariamente el responsable directo. Un controlador de Windows puede quedar señalado porque detecta las consecuencias de un fallo originado por otro controlador, un dispositivo defectuoso o un problema de hardware.

Si no aparece ningún archivo identificable, o si únicamente se muestran componentes de Windows, será necesario investigar el volcado de memoria. Entre los nombres que pueden aparecer en un análisis se encuentran ntoskrnl.exe y otros componentes del núcleo o de los subsistemas del sistema operativo. Su presencia no basta para atribuirles la responsabilidad del fallo.

El código de detención, sus parámetros y la pila de llamadas suelen aportar más información que el nombre de un único archivo. Por eso, cuando el error se repite o no resulta evidente su origen, conviene analizar el archivo DMP con una herramienta de depuración.

Congelaciones completas del sistema

Una congelación completa presenta una dificultad adicional: el equipo puede dejar de responder al teclado y al ratón sin llegar a mostrar una pantalla azul.

Si Windows todavía puede procesar una combinación de teclas específica, es posible provocar manualmente un error de depuración y generar un volcado de memoria. Esto permite estudiar el estado del sistema en el momento de la captura, aunque no garantiza que el volcado contenga la causa original del bloqueo.

El procedimiento requiere una configuración previa del registro y provoca deliberadamente un error crítico. Antes de utilizarlo, hay que guardar los documentos abiertos y asegurarse de que se puede reiniciar el equipo si fuera necesario.

Configurar CrashOnCtrlScroll

Windows dispone de una función de depuración que permite provocar un error mediante una combinación de teclas. La clave del registro que debe configurarse depende del controlador de teclado utilizado.

Para el controlador de teclado PS/2, la ruta es:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

Para el controlador de teclado USB estándar, la ruta es:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters

En la clave correspondiente, hay que crear un valor DWORD de 32 bits con los siguientes datos:

Nombre: CrashOnCtrlScroll.
Tipo: REG_DWORD.
Valor: 1.

Después hay que reiniciar el equipo para que el cambio entre en vigor. La configuración necesaria puede variar según la versión de Windows y los controladores instalados. En sistemas con varias rutas de teclado, puede ser necesario comprobar qué controlador recibe las pulsaciones.

Una vez habilitada la función, la combinación habitual consiste en mantener pulsada la tecla Ctrl derecha y pulsar dos veces Bloq Despl (Scroll Lock). Si el sistema puede procesar la combinación, provocará un error de detención manual y generará un volcado si la configuración lo permite.

El procedimiento puede funcionar con determinados teclados USB, pero no debe darse por supuesto en todos los teclados, controladores o dispositivos Bluetooth. Si el sistema está bloqueado a un nivel que impide procesar las pulsaciones, la combinación tampoco funcionará.

Este método no recupera el sistema ni soluciona el bloqueo; fuerza una detención para facilitar el diagnóstico. Puede provocar la pérdida de los datos que no se hayan guardado.

Documentación oficial: Forzar un bloqueo del sistema desde el teclado.

Tipos de volcado de memoria

Cuando se produce un error crítico, Windows puede guardar diferentes cantidades de información en un archivo de volcado de memoria. El tipo adecuado depende del problema que se quiera investigar, del espacio disponible y de los requisitos de la versión del sistema operativo.

Minivolcado de memoria

El minivolcado (Small Memory Dump) conserva un conjunto reducido de información sobre el error, como el código de detención, los parámetros asociados, la pila de llamadas y datos sobre los controladores implicados.

Tradicionalmente se asociaba con volcados de 64 KB, aunque el tamaño real puede variar según la versión de Windows y la información almacenada. Es útil para realizar una primera investigación y comparar varios fallos, pero puede carecer de datos suficientes para identificar la causa exacta.

En las versiones actuales de Windows, estos archivos suelen guardarse en la carpeta:

%SystemRoot%\Minidump

Volcado de memoria del kernel

El volcado del kernel conserva información del núcleo de Windows y de los componentes que se ejecutan en modo kernel, incluidos los datos necesarios para investigar muchos errores relacionados con controladores.

Suele ser una buena opción para analizar pantallas azules porque proporciona más información que un minivolcado sin necesidad de guardar toda la memoria física del sistema.

El archivo se guarda normalmente como:

%SystemRoot%\MEMORY.DMP

Volcado automático y volcado completo

El volcado automático permite a Windows gestionar determinados requisitos de tamaño del archivo de paginación para generar un volcado del kernel. No debe confundirse con el volcado completo.

El volcado completo registra el contenido de la memoria física del sistema en el momento del fallo. Puede resultar útil en investigaciones avanzadas, pero requiere más espacio y puede contener información sensible de los procesos que estaban en ejecución.

Para generar el tipo de volcado seleccionado, el sistema debe cumplir los requisitos de tamaño y ubicación del archivo de paginación o del archivo de volcado dedicado que correspondan a esa versión de Windows. Por tanto, no cualquier configuración es válida ni el archivo resultante tiene que ocupar siempre exactamente lo mismo que la memoria RAM instalada.

Para la mayoría de los usuarios que desean investigar una pantalla azul, un volcado automático o del kernel suele ser un buen punto de partida.

Documentación oficial: Opciones de los archivos de volcado de memoria.

Cómo configurar el volcado en Windows

En las versiones actuales de Windows, se puede acceder a la configuración desde las propiedades avanzadas del sistema:

Abrir las propiedades del sistema y entrar en Configuración avanzada del sistema.
En la pestaña Opciones avanzadas, localizar Inicio y recuperación y pulsar Configuración.
En el apartado de escritura de información de depuración, seleccionar el tipo de volcado deseado.
Comprobar que la unidad correspondiente dispone de espacio suficiente y que el archivo de paginación cumple los requisitos del tipo de volcado seleccionado.
Revisar la ubicación de destino y aplicar los cambios.

Las opciones disponibles y los requisitos pueden variar según la versión de Windows. Si el volcado no se genera, conviene comprobar también el espacio libre, la configuración del archivo de paginación y si el equipo pierde la alimentación antes de poder escribir los datos.

Software necesario para analizar el error

La herramienta recomendada para investigar volcados de memoria es WinDbg, el depurador de Microsoft. Permite analizar códigos de detención, examinar pilas de llamadas, consultar módulos cargados e interpretar información del núcleo y de los controladores.

Para equipos actuales, Microsoft ofrece la versión moderna de WinDbg a través de Microsoft Store. También existen distribuciones del depurador asociadas a las herramientas de desarrollo de Windows. La interfaz y algunas opciones pueden variar según la versión instalada.

Documentación y descarga oficial:

WinDbg puede ejecutarse en un ordenador distinto del que sufrió el fallo. No es necesario instalarlo en el equipo afectado, siempre que se disponga del archivo .dmp y de los archivos auxiliares que puedan resultar necesarios.

Configurar los símbolos de depuración

Para interpretar correctamente las direcciones de memoria y las funciones internas de Windows, WinDbg necesita los símbolos correspondientes a la versión del sistema que generó el volcado.

Los símbolos públicos de Microsoft permiten identificar muchas funciones y estructuras del sistema operativo. Sin embargo, los fabricantes de controladores de terceros no siempre proporcionan símbolos privados con información completa, por lo que algunos módulos pueden quedar parcialmente identificados.

Una forma habitual de configurar el servidor público de símbolos de Microsoft consiste en ejecutar estos comandos en la ventana de comandos de WinDbg:

.symfix C:\Symbols
.reload /f

El comando .symfix configura una ruta de símbolos que utiliza el servidor de Microsoft y una caché local en C:\Symbols. El comando .reload /f solicita la recarga forzada de los símbolos disponibles.

Es necesario disponer de conexión a Internet para descargar los símbolos que todavía no estén en la caché. La primera carga puede tardar más tiempo, especialmente si el depurador necesita archivos correspondientes a una versión de Windows que no se ha analizado anteriormente.

Si aparecen avisos de símbolos ausentes o incorrectos, conviene revisar la ruta configurada y comprobar si se han cargado los símbolos adecuados. Forzar la recarga no permite recuperar información privada que el fabricante del controlador no haya publicado.

Documentación oficial: Configurar la ruta de símbolos.

Abrir y analizar un archivo DMP

Una vez configurados los símbolos, abre el archivo de volcado mediante la opción correspondiente de la interfaz de WinDbg. En función de la versión, puede aparecer como Open dump file o una opción equivalente.

Selecciona el archivo .dmp y espera a que termine la carga inicial. El depurador mostrará información sobre el sistema analizado, los módulos disponibles y el estado de los símbolos.

A continuación, ejecuta el siguiente comando:

!analyze -v

Este comando solicita un análisis detallado del error. Entre los datos más útiles se encuentran:

BugCheck: código de detención y parámetros asociados.
MODULE_NAME: nombre del módulo que el análisis señala como relevante.
IMAGE_NAME: archivo de imagen asociado al módulo.
STACK_TEXT: información sobre la pila de llamadas, que puede ayudar a reconstruir la secuencia de ejecución.
FAILURE_BUCKET_ID: identificador utilizado para clasificar determinados fallos.
Followup: información orientativa sobre el seguimiento del problema.

Estos campos deben interpretarse en conjunto. El resultado de WinDbg sirve como punto de partida para investigar, pero no demuestra por sí solo que el módulo señalado sea el causante del error.

Si el análisis informa de símbolos ausentes o incorrectos, conviene revisar su configuración, recargarlos y comprobar si la información obtenida es suficiente para continuar.

Otros comandos útiles de WinDbg

Además de !analyze -v, WinDbg dispone de otros comandos que permiten profundizar en el análisis:

lm: muestra información sobre los módulos cargados que están disponibles en el contexto de depuración.
lmvm nombre_del_driver: muestra información detallada sobre un módulo concreto, como los datos de versión y su ubicación, cuando están disponibles.
k: muestra la pila de llamadas del hilo actual.
!thread: presenta información sobre un objeto de hilo. Se puede indicar una dirección concreta para examinar un hilo específico.
!process 0 0: enumera los procesos que pueden identificarse en el contexto del volcado.

Estos comandos complementan el análisis inicial y ayudan a investigar módulos, procesos y secuencias de ejecución. Su utilidad depende del tipo de volcado y de la información que se haya conservado.

Caso práctico: MULTIPLE_IRP_COMPLETE_REQUESTS en Windows Server 2003

El siguiente ejemplo procede de un análisis histórico realizado en Windows Server 2003 con Service Pack 1. El servidor actuaba como controlador de dominio y generó un volcado de memoria del kernel después de una pantalla azul.

Aunque el ejemplo utiliza Windows Server 2003 y controladores de aquella época, el método de investigación —examinar el código de detención, estudiar la pila de llamadas y analizar las peticiones de entrada/salida— sigue siendo útil para investigar errores de Windows actuales. Los nombres de los módulos, las estructuras internas y algunos comandos pueden variar entre versiones.

La pantalla azul original mostraba el error:

MULTIPLE_IRP_COMPLETE_REQUESTS (0x44)

Este código indica que se ha intentado completar una petición de entrada/salida (IRP) que ya había sido completada. En términos generales, puede producirse cuando dos controladores intentan completar la misma petición o cuando un controlador gestiona incorrectamente su finalización.

El resultado inicial de WinDbg señalaba:

Probably caused by: usbehci.sys

El archivo usbehci.sys correspondía al controlador del sistema relacionado con el controlador anfitrión USB 2.0 en aquella versión de Windows. Sin embargo, que apareciera este archivo no demostraba por sí solo que el controlador de Microsoft estuviera defectuoso.

El análisis también mostraba referencias a funciones del subsistema USB, como USBPORT_CompleteTransfer y USBPORT_DoneTransfer. Esto indicaba que el fallo se había producido durante la gestión de una transferencia USB, pero todavía era necesario examinar más información.

Examinar los detalles del error

Después de ejecutar !analyze -v, el depurador mostró el código de error, los parámetros asociados y la pila de llamadas. Entre los datos aparecía la dirección de la petición IRP implicada en el fallo:

Arg1: 87e5a490, Address of the IRP

En aquel volcado se utilizó el siguiente comando para examinar la petición:

!irp 87e5a490

Esta dirección pertenece exclusivamente a ese volcado y no debe reutilizarse para investigar otros errores. El comando !irp permite examinar la estructura de la petición y las distintas posiciones de su pila de controladores.

En la salida original aparecía una referencia a ax88172 asociada a la ruta de la petición USB. Este nombre está relacionado con una familia de adaptadores de red USB basada en controladores Ethernet de ASIX.

La referencia proporcionaba una pista relevante: el problema podía estar relacionado con la gestión de una petición USB por parte del controlador del adaptador de red, en interacción con la pila USB de Windows.

Interpretar el resultado

El análisis apuntaba a una posible interacción incorrecta entre los controladores implicados en la petición. Para confirmar esta hipótesis, habría que contrastar la información del volcado con el dispositivo instalado, la versión del controlador, los registros disponibles y, si fuera posible, nuevas pruebas controladas.

En un caso de este tipo, los pasos razonables serían comprobar el controlador del adaptador de red USB, buscar una versión compatible con el sistema operativo, revisar si el error se repite al utilizar el dispositivo y realizar pruebas con otro puerto o adaptador cuando sea viable.

La conclusión es que usbehci.sys aparecía como módulo implicado, mientras que el examen de la petición permitió identificar una posible relación con el controlador del adaptador de red USB. El resultado no demuestra por sí solo que el dispositivo o su controlador fueran responsables, pero ofrece una pista más concreta para continuar la investigación.

Este ejemplo muestra cómo pasar de una indicación inicial del depurador a una hipótesis más específica mediante el examen de las estructuras y las llamadas implicadas.

Recomendaciones para diagnosticar una pantalla azul

Ante una pantalla azul, lo más importante es conservar el código de detención, anotar cuándo aparece el fallo y comprobar si comenzó después de instalar un controlador, actualizar Windows o conectar un dispositivo.

Si el error se repite, conviene conservar los volcados de memoria y analizarlos con WinDbg. Cuando hay varios archivos disponibles, comparar sus códigos de detención, pilas de llamadas y módulos implicados puede ayudar a distinguir un problema recurrente de un fallo aislado.

También es importante comprobar la memoria, el almacenamiento, las temperaturas y la alimentación cuando existan indicios de un posible problema de hardware. No se debe sustituir un componente únicamente porque aparezca mencionado en el informe del depurador.

Cuando el análisis apunta a un posible problema de controladores, pero no resulta concluyente, Driver Verifier puede ayudar a detectar determinados comportamientos incorrectos durante las pruebas. Debe utilizarse con precaución, ya que puede provocar deliberadamente nuevas pantallas azules. No es recomendable activarlo indiscriminadamente en un equipo de uso habitual; antes de utilizarlo, conviene conocer cómo recuperar Windows si deja de arrancar con normalidad.

Por último, los volcados pueden contener datos sensibles de los procesos que estaban en ejecución. Antes de compartirlos públicamente, conviene valorar la información que podrían incluir y evitar publicar archivos completos sin necesidad.

El análisis de una pantalla azul rara vez se resuelve identificando un único archivo .sys. La combinación del código de detención, sus parámetros, la pila de llamadas, los símbolos de depuración y las circunstancias en las que se produce el fallo ofrece una base más sólida para investigar su origen.