Mes: octubre 2009

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.

STACK_COMMAND el comando utilizado para obtener el STACK_TEXT, en este caso kb.

FOLLOWUP_IP muestra el desensamblado de la instrucción que probablemente ha causado el error.

SYMBOL_NAME, MODULE_NAME, IMAGE_NAME y DBG_FLR_IMAGE_TIMESTAMP muestran datos sobre la instrucción: símbolo, módulo, imagen y marcado de la imagen.

BUCKET_ID: 0xD1_myfault+579

La categoría específica de errores al que pertenece el error.

Para analizar el archivo de volcado que se genera al colgarse Windows necesitaremos un depurador y los símbolos pertenecientes al sistema operativo en el que se ha producido ese dump.

Los mini-dumps se almacenan en la carpeta «ruta_del_sistemaMinidump», y contienen la información del stop, los datos de la pila del modo kernel y una lista de los controladores cargados.

Desde Debugging Tools for Windows podremos descargar las herramientas de depuración de 32/64 bits y los paquetes de símbolos, sinó configuramos el depurador para que los use desde internet.

Yo descargo la versión de 32 bits puesto que mi Windows 7 actual es el de 32 bits (cosas de pruebas).

Install Debugging Tools for Windows 32-bit Version

Luego los símbolos respectivos,

Download Windows Symbol Packages

El tamaño de un paquete de símbolos ronda los 300Mb y cada uno servirá para el sistema en concreto, puede configurarse Windbg para usar el servidor de descarga de MS.

Instalando las herramientas

Lo primero dirigirme donde he descargado el paquete msi y desbloquearlo:

Luego proceder a la instalación:

*Casi con seguridad que UAC nos pedirá confirmar la acción de instalación después de elegir el modo en la tercera pantalla.

Ya nos aparecen en el menú:

 Vamos a abrir Windbg y a configurar donde tiene los símbolos o desde donde descargarlos:

Hay que elegir una carpeta en el equipo donde se descargarán los símbolos desde el servidor de descarga, por ejemplo y siguiendo el ejemplo (valga la redundancia) de la propia MS, yo he creado la carpeta c:websymbols, y la ruta a utilizar en la configuración de Windbg sería: SRV*c:websymbols*http://msdl.microsoft.com/download/symbols

Podemos asimismo utilizar el botón Browse para buscar las rutas en el equipo.

Podemos establecer varias rutas de paquetes de símbolos.

Estaremos de acuerdo en que realizar un control rutinario del rendimiento nos servirá para propósitos como:

• Detectar y diagnosticar problemas de rendimiento
• Comprobar que los servicios cumplen con los niveles acordados
• Ayuda para poder prevenir escasez de recursos antes de ésta suponga un impacto al nivel de los servicios.

Saber que contadores registrar

Una rutina de control del rendimiento efectiva en la detección y diagnóstico, además de resolver los problemas de rendimiento comunes, debería reunir quizás cantidades enormes de datos, para editarlos, resumirlos y usarlos en informes y programación.

La primera de las cuestiones a determinar puede que verse sobre los contadores de rendimiento; entre todos los disponibles debemos reunir un conjunto básico.

Una monitorización diaria, con sesiones de registro de contadores en segundo plano, para reunir los datos de rendimiento según ese conjunto básico de contadores de forma continua que nos permita la posibilidad de resolver problemas comunes cuando surjan. Como no somos adivinos y nos es imposible conocer de antemano qué recursos clave están saturados en un equipo con problemas de rendimiento, quizás en un mundo perfecto deberíamos reunir datos de todos los recursos: procesador, memoria, disco y red; pero el sentido común nos dice que es una burrada, así qué nos queda la idea de ser selectivos en cuanto a los datos a reunir, su cantidad y con qué frecuencia. Es decir, un intento de encontrar un justo equilibrio entre la cantidad de datos a reunir para analizar y el costo asociado a este proceso.

La detección y diagnóstico de problemas comunes de rendimiento implica recursos sobrecargados, necesitamos reunir un gran rango de datos detallados del procesador, memoria, disco y uso de red y de las cargas que están soportando. Los datos deben incluir contadores que puedan indicar condiciones de error, en especial los que se dan como resultado de falta de recursos internos.

Procedimientos de control diario

Un procedimiento de control rutinario debe incluir:

• Recogida automática de una vista en detalle del rendimiento del sistema mediante los registros de contador.
• Control de los indicadores de errores de aplicaciones de servidor y del sistema.
• Configuración de alertas que provoquen registros de contador de diagnóstico e información detallada.
• Conservación resumida de estadísticas de rendimiento.
• Administración de los registros de contador generados automáticamente por estos procesos.

Registros de contador diarios.

Primer paso, establecer un registro automatizado de datos con Logman. Por ejemplo:

Logman create counter registro_diario –cf "ruta_del_archivo_de_configuracionarchivoconf.txt" –o ruta_archivodiarioregistrodiario –b 1/10/2009 00:00:00 –cnf 24:00:00 –si 1:00 –f BIN –v mmddhhmm

Después de la ejecución podemos verlo desde la interfaz gráfica de Rendimiento:

Descripción:

Se crea un contador llamado registro_diario, donde se registrarán los contadores especificados en C:perflogsarchivoconf.txt.

El registro se iniciará automáticamente por el monitor del sistema, una vez reiniciada la máquina y sea el 5 de octubre de 2009.

Las muestras se toman cada minuto, el formato del archivo de registro es el Binario.

Los archivos llevaran en su nombre la fecha, en formato mmddhhmm.

 

El archivo de configuración nos servirá para indicar los contadores que deseamos registrar o si queremos añadir contadores de aplicaciones específicas.