PRIMERA PARTE:

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

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.

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.

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)

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:

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                       DriverMYFAULT

                                   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

Enlace Sysinternals: https://technet.microsoft.com/en-us/sysinternals/bb897558

SEGUNDA PARTE:

2ª parte

Estándar

Fuente: https://windowstips.wordpress.com/