Daniel Martín's blog : Windbg

Tutorial sobre Windbg [Parte IV]

dmartin — Fri, 13 Nov 2009 13:30:00 GMT

En esta cuarta parte del tutorial sobre Windbg, se van a tratar algunos comandos básicos para conocer el estado de la máquina que estamos depurando. El primer aspecto que se va a tratar es el estado del banco de registros.

Estado del banco de registros

Toda computadora dispone de un conjunto compuesto por un cierto número de registros. El número de registros y su tamaño (en número de bits) es algo que depende de la arquitectura de la plataforma. Los registros principalmente sirven para almacenar de manera temporal pequeños valores que se van necesitando durante la ejecución del código máquina, así como valores de retorno de funciones, flags de estado del procesador, etc. Si ha seguido la parte tres del tutorial (http://msmvps.com/blogs/dmartin/archive/2009/08/13/tutorial-sobre-windbg-parte-iii.aspx), en ella se indicaron algunos comandos que sirven para detener el flujo de ejecución de un programa dentro del depurador. Si en ese estado queremos examinar cuál es el contenido de los registros de la máquina, podemos ejecutar el comando r. Este es un ejemplo de la salida del comando r en un sistema operativo de 32 bits que está siendo depurado:

0:000> r eax=00000000 ebx=00000000 ecx=0012fb0c edx=779664f4 esi=fffffffe edi=00000000 eip=779be60e esp=0012fb28 ebp=0012fb54 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 ntdll!LdrpDoDebuggerBreak+0x2c: 779be60e cc int 3

En la salida del comando se muestra el contenido de los registros de la arquitectura IA-32: Eax (registro acumulador), Ebx (registro base), Ecx (registro contador), Esi (registro origen en operaciones con la memoria), Edi (registro destino en operaciones con la memoria), Eip (registro de instrucciones), Esp (registro que contiene el puntero de pila), Ebp (registro con el puntero base de pila), y algunos flags que están activados en el registro de estado del procesador.

Sin embargo, estos no son todos los registros que componen el banco de registros del procesador. Por defecto, Windbg aplica una máscara al banco de registros que sirve para que solamente se muestren los registros de enteros del procesador. El comando rm devuelve cuál es la máscara que está siendo aplicada:

0:000> rm Register output mask is 9: 1 - Integer state (32-bit) 8 - Segment registers

En este ejemplo vemos que se están mostrando los registros de enteros y los registros de segmento del procesador. Si en nuestra depuración necesitáramos echar un vistazo también a los registros de punto flotante, el comando rm ? nos puede ayudar a descubrir qué máscara aplicar:

0:000> rm ? 1 - Integer state (32-bit) or 2 - Integer state (64-bit), 64-bit takes precedence 4 - Floating-point state 8 - Segment registers 10 - MMX registers 20 - Debug registers and, in kernel, CR4 40 - SSE XMM registers

Como queremos establecer el bit 0 (registros de enteros), el bit 2 (registros de punto flotante) y el bit 3 (registros de segmento), formamos el número binario 1101, que en hexadecimal es el número D. Ejecutamos rm D y a continuación rm para ver la máscara aplicada:

0:000> rm D 0:000> rm Register output mask is d: 1 - Integer state (32-bit) 4 - Floating-point state 8 - Segment registers

Comprobamos que efectivamente lo hemos hecho bien:

0:000> r eax=00000000 ebx=00000000 ecx=0012fb0c edx=777e64f4 esi=fffffffe edi=00000000 eip=7783e60e esp=0012fb28 ebp=0012fb54 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 fpcw=027F: rn 53 puozdi fpsw=0000: top=0 cc=0000 -------- fptw=FFFF fopcode=0000 fpip=0000:00000000 fpdp=0000:00000000 st0= 0.000000000000000000000e+0000 st1= 0.000000000000000000000e+0000 st2= 0.000000000000000000000e+0000 st3= 0.000000000000000000000e+0000 st4= 0.000000000000000000000e+0000 st5= 0.000000000000000000000e+0000 st6= 0.000000000000000000000e+0000 st7= 0.000000000000000000000e+0000

Es destacable comentar que en Windbg existe el concepto de pseudo-registros. Dependiendo de la arquitectura de la computadora en la que estemos trabajando, los nombres de los registros pueden cambiar, pese a que su semántica sea la misma. Por ejemplo, en la arquitectura x86 el registro de instrucciones es el registro Eip, mientras que en la arquitectura x64 es el registro Rip. Para evitar tener que memorizar este tipo de cosas, podemos hacer uso del pseudo-registro $ip. Aparte de este, dos de los pseudo-registros que más uso son $ra, que sirve para hacer referencia a la dirección de retorno de la función en curso, y $retreg, que hace referencia al registro que almacena el resultado de una función, una vez que esta ha finalizado (en el caso de la arquitectura x86, se trata del registro físico Eax).

Vista del código en ejecución

Otro aspecto muy importante durante una sesión de depuración es tener acceso al código ensamblador que está siendo ejecutado por el procesador. Windbg nos permite desensamblar el código máquina (binario) presente en la memoria del computador para convertirlo al lenguaje ensamblador, mucho más legible.

Para desensamblar las instrucciones de la función en curso, podemos hacer uso del comando uf . (Unassemble function). El punto que hay después de "uf" sirve como referencia a la instrucción presente en el registro de instrucciones, pero en general después de "uf" puede ponerse cualquier otra dirección de memoria.

Si queremos desensamblar instrucciones a partir de la instrucción actual (para ver qué código va a ejecutar el procesador inmediatamente después), podemos hacer uso del comando u . (o u $ip, haciendo uso de los pseudo-registros comentados anteriormente). Por defecto, si no se indica nada, Windbg desensambla 8 instrucciones.

Si en cambio quisiéramos desensamblar 8 instrucciones anteriores a la instrucción actual, el comando a ejecutar sería ub $ip Esto debería ser uno de los primeros pasos que deberíamos dar si nos hemos encontrado con un estado de la máquina incorrecto y queremos saber por qué la máquina ha llegado a tal estado, es decir, qué se ha estado ejecutando antes de que ocurriera el desastre.

Examinar el contenido de la memoria

La memoria de un computador que está ejecutando un programa contiene regiones con diferentes tipos de información. Pueden contener el código del programa, datos, la pila de ejecución, heap, etc.

La extensión de Windbg !address <Dirección> facilita el saber de qué tipo es la región que engloba a una dirección de memoria determinada. Por ejemplo:

0:000> !address $ip ProcessParametrs 007117a8 in range 00710000 00715000 Environment 00710810 in range 00710000 00715000 777a0000 : 777a1000 - 000d6000 Type 01000000 MEM_IMAGE Protect 00000020 PAGE_EXECUTE_READ State 00001000 MEM_COMMIT Usage RegionUsageImage FullPath ntdll.dll

Aquí se puede ver, entre otras cosas, como la dirección de memoria que se está ejecutando actualmente contiene código ("RegionUsageImage"), lo que es algo completamente normal.

Veamos qué ocurre si ejecutamos ese mismo comando pero haciendo referencia esta vez al puntero de pila:

0:000> !address @esp ProcessParametrs 007117a8 in range 00710000 00715000 Environment 00710810 in range 00710000 00715000 00030000 : 0012e000 - 00002000 Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 00001000 MEM_COMMIT Usage RegionUsageStack Pid.Tid 16fc.c4c

Podemos ver que, obviamente, se trata de una región de la pila ("RegionUsageStack").

El comando !address personalmente lo uso cuando me encuentro con una dirección de memoria involucrada en algún problema y quiero saber qué tipo de contenido tiene. Podría ser que fuera una dirección inválida, o bien que el procesador estuviera intentando ejecutar código desde una región de memoria marcada como contenedora de datos, por culpa de algún puntero que apunte a donde no debe o quién sabe si por algún fallo de hardware. Otro uso que le doy a la extensión !address es saber qué tipo de fuga de memoria tiene un proceso. Si nos encontramos con un proceso que consume memoria de manera desmedida, existe la posibilidad de que tenga una fuga de memoria. Como un proceso puede fugar diversos tipos de memoria, una manera de saber qué tipo de memoria está utilizando sin liberar es ejecutar el comando !address sin parámetros para ver un resumen estadístico del consumo de memoria de un proceso.

Para ver lo que contiene una dirección de memoria, Windbg nos proporciona la familia de comandos d*, que tienen la sintaxis

d<Tipo> <Rango_direcciones>

<Tipo> sirve para ayudar al depurador a interpretar el contenido de la memoria situado en el rango <Rango_direcciones>

En la documentación de Windbg está disponible una lista con todos los tipos de comando d* que se pueden usar, según lo que queramos mostrar sean valores ASCII, Unicode, palabras dobles, valores en punto flotante, etc. Si el resultado de un comando d* es una ristra de símbolos "?", esto quiere decir que Windbg ha intentado acceder a una posición inválida de memoria. Esto merecería una investigación más en profundidad usando alguno de los comandos que se han descrito anteriormente.

En el próximo artículo se tratarán en detalle los comandos de Windbg que nos permiten explorar dos estructuras muy importantes en el estado de una máquina que está siendo depurada: El bloque de control de proceso (y de hilo) y la pila de ejecución.

Tutorial sobre Windbg [Parte III]

dmartin — Thu, 13 Aug 2009 21:44:00 GMT

En el anterior artículo vimos cómo abrir nuestra aplicación en modo usuario dentro de Windbg y comprendimos mejor qué es lo que ocurre cuando este se hace cargo de nuestra aplicación. Ahora tenemos a nuestra disposición una ventana con salida de texto y una caja de entrada de comandos pero, ¿qué podemos hacer?

Es importante saber que podemos manejar la ventana de Windbg e introducir comandos en su caja de texto porque nuestra aplicación está detenida debido a la excepción STATUS_BREAKPOINT que se recibe por defecto nada más abrir la aplicación en Windbg. Así pues, lo primero que buscamos es una forma de permitir que nuestra aplicación continúe con su ejecución. El comando g (o presionar F5) consigue esto mismo. Este comando hace que la aplicación siga ejecutándose hasta que se encuentre con alguna condición de parada (posteriormente aprenderemos a configurar esto), o bien ocurra algún tipo de excepción (por ejemplo, la aplicación quiere acceder a una posición de memoria incorrecta).

El comando g admite alguna que otra variante. Si, por ejemplo, queremos que nuestra aplicación siga ejecutándose hasta que se alcance una determinada posición de memoria, podemos usar la sintaxis g <Dirección>. Por otra parte, si solo nos interesa que continúe la ejecución hasta que finalice la función en curso, podemos usar el comando gu.

¿Cómo detener la ejecución de la aplicación en los momentos que nos interese?

Uno de los aspectos más importantes en la depuración de aplicaciones es la creación de breakpoints. Windbg nos proporciona los medios necesarios para crear todo tipo de breakpoints, desde los más sencillos hasta los más imaginativos. Saber qué tipo de breakpoint se debe usar en cada caso nos permitirá ahorrar horas de trabajo infructuoso.

Establecer breakpoints en código

El primer tipo de breakpoints que voy a tratar son los clásicos breakpoints en código. Como su nombre indica, son breakpoints que se alcanzan en una determinada dirección de código (típicamente el inicio de una función, pero podría ser cualquier otra cosa). El comando de Windbg para crear este tipo de breakpoints es bp. Este comando recibe como parámetro la dirección en la que queremos detener la ejecución del programa y, opcionalmente, algunas restricciones y comandos que se ejecuten automáticamente cuando se llegue al breakpoint. El abanico de restricciones que se pueden establecer conforma un amplio tipo de breakpoints que se conocen como breakpoints condicionales, que se tratarán más adelante en este artículo. Por ejemplo, si introducimos el comando bp MiAplicacion!MiFuncion "kb" y pulsamos INTRO, lo que va a ocurrir es que cuando reanudemos la ejecución de nuestra aplicación (con el comando g, como ya sabe) y se llegue a la función cuyo símbolo es MiAplicacion!MiFuncion, el depurador informará sobre esto y automáticamente ejecutará el comando kb, que como verá posteriormente, sirve para ver el estado de una estructura de datos muy importante para un proceso/hilo, la pila de ejecución.

Una cosa que quizá se pregunte es, ¿cómo averiguar qué símbolo de función me interesa? Una opción de fuerza bruta consiste en mostrar en pantalla todos los símbolos que cumplan con un determinado patrón y buscar aquella función que puede interesarnos. El comando x consigue esto mismo. Por ejemplo, si quisiera mostrar los símbolos de MiAplicacion que contuvieran la palabra "Window", podríamos usar la sintaxis x MiAplicacion!*Window*. Al pulsar INTRO, WIndbg buscará entre los símbolos disponibles aquellos que coincidan con el patrón establecido y los mostrará en pantalla junto con sus correspondientes direcciones. Si bien esta aproximación de fuerza bruta es útil en algunos casos, lo más probable es que el símbolo en el que quiera detener la ejecución del programa lo obtenga de los resultados que le proporcione Windbg al ejecutar otros comandos.

Por supuesto, también podemos crear múltiples breakpoints sin necesidad de tener que establecerlos uno a uno. Supongamos que nuestra aplicación tiene algún problema a la hora de escribir ciertos archivos en el disco. Podríamos suponer que los símbolos que más nos interesa son los de aquellas funciones que contengan la palabra "Write". Para agregar breakpoints para todos y cada uno de los símbolos que cumplan con este patrón, podemos usar el comando bm, de la siguiente manera: bm MiAplicacion!*Write*

Si la aplicación que se está depurando tiene un cierto grado de complejidad, es bastante probable que haga uso de librerías dinámicas (DLL) cuya carga no se conoce de antemano y se produce en tiempo de ejecución. Por este motivo, si necesitara parar la ejecución en alguna función dentro de esas librerías dinámicas no le sería posible, pues Windbg no conoce la dirección de la función donde debe detenerse. A fin de cuentas, Windbg solo entiende de direcciones de memoria. Para dar solución a este problema, existe el comando bu. Por ejemplo, si nuestra aplicación hiciera uso de una DLL para calcular los primeros dígitos decimales del número pi, podemos detener la ejecución en dicha función ejecutando el comando bu MiDLL!CalcularPI. Una vez introducido el comando lo que ocurre es que Windbg sabe que justo en el momento en que el módulo correspondiente a esa DLL (MiDLL) se cargue en memoria (eche un vistazo al artículo anterior para obtener más información sobre la carga de módulos), debe crear el correspondiente breakpoint, ahora que sabe cuál es su dirección de memoria.

Establecer breakpoints por acceso a un dato

En muchos casos vamos a necesitar parar la ejecución de nuestro programa no cuando se llegue a una porción de código, sino cuando se acceda a un dato. El escenario típico de esto es una aplicación que en apariencia sufre un bug del tipo buffer overrun. Básicamente este tipo de problemas implica que se sobreescriban posiciones de memoria contiguas a las de una porción de datos del programa, por ejemplo un vector. En esta situación, quizá necesitemos indagar sobre todos y cada uno de los accesos que se produzcan hacia este vector. Podemos lograr esto ejecutando el comando ba w4 miVector, suponiendo que el símbolo miVector sea el correspondiente al vector que queremos examinar. Por supuesto, podemos sustituir el símbolo por una dirección de memoria. ¿Qué significa el w4 que aparece como primer parámetro del comando ba? "W" indica que estamos buscando accesos de tipo escritura. Otras posibilidades son "E" (ejecución) y "R" (lectura). El "4" indica el número de bytes que queremos monitorizar. En las arquitecturas de 32 bits este valor puede ser 1, 2 ó 4. En las de 64 bits existe la posibilidad de establecer también 8 bytes como tamaño.

Como habrá podido observar, la creación de breakpoints es un aspecto complejo de Windbg. La capacidad más interesante a mi juicio es la posibilidad de crear breakpoints condicionales. Como vimos, para crear un breakpoint se usa el comando bp. Uno de los parámetros de este comando va entrecomillado y representa una condición adicional a la condición estándar (la llegada a la correspondiente función). Incluso se puede omitir la función y dejar solamente la condición. Supongamos que nuestro programa tiene una variable Contador que va incrementándose cada vez que se itera en un bucle, por ejemplo. Quizá estemos interesados en parar la ejecución de nuestra aplicación cuando la variable Contador adquiera el valor 10, que sabemos que es el valor de finalización del bucle. Para ello podríamos usar esta sintaxis:

bp ".if (poi(Contador)==10) {.echo Fin de cuenta }"

Este comando establece un breakpoint (bp) cuya condición (.if) es que la variable Contador sea igual al número 10. En tal caso, sacamos por pantalla (.echo) la cadena "Fin de cuenta". El comando poi se usa porque de no hacerlo, la variable Contador sería interpretada como una dirección de memoria, y esto no es lo que queremos. Como queremos tener acceso al contenido de esa dirección de memoria, los programadores de C que estén leyendo esto contestarán rápidamente que necesitamos desreferenciar ese acceso. En C esto se hace con el operador * y en Windbg con poi.

Cómo mostrar un listado de los breakpoints que hemos añadido

Una vez que hayamos establecido los breakpoints que necesitemos, es posible que queramos ver un listado de los mismos. Puede usar para ello el comando bl o bien usar la interfaz gráfica de Windbg: Si pulsa F9, se abrirá el cuadro de diálogo Breakpoints, desde el que podrá ver un listado de los breakpoints asociados a la sesión de depuración actual y crear de manera más o menos intuitiva otros nuevos. Mi consejo es usar siempre que sea posible la propia consola de comandos de Windbg, pues suele ofrecer más flexibilidad que la interfaz gráfica, pero comento esta posibilidad por si alguien se siente más cómodo/a usando cuadros de diálogo.

En este artículo hemos aprendido a crear breakpoints básicos y sencillos y otros no tan sencillos. Hemos visto también que la potencia de los breakpoints reside en los breakpoints condicionales, pues el único límite prácticamente es el de nuestra imaginación. La documentación de Windbg (F1) ofrece información más detallada sobre cada uno de los comandos que he tratado aquí, pero espero esto que sirva como punto de partida para sacarle el mayor provecho posible a esta funcionalidad que nos proporciona el sistema operativo en conjunción con Windbg. En los próximos artículos veremos comandos que nos permiten examinar el estado de la máquina. Para comprender mejor la salida de estos comandos, se explicarán también algunos conceptos importantes de la estructura de un computador y del sistema operativo, como son el repertorio de registros, la pila de ejecución o el bloque de control de un proceso/hilo.

Tutorial sobre Windbg [Parte II]

dmartin — Fri, 15 May 2009 19:21:00 GMT

En la primera parte de esta serie de artículos aprendió a instalar Windbg y a configurar un aspecto básico, los símbolos de depuración. En este artículo veremos cómo configurar otros aspectos menores de Windbg, pero que le pueden resultar necesarios, y depuraremos la primera aplicación en modo usuario.

Configurar la ruta de código fuente

Si está depurando una aplicación que no haya desarrollado, es probable que no disponga del código fuente de la misma; sin embargo, si estuviera depurando una aplicación de la que dispone el código fuente, es muy buena idea configurar Windbg para que sea capaz de usar toda esa información y mostrar la ejecución paso a paso en formato de instrucciones de código fuente, no instrucciones máquina. Para configurar este aspecto, despliegue el menú File, Source File Path (o pulse Ctrl+P). También puede usar el comando .srcpath <Ruta_código_fuente>

Para que el depurador muestre instrucciones de código fuente y no instrucciones máquina es necesario además que los símbolos de depuración contengan información acerca del fichero fuente y número de línea que se corresponde con un determinado símbolo. Estos símbolos, denominados normalmente símbolos privados, no suelen estar a disposición de los usuarios ajenos a la empresa creadora del software en cuestión.

Configurar la ruta de los módulos

En la mayoría de ocasiones, Windbg es capaz por sí solo de encontrar las imágenes de los ejecutables implicados en una sesión de depuración. En determinados casos, como por ejemplo cuando se está depurando un volcado de memoria pequeño o minidump (la depuración de volcados de memoria se tratará en un posterior artículo), es necesario indicarle al depurador dónde debe buscar los módulos (.exe, .dll, .sys, etc.). Para ello, abra File, Image File Path (o pulse Ctrl+I). Como siempre, si desea lograr esto mediante un comando de Windbg, ejecute .exepath <Ruta_ejecutables>

Ejecutar una aplicación dentro del depurador

Ya está en condiciones de depurar su primera aplicación en Windbg y para ello vamos a ejecutar la calculadora de Windows dentro de Windbg.

Abra File, Open Executable (o pulse Ctrl+E) y busque el ejecutable Calc.exe dentro del directorio \Windows\system32\. En este caso deje desmarcada la casilla Debug child processes also, que sirve para depurar no solo el proceso principal que cree ese ejecutable sino sus procesos hijos también. Haga clic sobre Abrir.

La pantalla de Windbg se rellenará con un texto similar al siguiente:


CommandLine: C:\WINDOWS\system32\calc.exe
Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
ModLoad: 01000000 0101f000   calc.exe
ModLoad: 7c910000 7c9c5000   ntdll.dll
ModLoad: 7c800000 7c903000   C:\WINDOWS\system32\kernel32.dll
ModLoad: 7e6a0000 7eec1000   C:\WINDOWS\system32\SHELL32.dll
ModLoad: 77da0000 77e4c000   C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 77e50000 77ee2000   C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 77fc0000 77fd1000   C:\WINDOWS\system32\Secur32.dll
ModLoad: 77ef0000 77f39000   C:\WINDOWS\system32\GDI32.dll
ModLoad: 7e390000 7e421000   C:\WINDOWS\system32\USER32.dll
ModLoad: 77be0000 77c38000   C:\WINDOWS\system32\msvcrt.dll
ModLoad: 77f40000 77fb6000   C:\WINDOWS\system32\SHLWAPI.dll
(23c.24c): Break instruction exception - code 80000003 (first chance)
eax=001a1eb4 ebx=7ffdb000 ecx=00000007 edx=00000080 esi=001a1f48 edi=001a1eb4
eip=7c91120e esp=0007fb20 ebp=0007fc94 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!DbgBreakPoint:
7c91120e cc              int     3

Analicemos detalladamente toda esta información:

La línea CommandLine nos está indicando el archivo que vamos a ejecutar dentro de Windbg, en este caso la calculadora de Windows. A continuación se muestra la ruta establecida para los símbolos y la ruta de búsqueda de módulos ejecutables, que en este caso está vacía porque no la hemos establecido desde la opción File, Image File Path. Seguidamente el depurador ha registrado información sobre la carga de una serie de módulos de los que depende la calculadora de Windows. Para ver las dependencias de un módulo yo recomiendo usar la herramienta Dependency Walker (http://www.dependencywalker.com/).

La siguiente línea, (23c.24c): Break instruction exception - code 80000003 (first chance), da pie a comentar bastantes cosas:

La sintaxis (23c.24c) la va a encontrar no pocas veces en Windbg. Hace referencia a un hilo dentro de un proceso. 23c es el identificador de proceso (PID), en formato hexadecimal. En este caso es el PID del proceso Calc.exe. 24c hace referencia al identificador de hilo (TID), en formato hexadecimal también. La excepción recibida en este caso es "Break instruction" (STATUS_BREAKPOINT), identificada por el código hexadecimal 0x80000003. Vamos a ver qué ocurre "por lo bajo" para explicar por qué ha ocurrido esto:

Cuando hemos seleccionado el ejecutable Calc.exe y hemos hecho clic sobre Abrir, Windbg ha llamado a la API CreateProcess con el sexto parámetro establecido a DEBUG_PROCESS. Esto permite crear un proceso e indicarle a Windows que deseamos depurarlo. Pero depurar un proceso requiere de algo más. Requiere que el programa depurador reciba una serie de eventos procedentes de la ejecución de la aplicación y los muestre al usuario o los trate de manera conveniente. Lo que ocurre durante una sesión de depuración se puede entender como un bucle en el cual el depurador espera eventos de depuración mediante la API WaitForDebugEvent, los trata de manera conveniente, y continua la ejecución del programa mediante la API ContinueDebugEvent. Este bucle se repite indefinidamente hasta que o bien la aplicación que está siendo depurada desaparece de la memoria, o bien finaliza correctamente su ejecución, o bien desacoplamos el depurador mediante el comando Debug, Detach Debugee.

La frase (first chance) hace referencia al comportamiento de las excepciones. Cuando una aplicación genera una excepción y está siendo depurada, el depurador recibe una excepción de primera oportunidad (first chance) y le da la opción de tratarla. En este caso, el depurador trata la excepción STATUS_BREAKPOINT deteniendo la ejecución de la aplicación permitiendo que el usuario introduzca comandos o examine el estado de la imagen de memoria del proceso y el estado del procesador. Si el depurador no capturase la excepción, se comprueba si el código de la aplicación la capturara. Este procedimiento implica verificar en la pila de ejecución si hay algún código manejador de excepciones, desde el marco de activación más reciente hasta al más antiguo. Este procedimiento recibe técnicamente el nombre de stack unwinding. No se preocupe, en posteriores artículos se va a tratar la estructura de datos conocida como pila, pues es de capital importancia a la hora de entender buena parte de la información que nos proporcione Windbg. En caso de que el código no capturase la excepción, se lanza al depurador una excepción de segunda oportunidad (second chance) y se vuelve a comprobar si el código captura la excepción.

Lo que aparece a continuación en la pantalla de Windbg es el estado de los registros del procesador. Para entender esta parte de la salida es necesario disponer de ciertos conocimientos específicos de la máquina que está siendo depurada. En este caso se trata de la arquitectura x86, por lo que la referencia obligada es este documento: http://download.intel.com/design/PentiumII/manuals/24319102.PDF. Cuando veamos algunos casos de estudio verá cómo aplicar la información sobre los registros de la máquina a un caso real.

Para finalizar nos aparece la última instrucción ejecutada en el procesador antes de que se pasara el control al depurador. En este caso se trata de una instrucción dentro de la función DbgBreakPoint dentro del módulo Ntdll.dll. La instrucción en cuestión es la instrucción int 3, identificada mediante el código hexadecimal CC. Esta instrucción lanza una interrupción software. El parámetro 3 indica que ejecutaremos la posición 3 del vector de interrupciones y básicamente se enviará la excepción STATUS_BREAKPOINT al depurador, para que haga con ella lo que considere oportuno. La dirección de memoria que contiene esa instrucción es la 7c91120e (en este ejemplo particular).

Para concluir, puede configurar Windbg para que no informe de ciertos eventos (tales como la finalización de un proceso, la carga de una DLL, etc.). Para ello puede ir al menú Debug, Event Filters.

Si desea hacer uso de la línea de comandos de Windbg, el comando en cuestión es sx y sus derivados sxe, sxd, sxi, sxn. En la documentación de Windbg (Help, About) puede obtener información adicional sobre el uso de estos comandos.

En este artículo hemos aprendido a configurar Windbg para comenzar una sesión de depuración y hemos ejecutado nuestra primera aplicación dentro del depurador. También hemos aprendido qué quiere decir la información que aparece en pantalla y en qué consiste "por lo bajo" la depuración de aplicaciones y el manejo de excepciones. En la siguiente parte veremos algunos comandos para examinar el estado de la máquina y del proceso que está siendo depurado. Se detallarán también algunos aspectos de la arquitectura interna de Windows que son importantes para saber realmente lo que está pasando.

Tutorial sobre Windbg [Parte I]

dmartin — Sat, 04 Apr 2009 14:09:00 GMT

A petición de un buen número de personas que me han escrito a través del blog, he decidido comenzar un tutorial sobre depuración de aplicaciones y el sistema operativo Windows usando Windbg. A través de este tutorial espero cubrir conceptos introductorios (tales como aprender a configurar Windbg, saber qué comandos son los más destacados y para qué sirven, etc.), hasta llegar a conceptos más avanzados que impliquen la aplicación de la teoría al análisis y solución de problemas reales. Se van a tratar tanto la depuración de volcados de memoria (algo que se conoce como postmortem debugging), como la depuración de sistemas en vivo (live debugging). Al final del tutorial espero que tenga la información apropiada para abordar un problema en su máquina ejecutando algo más que el clásico comando de Windbg "analyze -v".

¿Qué es un depurador y qué tipos de depuradores hay?

El concepto de depuración en el ámbito de la computación podría describirse como un procedimiento metódico consistente en el análisis y corrección de los defectos de un sistema software o hardware. Esta sencilla descripción representa una tarea ardua y dificultosa en sí misma dada la alta complejidad de cualquier sistema computacional de hoy en día. Para poder llevarla a cabo, los ingenieros se sirven de unos programas denominados depuradores (en inglés, debuggers) que permiten, entre otras cosas, analizar un volcado de memoria, adjuntarse a un proceso (más adelante veremos en qué consiste esto exactamente), ejecutar un programa y examinar el estado de la máquina (registros, memoria, procesos en ejecución, etc.), ejecutar paso a paso una aplicación, parar la ejecución según una cierta condición, etc.

Los depuradores pueden clasificarse en dos grupos bien diferenciados:

Depuradores en modo usuario: Este tipo de depuradores son capaces de mostrar el estado de un proceso en un determinado momento (hilos en ejecución, registros de la máquina, contenido de la memoria, etc.), es decir, el depurador tiene exactamente la misma visión de la máquina que tendría cada uno de los procesos que se estén ejecutando.
Depuradores en modo núcleo: Este tipo de depuradores disponen de una visión completa de la máquina sobre la que se están ejecutando. Suelen utilizarse para detectar errores en controladores de sistema, pero en ciertos casos es necesario recurrir a un depurador en modo núcleo para depurar una aplicación que funcione en modo usuario.

¿Qué es Windbg?

Windbg es un completo depurador de Microsoft, tanto en modo usuario como en modo núcleo, con una intuitiva interfaz gráfica y descargable de forma gratuita desde la página http://www.microsoft.com/whdc/devtools/debugging/default.mspx. El paquete Debugging Tools for Windows incorpora un buen número de depuradores y utilidades relacionadas, y aunque este tutorial solo se vaya a centrar en el depurador gráfico Windbg mi recomendación personal es que se instale el paquete completo de Debugging Tools for Windows.

Una vez finalizada la instalación, podemos ejecutar Windbg desde Inicio, Todos los programas, Debugging Tools for Windows (x86)/(x64), Windbg. La pantalla principal tendrá un aspecto similar al de la siguiente imagen:

Lo primero que se debe hacer es configurar el depurador. El aspecto de configuración más importante de Windbg es quizá la información referente a los símbolos del código del programa que vayamos a depurar. Antes de proseguir, vamos a describir lo que es un símbolo:

Durante la fase de construcción de un fichero ejecutable a partir de su código fuente, se genera información referente a las funciones, variables, estructuras de datos, etc. usadas en dicho código. Dependiendo de los intereses del programador, esta información puede acabar embebida en el propio ejecutable o bien proporcionarse de manera separada en la forma de ficheros con extensión .pbd (si se ha usado algún compilador de Microsoft). Embeber dicha información en el ejecutable tiene como consecuencia que su tamaño se vea incrementado de manera considerable, además por información que solo es de utilidad para programadores o profesionales de soporte. Por lo tanto, la gran mayoría de compañías de software proporcionan los símbolos para la depuración de manera separada. Sin embargo, es muy probable que existan multitud de versiones de una determinada DLL o ejecutable, en cuyo caso, ¿cómo sabe el depurador qué símbolos escoger? La primera alternativa supondría indicar individualmente la ruta que apunte a los símbolos de cada una de estas versiones, algo inviable. Para dar solución a este y otros problemas, se ideó el concepto de servidor de símbolos, una máquina cuyo cometido es proporcionar los símbolos de depuración conforme el depurador los vaya necesitando. Y lo que es más importante, el servidor de símbolos mantiene una lista de símbolos indizada por nombre, tamaño, versión o cualquier otro parámetro, por lo que es capaz de ofrecer la versión apropiada de un símbolo de manera cómoda y rápida.

¿Cómo configurar la información referente a los símbolos de depuración en Windbg?

Hay que precisar que si se configura Windbg para que consiga los símbolos de depuración desde un servidor de símbolos, es necesario que el sistema tenga conexión a Internet durante todo el periodo que dure la depuración. Si esto no fuera posible, existe la alternativa de descargarse un paquete de símbolos acorde con la versión del sistema operativo que está siendo depurado desde una web de Microsoft, http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx#d. Sin embargo, esta opción tiene el inconveniente de que los símbolos suelen estar actualizados solo hasta el Service Pack más reciente que haya salido. Si Windows Update hubiera actualizado algún ejecutable o DLL con motivo de una actualización de seguridad, por ejemplo, es posible que el depurador no disponga de la información simbólica pertinente. En particular, si faltan los símbolos de Ntoskrnl.exe (depuración en modo núcleo) o bien Ntdll.dll, Shell32.dll o alguna otra DLL muy usada del sistema operativo (depuración en modo usuario), el análisis que hagamos no servirá para nada. Es, por tanto, muy importante que configuremos correctamente la información simbólica en Windbg.

Para configurar Windbg para que acceda al servidor de símbolos de Microsoft se pueden seguir estos pasos:

Abrir el menú File, Symbol File Path (o pulsar Ctrl+S).
Introducir en la caja de texto Symbol path lo siguiente:

SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

Pulsar OK.

Téngase en cuenta que se ha configurado como carpeta de descarga de los símbolos la carpeta C:\websymbols, pero se podría indicar cualquier otra. A continuación podemos salvaguardar la configuración que hemos realizado para que no se pierda en sucesivas depuraciones haciendo clic sobre el menú File, Save Workspace (o Save Workspace As).

Si estamos en una sesión de depuración (algo que se describirá en un posterior artículo), podemos usar comandos para configurar los símbolos adecuadamente:

.sympath

Este comando muestra la ruta que esté configurada para el servidor de símbolos.

.sympath <Ruta>

Este comando establece la ruta <Ruta> como ruta del servidor de símbolos.

.sympath+ <Ruta>

Este comando es similar al anterior pero respeta cualquier otra ruta de servidor de símbolos que pueda haber configurada con anterioridad.

.symfix <Carpeta>

Este comando nos evita tener que aprender de memoria la dirección del servidor de símbolos de Microsoft. Tan solo tenemos que indicarle la carpeta en la que queremos que se descarguen los símbolos.

.symfix+ <Carpeta>

Este comando es similar al anterior pero respeta cualquier otra ruta de servidor de símbolos que pueda haber configurada con anterioridad.

Ya hemos configurado uno de los aspectos más importantes de Windbg, la información simbólica de depuración. En el siguiente artículo veremos otros aspectos menores de configuración del depurador y aprenderemos a depurar una aplicación o proceso en modo usuario.