Análisis del dump II – Windbg – Uno de los blogs de Juansa

Windbg es una herramienta de depuración tanto en modo kernel como en modo usuario, con ella analizaremos los volcados.

Repasemos:

Cuando pasa un error en modo kernel Windows nos saluda con una pantalla azul y la info sobre el código de stop. Esto puede modificarse, de manera que:

– Se puede asignar un depurador (como windbg o KD).
– Se grabe el archivo de volcado de memoria (dump).
– Se produzca un reinicio automático del sistema.
– Se grabe el volcado y reinicie el sistema inmediatamente después.

Aunque a nosotros de momento nos interesa más ver los volcados.

Los volcados.

Modo-kernel:

Completo: volcado de tamaño más grande, contendrá la memoria física del equipo en el momento del pete. Lo que implica que el archivo de paginación deba tener al menos el tamaño de la memoria real + 1MB.
El volcado se guarda en la raíz del sistema con el nombre de memory.dmp(Por ejemplo: C:windowsMEMORY.DMP), y en el caso de volcados posteriores, irían sustituyendo al existente.

Memoria Kernel: Con un tamaño significativamente menor contiene la memoria ocupada por el kernel en el momento del pete. Es decir, ni memoria no asignada ni la que está asignada a aplicaciones en modo usuario, sólo la usada por el kernel, HAL, y la asignada a controladores y programas en modo kernel.
En general es el volcado más útil y se guarda en la raíz del sistema con el nombre memory.dmp. Los volcados posteriores, sean memoria kernel o completo, sustituyen al existente.

Volcado pequeño: Con un tamaño de 64KB es el más pequeño de todos y por tanto sólo requiere un archivo de paginación de ese tamaño.
Su contenido es:
– Mensaje del código de stop y sus parámetros.
– El contexto del procesador que ha cascado.
– La información del proceso y el contexto kernel, del proceso que ha petado.
– La información del hilo y el contexto kernel, del proceso que ha petado.
– La pila de llamadas en modo kernel para el hilo que ha petado. Sólo hasta 16KB, los de arriba de la pila.
– Una lista de los controladores cargados.
Además, si es Windows XP o posterior:
– Una lista de módulos cargados y descargados.
– El bloque de datos del depurador (información de depuración básica del sistema).
– Cualquier página de memoria que Windows crea que es útil en la depuración de errores. (Las páginas de datos a qué apuntan los registradores en el momento del pete y otras que hayan sido solicitadas específicamente por el componente que falla).

Este tipo de volcado puede ser útil en los casos que el espacio sea escaso, aunque su información limitada hará que errores cuya causa no sea un hilo en ejecución en el momento del pete sean imposibles de ver en su análisis.
Ante nuevos petes, la creación del volcado pequeño no sustituye a los anteriores, creándose con nombres cuyo formato incluye la fecha añadida a la palabra mini, y un valor numérico tras un guión si se producen varios en una misma fecha, al estilo de mini070209-01.dmp; el primer volcado pequeño del 7 de febrero de 2009.
Los minidump se guardan en una carpeta denominada Minidump dentro de la raíz del sistema.

* Kernel = Núcleo.

Análisis mediante Windbg

Como ya comentamos e independientemente del depurador a usar, necesitamos instalar los archivos de símbolos de la versión de Windows que ha generado el volcado. Los utilizará el depurador para el análisis del archivo, y puede configurarse en Windbg el uso de la ruta de descarga desde el servidor de MS.

Con Windbg abriremos el dump desde File/Open Crash Dump, navegaremos hasta el lugar donde tenemos el archivo, lo elegiremos y pulsaremos Abrir.

Se abrirá una ventana independiente, mostrándonos el proceso de carga del volcado.

Bajo Bugckeck Analysis encontraremos la primera información relevante, para obtener información detallada (aconsejable) podemos pulsar sobre el link !analyze –v o escribirlo tal cual en la barra de comandos abajo, el resultado es el mismo.

Podemos usar también otros comandos para ver información relacionada, como:

!memusage

!vm

!errlog

!process 0 0

!process 0 7

Como decía al principio el primer paso sería darle paso al comando !analyze junto a la opción -v, que nos dará información extensa.

Las opciones disponibles de !analyze son:

-v
Salida de info extendida por pantalla
-f
Genera información sobre la excepción. Se usa para ver un análisis de la excepción aún si el depurador no la ha detectado.
-hang
Genera información sobre el pete de la aplicación.

-D BucketID
Sólo muestra aquéllos elementos que son relevantes al BucketID especificado.

-show
Muestra en pantalla la información sobre el código de stop especificado.

-c
Sigue con la depuración cuando el depurador se encuentra con un problema conocido. Si el problema no es uno conocido, el depurador permanecerá detenido.
Podemos usar -c con ciertos subparámetros, que configuran la lista de problemas conocidos y de porsí no se ejecutan, hasta que usemos !analyze -c -load al menos una vez. !analyze -c no tiene ningún efecto.

    -load Archivoconocidos
Carga un archivo de problemas conocidos. Archivoconocidos específica la ruta y el nombre del archivo a cargar. Debe estar en formato xml. Se usará en todos los análisis posteriores con el parámetro !analyze -c hasta que se descargue el archivo o se cargue otro nuevo que sustituya al cargado.
    -unload
descarga la lista de problemas conocidos.
    -help
Muestra ayuda para la extensión !analyze -c en la ventana de comandos del depurador.

BugCheckCode
Específica el código de stop a mostrar.

BugParameters
Especifica hasta cuatro parámetros del código separados por espacios. Ese parámetro nos permite mayor refinamiento en la especificación de los cuatro parámetros.

analyze modo kernel:

se inicia…

El primer elemento que muestra el pantallazo es el código de stop y la información relacionada con el mismo.

Sus parámetros y breve descripción, en el argumento 3 el valor es 0 y a su lado una descripción sobre el valor.

Los siguientes elementos varían según la naturaleza del pete. En la imagen podemos ver los campos READ_ADDRESS y CURRENT_IRQL.
FAULTING_IP muestra el puntero en el momento de error.

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

Muestra la categoría general a la que pertenece este fallo.

BUGCHECK_STR: 0xD1

El código de stop, que a veces va seguido de información adicional.

El campo TRAP_FRAME nos muestra el cuadro trap del pete. (con el comando .trap seguido de la dirección del cuadro también se muestra la información)

LAST_CONTROL_TRANSFER: from 921ec579 to 8168cfb9

última llamada a la pila. Si usamos el comando Ln dirección, podemos ver el módulo y función de la dirección. En este caso:
kd> ln 8168cfb9
(8168ccd8) nt!KiTrap0E+0x2e1 | (8168cff8) nt!Dr_kitf_a

STACK_TEXT muestra un seguimiento de la pila del componente que falla.