Perdiendo el miedo a la pantalla azul (BSOD) 1ª parte

Estándar

Cuando Windows encuentra una sentencia que pueda llegar a comprometer el sistema, éste se para. Esta sentencia se llama KeBugCheckEx. Esta llamada al sistema la podríamos llamar fallo de sistema, error de kernel, STOP, etc.. , y toma 5 argumentos:

  • Código de STOP

  • Cuatro parámetros que indican el código de STOP

Si hemos configurado nuestro sistema para que nos vuelque el contenido de la memoria, éste nos generará un archivo para su posterior análisis. Estos archivos se dividen en:

  • Small Memory Dump.- El más pequeño de todos y el más limitado (en cuanto a investigación). Solo ocupa 64 Kb y en este archivo irá incluida la siguiente información:

    •  
      •  El mensaje de detención, parámetros y otros datos
      • El contexto del procesador (PRCB) para el procesador que se colgó.

      • La información de proceso y contexto del kernel (EPROCESS) del proceso que se colgó.

      • La información de proceso y contexto del kernel (ETHREAD) del thread que se colgó.

      • La pila de llamadas del modo kernel para el subproceso que se colgó.  Si éste tiene un tamaño mayor que 16 Kb, sólo los primeros 16 Kb serán almacenados.

      • Una lista de controladores cargados

      • Una lista de módulos cargados y no cargados

      • Bloque de datos de depuración. Contiene información básica de depuración acerca del sistema.

      • Páginas adicionales de memoria. Windows también almacena estos datos para que así podamos obtener una mayor “versión” de lo que cascó. Esto nos ayudará a identificar mucho mejor el error ya que contienen las últimas páginas de datos a las que señalaban los registros cuando el sistema se colgó.

  • Kernel Memory Dump.- Escribe el contenido de la memoria excepto los procesos.

  • Complete Memory Dump.- Escribe todo el contenido de la memoria.

En muchos casos, la información que viene contenida en un MiniDump, no es suficiente para analizar en profundidad un error. Hace años el espacio en disco podría ser un problema para almacenar este tipo de datos, pero hoy en día esto ya no es un problema. Si queremos analizar mejor el error, configurad vuestro sistema para generar o un volcado de memoria completo (Complete Memory Dump) o un volcado del Kernel (Kernel Memory Dump).

Para configurar el volcado de memoria iremos a Inicio à Ejecutar à sysdm.cpl y pulsaremos Enter.

Una vez dentro nos dirigiremos a la pestaña Configuración, y una vez dentro, en la parte de Inicio y Recuperación pulsaremos Configuración

  

Configuración Volcado de memoria

 

Como podréis ver en la imagen, hemos configurado nuestro Windows de prueba, para que NO reinicie cuando muestre una pantalla de STOP, así podremos ver la pantalla azul en todo su esplendor, y aparte le decimos que cuando muestre una pantalla de error, nos vuelque el contenido completo de la memoria, para que podamos debugearlo, y así practicar!

Y para poder practicar, qué mejor que una maquina virtual no? Podemos instalar una máquina virtual desde 0, o descargarnos una de las muchas imágenes para Virtual PC que podemos encontrar en Microsoft. En cuestión yo utilizaré esta:

http://www.microsoft.com/downloads/details.aspx?FamilyId=21EABB90-958F-4B64-B5F1-73D0A413C8EF&displaylang=en

En el blog también he puesto algunas imágenes en descarga directa con algunas plataformas servidoras, por si queréis descargarlas también.

https://windowstips.wordpress.com/2007/01/18/practica-practica/

Bien. Ya tenemos nuestra máquina virtual funcionando. Hemos configurado nuestro sistema para que nos haga un volcado de memoria completo. Qué hacemos ahora? Esperar? Instalar drivers y aplicaciones hasta que pete por algún lado? J

Como no queremos esperar a tener un BSOD para practicar, Mr. Mark Russinovich, autor de grandes herramientas, principal fundador de la Web Sysinternals y fichado por Microsoft, se ha codeado una herramienta muy chula para que podamos practicar. La herramienta en cuestión se llama NotMyFault.

NotMyFault

Esta herramienta nos ayudará a crear los típicos escenarios que nos podemos encontrar en nuestro trabajo. Esta herramienta carga un driver llamado MyFault.sys, y este es el que va a implementar las diferentes BSOD que nos podemos encontrar.

La herramienta en cuestión la podéis descargar de la siguiente dirección:

 

http://download.sysinternals.com/Files/Notmyfault.zip

También necesitaremos un debuggeador, para poder analizar los volcados de memoria. Utilizaremos el debugeador de Microsoft WinDbg, el cual lo podemos descargar de:

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

