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

  

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

 

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

 

SEGUNDA PARTE:

 

2ª parte

Estándar

Hola chavales!!

Sigamos adentrándonos en el maravilloso mundo de las pantallitas azules… J

Hemos visto cómo analizar un típico crash dump utilizando sólo un par de comandos del debuggeador de Windows (Windbg). El último BSOD mostraba información del driver que causaba el fallo, el tipo de error que daba (DRIVER_IRQL_NOT_…), etc..

Pero qué pasa cuando el pantallazo no nos muestra información relevante? Ni muestra driver que cause el error, ni aplicación, ni tipo de error… Nada. Qué hacemos en este caso? Pues lo mismo. J Con una serie de comandos en el debugeador podremos sacar toda la información que necesitemos para un análisis post-mortem.

En este caso vamos a utilizar de nuevo la aplicación NotMyFault. En este caso vamos a marcar el apartado Stack Trash y pulsamos en Do Bug, con lo que nos debería de salir el siguiente BSOD

StackTrash

Sabemos por la misma ayuda que nos brinda el debuggeador, que el código de STOP (0X0000008E) se corresponde al error KERNEL_MODE_EXCEPTION_NOT_HANDLED, y que la primera dirección que nos muestra el error (0XC0000005), se corresponde a STATUS_ACCESS_VIOLATION. La misma ayuda nos dice que ha habido una violación en el acceso a memoria. Y todo esto con sólo mirar la ayuda!

Cargando el CrashDump en el debugeador, vemos que este no nos muestra nada a simple vista:

BugCheck 8E, {c0000005, 0, f3c61b8c, 0} *** WARNING: Unable to verify checksum for NotMyfault.exe*** ERROR: Module load completed but symbols could not be loaded for NotMyfault.exeProbably caused by : memory_corruption Followup: memory_corruption

Nos dice que es un error de tipo 8E y que la causa probable es una corrupción de memoria. Toca analizar con el comando !analyze –v

Analizando con este comando, vemos que la salida ya nos va mostrando otras cositas interesantes:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 – La instrucci n en “0x%08lx” hace referencia a la memoria en “0x%08lx”. La memoria no se puede “%s”.

FAULTING_IP:

+0

00000000 ??              ???

TRAP_FRAME:  f3c61b8c — (.trap fffffffff3c61b8c)

ErrCode = 00000000

eax=00000120 ebx=841c53c8 ecx=83360010 edx=83360010 esi=841c53c8 edi=00000000

eip=00000000 esp=f3c61c00 ebp=f3c61c58 iopl=0         nv up ei ng nz na pe nc

cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010286

0008:00000000 ??              ???Resetting default scope DEFAULT_BUCKET_ID:  CODE_CORRUPTION 

BUGCHECK_STR:  0x8E

PROCESS_NAME:  NotMyfault.exe

Nos dice que la causa del cuelgue se podría dar por haber utilizado la aplicación NotMyFault.exe. Pero nuevamente tampoco nos dice nada del driver. Podemos utilizar el comando que utilizamos en la primera parte !thread, para que nos muestre el subproceso que logró colgar a nuestro sistema. Llamando a este comando conseguimos más información, como por ejemplo las llamadas que realizó la aplicación al sistema, así como también nos muestra la IRP:

THREAD 842f3610  Cid 0118.0328  Teb: 7ffde000 Win32Thread: e1b11968 RUNNING on processor 0IRP List:    841c53b0: (0006,0094) Flags: 00000000  Mdl: 00000000Not impersonatingDeviceMap                 e183ac28Owning Process            842f2608       Image:         NotMyfault.exeWait Start TickCount      12895          Ticks: 0Context Switch Count      557                 LargeStack

UserTime                  00:00:00.0050

KernelTime                00:00:00.0140

Win32 Start Address NotMyfault (0x00401ccb)

Llamando al comando !irp <IRP>, este nos muestra el driver que nos faltaba por descubrir:

kd> !irp 841c53b0Irp is active with 1 stacks 1 is current (= 0x841c5420)No Mdl: No System Buffer: Thread 842f3610:  Irp stack trace.       cmd  flg cl Device   File     Completion-Context>[  e, 0]   5  0 842f76a8 84153028 00000000-00000000                      *** ERROR: Module load completed but symbols could not be loaded for myfault.sys\Driver\MYFAULT                                   Args: 00000000 00000000 83360010 00000000kd> !irp 841c53b0Irp is active with 1 stacks 1 is current (= 0x841c5420)No Mdl: No System Buffer: Thread 842f3610:  Irp stack trace. 

     cmd  flg cl Device   File     Completion-Context

>[ e, 0]   5  0 842f76a8 84153028 00000000-00000000   

                   \Driver\MYFAULT

                                   Args: 00000000 00000000 83360010 00000000

Nuevamente tenemos a nuestro culpable!!

 Otros comandos que podemos utilizar:

 !cpuinfo.- Muestra información acerca del procesador instalado.

kd> !cpuinfo
CP  F/M/S Manufacturer  MHz PRCB Signature    MSR 8B Signature Features
TargetInfo::ReadMsr is not available in the current debug session
 0 15,2,4 GenuineIntel 1195 0000000d00000000                   80073fff
                      Cached Update Signature 0000002000000000
                     Initial Update Signature 0000000d00000000

!peb.- Válido para comprobar por ejemplo el nombre de equipo, path de instalación, número de procesadores, ruta de instalación, etc…

!token.- Muestra información sobre los objetos de seguridad

.cls.- Igual que la shell de Windows. Limpia la pantalla

 Se puede analizar desde el entorno de comandos (cmd.exe)??

El debuggeador de Windows viene con una herramienta llamada kd.exe, la cual la podemos invocar desde la shell de Windows. Los comandos son prácticamente los mismos, al igual que la información que nos es mostrada por la shell. La forma de invocar un crashdump desde la shell de Windows es la siguiente:

 kd.exe -z “Ruta donde está el volcado de memoria en formato DMP” -y “Ruta donde se encuentran los ficheros de símbolos” -i “Ruta de búsqueda de símbolos”

shell.PNG

Tienes las herramientas para poder hacerlo, y ya sabes cómo enfocar un problema de estas características. Lo único que te queda es practicar!

 

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