Perdiendo el miedo a la pantalla azul (BSOD) 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!

Saludos!!

 

 

 

5 comentarios en “Perdiendo el miedo a la pantalla azul (BSOD) 2ª parte

  1. Excelentes dos entradas. Las he leído con mucho interés y he activado las opciones de volcado de memoria que mencionas. Ahora a esperar que esto falle, que desde hace tiempo a veces se me cuelga y no se el porque.

  2. Hola Pedro!

    Si te ha dado algún que otro pantallazo, en el directorio %systemroot%/minidump tienes que tener algún volcado de memoria, en formato pequeño (64Kb). Generalmente no tiene mucha información, pero puede ser válido para empezar.
    También puedes exponer tus dudas en los foros de TechNet.

    http://forums.microsoft.com/technet-es/default.aspx?siteid=30

    O en los foros de elhacker.net

    http://foro.elhacker.net

    Muchas gracias por tus comentarios!
    1Saludo

  3. Hola juanito me puedes ayudar?, he tenido unos pantallazos azules los he analizado y me da esto. ¿Cual es el causante?

    *******************************************************************************
    * *
    * Bugcheck Analysis *
    * *
    *******************************************************************************

    BAD_POOL_HEADER (19)
    The pool is already corrupt at the time of the current request.
    This may or may not be due to the caller.
    The internal pool links must be walked to figure out a possible cause of
    the problem, and then special pool applied to the suspect tags or the driver
    verifier to a suspect driver.
    Arguments:
    Arg1: 00000020, a pool block header size is corrupt.
    Arg2: e11dd000, The pool entry we were looking for within the page.
    Arg3: e11ddfb0, The next pool entry.
    Arg4: 7df67df6, (reserved)

    Debugging Details:
    ——————

    GetUlongFromAddress: unable to read from 80562970

    BUGCHECK_STR: 0x19_20

    POOL_ADDRESS: e11dd000

    CUSTOMER_CRASH_COUNT: 1

    DEFAULT_BUCKET_ID: DRIVER_FAULT

    PROCESS_NAME: msiexec.exe

    LAST_CONTROL_TRANSFER: from 8054b741 to 80533336

    STACK_TEXT:
    f418a928 8054b741 00000019 00000020 e11dd000 nt!KeBugCheckEx+0x1b
    f418a978 8058cbab e11dd008 00000000 c5171094 nt!ExFreePoolWithTag+0x2be
    f418a994 8058b375 e123d440 c5171094 e1012484 nt!CmpCleanUpKcbValueCache+0x3d
    f418a9a8 80589fdf e123d440 e12de6b8 80567ca8 nt!CmpCleanUpKcbCacheWithLock+0x1a
    f418a9b4 80567ca8 f418a9c8 80567c5f e2840908 nt!CmpGetDelayedCloseIndex+0x16
    f418a9bc 80567c5f e2840908 f418a9d4 80567aed nt!CmpAddToDelayedClose+0xa
    f418a9c8 80567aed e2840908 f418aba0 805677bc nt!CmpDereferenceKeyControlBlockWithLock+0x38
    f418a9d4 805677bc e2840908 e108e590 00000000 nt!CmpDereferenceKeyControlBlock+0x12
    f418aba0 805674b5 00870090 c0000034 8113ad78 nt!CmpParseKey+0x6af
    f418ac28 8056729a 00000010 f418ac68 00000040 nt!ObpLookupObjectName+0x119
    f418ac7c 80567bfd 00000000 827c4980 00000001 nt!ObOpenObjectByName+0xeb
    f418ad50 804de7ec 0091ec24 00020019 0091e8a8 nt!NtOpenKey+0x1af
    f418ad50 7c91eb94 0091ec24 00020019 0091e8a8 nt!KiFastCallEntry+0xf8
    WARNING: Frame IP not in any known module. Following frames may be wrong.
    0091e8e8 00000000 00000000 00000000 00000000 0x7c91eb94

    STACK_COMMAND: kb

    FOLLOWUP_IP:
    nt!ExFreePoolWithTag+2be
    8054b741 83f801 cmp eax,1

    SYMBOL_STACK_INDEX: 1

    SYMBOL_NAME: nt!ExFreePoolWithTag+2be

    FOLLOWUP_NAME: MachineOwner

    MODULE_NAME: nt

    IMAGE_NAME: ntoskrnl.exe

    DEBUG_FLR_IMAGE_TIMESTAMP: 42251106

    FAILURE_BUCKET_ID: 0x19_20_nt!ExFreePoolWithTag+2be

    BUCKET_ID: 0x19_20_nt!ExFreePoolWithTag+2be

    Followup: MachineOwner

  4. manuel gerez

    hola juan, te he dejado un mensaje desde mi casilla, estos articulos son invaluables en cuanto a la ayuda que nos das… por favor ojala puedas responderme.

    saludos. manuel.

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