José Manuel Tella Llop, MVP de Windows, escribió un artículo en su día sobre cómo debíamos comportarnos ante una pantalla azul. El artículo original lo podéis encontrar aquí y nos servirá de guía en todo momento:

http://multingles.net/docs/jmt/bsod.htm

En el artículo de Tella viene cómo instalar tanto las herramientas de debugeo como los símbolos necesarios para poder analizar un volcado de memoria, así como un casque real, a modo de ejemplo, en el que nos muestra la sencillez con la que se saca un error. A partir de aquí asumiremos que tienes instalado WinDbg y tienes configurado correctamente el path de símbolos.

Manos a la obra! Abrimos nuestra máquina virtual, iniciamos nuestro Windows, ejecutamos NotMyFault.exe y pulsaremos la primera opción que viene en el Interface. High IRQL fault (kernel mode). Acto seguido pulsamos en Do Bug.

 

HighIRQL

 

Upppssss. Pantallaco azul al canto. Formateamos el equipo? Reiniciamos? Reinstalamos el sistema operativo? Por qué Windows es tan malo con nosotros?? J

Detengámonos un momento a analizar el BSOD.

Primera pista: DRIVER_IRQL_NOT_LESS_OR_EQUAL 

Explicación: Un driver en modo kernel ha intentado acceder a memoria paginable desde un proceso o aplicación

Causa: Un driver que ha intentado acceder a memoria paginable mientras había una interrupción, o incluso intentó acceder a memoria inválida o no presente.

Efecto: Casque real del sistema. Estamos jodidos…

 

Como podemos ver en el pantallaco azul, éste nos muestra varias cosas que tenemos que tener en cuenta en un primer momento:

  • Nos muestra el BugCheck o mensaje de STOP.
  • Nos muestra el posible causante del fallo (MyFault.sys)

 

Pero como no estamos seguros, vamos a analizar el error debugeando un poquito.

Una vez que el volcado de memoria haya finalizado, reiniciaremos la máquina y en nuestro directorio Windows, tendremos un archivo llamado MEMORY.DUMP, el cual contiene toda la memoria, ejecutables, threads, etc..

En WinDbg, pulsaremos en File à Open Crash Dump (Acordaos del path de los símbolos)

 

Windbg

 

Esto es lo que nos sale en primera instancia:

Use !analyze -v to get detailed debugging information.  BugCheck D1, {e1071800, 1c, 0, f7cda403} *** ERROR: Module load completed but symbols could not be loaded for myfault.sys*** WARNING: Unable to verify checksum for NotMyfault.exe*** ERROR: Module load completed but symbols could not be loaded for NotMyfault.exe

Probably caused by : memory_corruption

Followup: memory_corruption

 

El debugeador nos dice que casi con toda seguridad es una corrupción de memoria. El código del BugCheck es D1 (DRIVER_IRQL_…..)

Microsoft tiene registrado más de 150 posibles códigos de error. Todos ellos podemos encontrarlo en la ayuda de la misma aplicación. Más concretamente en:Debuggin tools for Windows à Debuggin Techniques à Blue Screen à Bug Check Code Reference 

También nos pone que si queremos un análisis más exhaustivo podemos escribir el comando ¡analyze –v. Así que escribimos en kd> el mencionado comando, con lo que obtendremos una respuesta parecida a esta:

analyze

Vaya. Nos da el código exacto de la pantalla azul, el bugcheck reference (D1), los 4 argumentos restantes de la pantalla azul y nos dice que el proceso que cascó es el proceso NotMyfault.exe. Ya tenemos a nuestro culpable, pero no nos dice nada del driver (MyFault.sys) que provoca el casque real.

Cuando el debugeador no nos dice realmente quién es el culpable, y queremos averiguar más sobre dicho casque, podemos hacer varias cosas:

Ejecutar el comando ¡Thread

Con el comando ¡Thread conseguimos que nos muestre qué llamadas hizo el subproceso en el sistema.

Llamando al comando ¡Thread, el debugeador nos muestra las siguientes líneas:

 

kd> !threadTHREAD 842f6600  Cid 049c.04ac  Teb: 7ffdf000 Win32Thread: e1a99168 RUNNING on processor 0IRP List:    8428cc98: (0006,0094) Flags: 00000000  Mdl: 00000000

 

WARNING: Stack unwind information not available. Following frames may be wrong.f3eb4c58 80579a8a 841d8f18 8428cc98 842b6ad0 myfault+0x403

He señalado en negrita lo más característico de estas líneas.

El proceso NotMyFault.exe hace una serie de llamadas, hasta que una pone en peligro la estabilidad del sistema. En nuestro caso es:

