La pantalla azul II- Ha petado o petado, ¿pero hay solución?

Dependeeee… ¿de qué?. De las ganas que se tengan de encontrar solución, hay muchos que reinstalan el sistema pensando que así desaparecerá el problema, y yo digo que puede que no y puede que tampoco, tarde o temprano si tenemos los mismos dispositivos, el mismo sistema, los mismos controladores y las mismas aplicaciones… regresará. Otra cosa es si al mismo tiempo cambiamos cosas y no nos damos cuenta que estamos eliminando la causa, pero en fin, contra gustos no hay colores, ni el azul.

Yo sí tengo ganas de solucionarlos. Por ello, primero analizo si es cosa del sistema o de alguna aplicación, luego sigo unas premisas bastante básicas para ir poco a poco profundizando si fuese necesario.

Cuando uno o varios equipos se ponen pesados en mostrarnos BSOD’s puede que sea por diversas razones:

– que hayamos instalado nuevos dispositivos,

– nuevo software o,

– de verdad se ha roto algo.

Yo pienso que el azul no sale «porque sí», es decir, pienso que el desencadenante es reciente y no creo nunca eso de «no hemos hecho nada». Una nueva aplicación, un nuevo escáner, ratón, tarjeta, controladores,…

Si hemos actualizado o instalado un nuevo controlador y al reiniciar nos saluda con una pantalla azul… pues que te voy a contar: Reinicia de nuevo y pulsa la tecla de función F8 y escoge «la última configuración buena conocida». Esto lo que hará es volver hacia atrás, evitando el nuevo controlador instalado.

wre2 

Al reiniciar después de una bsod, bootmgr automáticamente detecta que no se apagó correctamente y mostrará una pantalla similar a la anterior (Windows Error Recovery), que nos ofrece algunas opciones; en este caso reparar el inicio. (En este caso la bsod fue provocada en un windows 7 en español)

Si las pantallas azules nos aparecen después de haber pasado ya tiempo de cualquier instalación de soft o hard no nos quedará otro remedio que intentar buscarnos la vida de algún modo, si es que queremos encontrar solución.

Aquí tenemos el primer paso importante, para poder indagar necesitamos datos y creo recordar que comenté algo de DUMPS, es decir, archivos de volcado de memoria. Bien, lo primero es lo primero.

Archivos de volcado

De forma predeterminada todos los Windows están configurados para intentar la grabación de información relativa al estado del sistema durante un cuelgue. La configuración se encuentra en la pestaña avanzada de las propiedades del sistema:

Clic derecho Equipo –> Propiedades –> Configuración avanzada del sistema del árbol izquierdo –> Pestaña Opciones avanzadas –> Sección Inicio y recuperación –> Sección Error del sistema.

configdumps01 configdumps02 configdumps03 configdumps04

La configuración predeterminada con la que me encuentro en windows 7:

  • Grabar un evento en el registro del sistema
  • Reiniciar automáticamente
  • Un Volcado de memoria del kernel
  • La ruta del volcado es: %SYSTEMROOT%MEMORY.DMP
  • Sobrescribir cualquier archivo existente

Los volcados, son tres –aunque en la imagen de win7 sólo hay dos-:

  1. Volcado de memoria del kernel
  2. Volcado de memoria completo
  3. Volcado de memoria pequeño (128KB)

¿Sus diferencias?

El tamaño del archivo final es concluyente.

1) Sólo contiene páginas de memoria presentes lectura/escritura en modo kernel y en la memoria física, todo ello en el momento del cuelgue. Por su tipo y debido a que sólo el código en modo kernel puede causar cuelgues, parece el más indicado, aunque habrá ocasiones que necesitaremos depurar los procesos de usuario.

2) Lo que contiene la memoria física en el momento del cuelgue.

3) Con un tamaño entre 128KB y 1MB, denominado mini-Dump también, contiene el código de stop y sus parámetros, la lista de controladores de dispositivo cargados, las estructuras de datos que describen el proceso actual y el hilo, la pila del kernel para el hilo que ha causado el cuelgue y aquélla porción de memoria considerada relevante para el caso, de forma heurística.

Yo lo dejo de forma que no reinicie automáticamente, así puedo leer los datos de la pantalla azul mientras se realiza el volcado, y el volcado del kernel (el minidump siempre lo hace).

Después de la pantalla que hemos visto en la primera imagen, desde el interfaz de Windows se nos informa que el sistema se ha recuperado de un error grave, ofreciéndonos algunas opciones (esto sería para un análisis online).

infobsod2008 infobsod20082

 

Ok. Tenemos los dumps. Pues ya veremos si hacemos algo con ellos. También podemos forzar un dump manualmente vía teclado.

Y, ¿podemos realizar dumps si es una aplicación o servicio (no se cae el sistema) el del Hang?

Sí por supuesto.

También necesitaremos los símbolos del sistema a analizar para usarlos con algún depurador.

La pantalla azul de la muerte BSOD

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.

bsod

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.