El azul es mi color favorito, no sé si es por ser acuario. Tengo el mar a mi lado, tenemos un cielo azul la mayor parte del año, etc…
Eso sí, cuando lo veo mostrado por Windows se transforma! :-)))
Está claro que ese bonito color azul no es más ni menos que una BSOD (Blue Screen Of Death), la pantalla azul de la muerte.
Una de las primeras cosas que se me vienen a la cabeza es, simplemente, que el equipo ha petado. Y ya en lo de petar, una de las primeras confusiones al respecto es la diferencia entre petar y petar. ¿Ha petado porque ha petado? o ¿Simplemente ha petado? 🙂
Me explico: En inglés hablan de Crash y de Hang, que a veces van relacionados, es decir, que a veces un Hang es una consecuencia directa de un Crash. Yo siempre digo que ha petado o ha petado, pero parece que no es lo mismo, me explico.
Petar (Crash): La cpu no puede llevar a cabo su trabajo por una instrucción (cálculo, lectura/escritura) incorrecta. En cuanto sucede esto, Windows es tan listo que inicia una recogida de datos y los guarda para analizarlos. Si el pete es del propio sistema operativo, además, nos regala con una pantalla azul llena de garabatos y la información de la memoria del kernel o de la totalidad de la memoria física(dependerá de la configuración) la guardará en un archivo denominado DUMP, un archivo de volcado de memoria. Si el pete ha sido de una aplicación o servicio el dump será de la memoria de usuario. Este último lo llaman muchas veces el archivo de volcado de memoria post-mortem y que podemos enviar a un depurador post-mortem, que aunque pueden ser varios los depuradores se ejecutará el especificado en el registro.
Petar (Hang): Este también podemos analizarlo con un dump. La primera diferencia es que se manifiestan de forma diferente (¿petar<>petar? Me pierdo.)
Veamos como peta (Crash) una aplicación (proceso): plas! peta y desaparece de la lista de procesos en ejecución;
¿y como peta (Hang)? Pues se queda ahí, como embobado, esperando no se sabe a qué, COLGADO vamos…
Los cuelgues de aplicaciones o sistema se producen por ciertos fenómenos de mala entrega de mensajes. Las aplicaciones, o componentes del propio sistema se relacionan entre sí por ese medio, se mandan mensajitos. Y claro, esperan respuesta, y aquí está el quid de la cuestión, que se quedan esperando, esperando, esperando…
Y no hay nada más colgado que dos aplicaciones en ejecución que se esperan una a otra.
El dilema de Windows: ¿Qué hacer ante una excepción ilegal? Alguien está intentando hacer algo que se supone que no debería hacer y para más inri dispone de privilegios de acceso elevados. ¿Entonces? ¿Por qué acaba colgándose? ¿No podría ignorar dicha excepción y permitir al controlador o subsistema seguir como si no hubiera pasado nada? De hecho podría hacerlo y pensar que el error es aislado y el componente, de alguna manera, podrá recuperarse. Pero, lo más probable es que acabe con problemas mayores y es un riesgo muy alto.
La pantalla azul
KeBugCheckEx, documentada en el WDK (Windows Driver Kit), es la encargada de dar el pantallazo.
KeBugCheckEx muestra en pantalla los garabatos que nos servirán para ir investigando. El código de stop y tras la palabra STOP muestra el código numérico y 4 parámetros.
En la imagen(provocada por cierto), el código que se muestra es: DRIVER_IRQL_NOT_LESS_OR_EQUAL, el equivalente al código numérico detrás del STOP: 0x000000D1. Cuando un parámetro contiene una dirección al código de parte del sistema operativo o controlador de dispositivo, Windows muestra la dirección base del módulo donde se presume el fallo, la fecha y el nombre del controlador. Con esta sola información ya podríamos localizar el componente que está fallando.
Aunque hay más de 300 códigos de stop, la mayoría no se suelen ver. No demasiados representan la mayoría de los cuelgues de Windows. El significado de los cuatro parámetros adicionales dependerá del código de stop (que no se dan en todos). Aún así con el código de stop y los parámetros (si los muestra) pueden, al menos, darnos la posibilidad de diagnosticar el componente que está fallando ( o el controlador de dispositivo que causa el cuelgue).
Podemos encontrar la información de los errores de stop en el archivo de ayuda de las herramientas de depuración para Windows, sección Bug Checks (Blue Screens) o, basándonos en el código del error o en el nombre del hardware o aplicación sospechosa, buscarla en la Knowledge Base. Siempre podemos encontrar información sobre alternativas, actualizaciones, services pack que arreglen el problema que se está padeciendo. El archivo Bugcodes.h del WDK contiene una lista completa de los aproximadamente 300 códigos de error de stop con detalles y razones adicionales en algunos casos.