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

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

 

 

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:  0×8E

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 (0×00401ccb) 

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 (= 0×841c5420) 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 (= 0×841c5420) 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”

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!

Saludos!!