BSOD

Casi todos los usuarios de Windows han oído hablar —si no experimentado— la infame “pantalla azul de la muerte” (BSOD). Este término ominoso se refiere a la pantalla de fondo azul que se muestra cuando se bloquea Windows, o deja de ejecutarse, a causa de un fallo catastrófico o de una condición interna que impida al sistema continuar funcionando.

Windows se bloquea (se detiene la ejecución y se muestra la pantalla azul) por muchas razones posibles. Un ejemplo muy común es una referencia a una dirección de memoria que causa una infracción de acceso, ya sea por intentar escribir en memoria de sólo lectura o por una operación de lectura en una dirección que no está asignada o mapeada. Otra causa común, por ejemplo, es una excepción inesperada o un “cuelgue”. Los bloqueos también ocurren cuando el kernel de un subsistema (el administrador de memoria, el administrador de energía…) o un controlador (de pantalla, de red…) detectan inconsistencias en su propio funcionamiento.

Cuando un controlador o subsistema, pues, provoca una excepción ilegal, Windows se enfrenta a un difícil dilema: se ha detectado que una parte del sistema operativo con capacidades de acceso a cualquier dispositivo de hardware y a la memoria válida ha hecho algo que no se suponía que debería hacer. ¿Por qué significa eso que Windows tiene que fallar? ¿No podría, simplemente, ignorar la excepción y dejar que el controlador de dispositivo o el subsistema continuaran como si nada hubiera pasado?

Existe la posibilidad de que el error fuera aislado y de que el componente se recuperara de alguna manera. Pero, lo más probable, es que la excepción detectada resultara en problemas más profundos como, por ejemplo, una corrupción general de la memoria o un funcionamiento errático de un dispositivo de hardware. Permitir que el sistema continúe funcionando, probablemente, daría lugar a más excepciones, y los datos almacenados en el disco u otros periféricos podrían resultar corruptos; esto supone un riesgo demasiado elevado. Así que Windows adopta una política rápida de error al tratar de evitar que la corrupción en la RAM termine por extenderse al disco.

Pantalla azul de la muerte (con sorpresa)

Independientemente de la razón de un bloqueo de sistema, la rutina que realmente realiza el bloqueo se conoce con el nombre de KeBugCheckEx. Esta función toma un código de parada (a veces llamado código de comprobación de errores) y algunos parámetros más. Una vez que KeBugCheckEx filtra todas las interrupciones del sistema, cambia la pantalla al modo de gráficos VGA de baja resolución (implementado por todos los sistemas Windows y soportado por todas las tarjetas de vídeo actuales), pinta el fondo de azul y, a continuación, muestra el código de detención, seguido de algún texto que sugiere lo que el usuario puede hacer.

La primera línea de la sección de información técnica enumera el código de parada y los parámetros pasados a KeBugCheckEx. Otra línea, cerca de la parte superior de la pantalla, proporciona el texto equivalente del identificador numérico del código de parada. Cuando un parámetro contiene una dirección de un código de sistema operativo o de dispositivo, Windows muestra también la dirección base del módulo en el que se encuentra la dirección del fallo, la fecha y hora (curiosamente con un valor hexadecimal en el formato timestamp de Unix) y el nombre del archivo del controlador de dispositivo. Esta información por sí sola podría ayudar al usuario a identificar el componente defectuoso.

Aunque existen más de 300 códigos de parada únicos, la mayoría son bastante raros de ver. En su lugar, sólo algunos pocos códigos de detención comunes representan la mayoría de los fallos de sistema de Windows.

Distribución de errores por fecuencia

Por último, el módulo KeBugCheckEx recurre a la llamada de comprobación de errores de todos los controladores de dispositivos (registrados en la función llamada KeRegisterBugCheckCallback), lo que permite a los controladores la oportunidad de detener esos dispositivos. Para terminar, accede al módulo KeRegisterBugCheckReasonCallback, el cual permite a los mismos controladores anexar datos en el volcado de bloqueo o escribir información de volcado del fallo en dispositivos alternativos.