f3eb4c58 80579a8a 841d8f18 8428cc98 842b6ad0 myfault+0x403

Una vez que realiza la llamada, el sistema nos avisa de que la pila posiblemente esté corrompida y que los frames pueden estar corruptos.

WARNING: Stack unwind information not available. Following frames may be wrong.También nos muestra la IRP (The I/O request packet) que solicitó.IRP List:    8428cc98: (0006,0094) Flags: 00000000  Mdl: 00000000 

Con lo que tendríamos que llamar a esa IRP para que nos muestre el contenido de esa IRP.

kd> !irp 8428cc98Irp is active with 1 stacks 1 is current (= 0x8428cd08) No Mdl: No System Buffer: Thread 842f6600:  Irp stack trace.       cmd  flg cl Device   File     Completion-Context>[  e, 0]   5  0 841d8f18 842b6ad0 00000000-00000000                       \Driver\MYFAULT

                                   Args: 00000000 00000000 83360018 00000000

 

Ya tenemos a nuestro culpable. El driver MYFAULT.SYS.

También podremos ver los procesos que actualmente corrían en esa máquina antes del casque, con el comando ¡process 0 0. La salida es parecida a esta:

kd> !process 0 0**** NT ACTIVE PROCESS DUMP ****PROCESS 843cab98  SessionId: none  Cid: 0004    Peb: 00000000  ParentCid: 0000    DirBase: 00039000  ObjectTable: e1000d68  HandleCount: 232.    Image: System 

PROCESS 841d8550  SessionId: none  Cid: 0134    Peb: 7ffdf000  ParentCid: 0004    DirBase: 091af000  ObjectTable: e1007790  HandleCount:  21.    Image: smss.exe

.

.

.

En la segunda parte podremos analizar de igual manera un pantallazo azul que no nos diga a simple vista nada, un cuelgue de Windows en el que el sistema se congela literalmente, etc..

17 comentarios en “Perdiendo el miedo a la pantalla azul (BSOD) 1ª parte

  1. Exacto Akemi. O por lo menos renombrarlo. Ese driver está registrado en Windows para que se inicie cuando se cargue el sistema. Al cargarse, realiza alguna operación no permitida y crash… Pantallazo azul….
    1Saludo!

  2. Akemi

    El driver que me lo causa se llama NDIS.sys, pero no me aparece el pantallazo cuando prendo la pc, sino que después de un tiempo (unas horas) se me ponde así y se me reiniciaba después de unos segundos (un min creo), pero ahora ya lo puse para que no lo haga.

    ¿¿Lo elimino??¿¿No es importante??¿No me va a afectar el sistema, o algo así? ¿o tengo que bajarme otro driver que se llame igual o algo…ô.ó ?

  3. Akemi

    Che, le cambié el nombre y al rarito se me volvió a poner la pantalla azul, reseteé y entré en modo a prueba de fallos, borré los drivers y reinicié la compu, y cuando entré al escritorio, no me andaba el bitorrent ni me conectaba internet porque decía que el módem no estaba, o que estaba ocupado…tuve que resetear y volver a modo seguro, restaurar los drivers, y ahora me volvió a andar…

  4. LUIS

    HOLA LA DIARIO DE JUANITO!
    Primero quiero dar las gracias por explicar un poco el tema sobre los pantallazos azules y su posible solución. Segundo: quiesiera que me ayudeis ya que he instalado el debbuging tool y he puesto el parche de los simbolos, pero al salir el pantallazo azul, me da ciertos datos que los apunto en una hoja, apago el ordenador y volverlo a encender, pero cuando inicio el debbuging y me voy a File à Open Crash Dump miro la carpeta de windows y no sale ningun archivo con memory.dump. ya me han saltado varios pantallazos y nada que ver…, ¿que puedo hacer? ¿donde esta mi error? ya que he hecho todos, pero todos los pasos y no tengo respuesta, alguien me podria ayudar de urgencia? de antemano, gracias por vuestro tiempo.

  5. pajarete

    wolas. hoy me pasó el tan temido BSOD.. Pero por suerte contaba con un punto de restauracion y al parecer se solucionó… el pantallazo fue tan rapido que lo unico que alcancé a leer fue: BAD_POOL_HEADER–O ALGO ASI..luego, windows dijo😄 que podía intentar buscar alguna solución al puto problema, y me pidió la confirmación, en cuanto le di click en aceptar. windows se dispuso a enviar el archivo AUTOKMS, que es para activar el office…y eso me dejó en duda…Será que este puto archivo (autokms) no es taan confiable, y al precio de tener el office gratis, te fastidia el PC??

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s