Debugging

En este articulo quiero hablar de las herramientas Debugging Tools, más abajo vamos a ver las definiciones de las Aplicaciones, Procesos, Threads y CallStacks una vez que ya sabemos estas definiciones nos podemos defender con las aplicaciones de Debugging.

Aplicaciones, procesos y threads

Una aplicación está formada por uno o más procesos
Un proceso es un ejecutable (.exe) que está en memoria y que está formado por uno o más threads (hilos de ejecución) y sus propios recursos
Piensa en un proceso como en un contenedor de threads
Un thread es la unidad básica de ejecución para la que el sistema operativo reserva tiempo de procesador para llevar a cabo una tarea
Un thread es lo que la CPU ejecuta. Todo proceso vivo ha de tener al menos un thread, y a menudo tiene varios.

Thread Call Stacks
Foto de un thread en un instante de tiempo
Muestra la historia de llamadas a funciones
Cada thread tiene su propio Call Stack
Ejemplo:
ntdll!KiFastSystemCallRet
USER32!NtUserGetMessage+0xc
notepad!WinMain+0xe5
notepad!WinMainCRTStartup+0x174
kernel32!BaseProcessStart+0x23

Cada hilo(Thread) de un proceso tiene su Call Stack independiente. Con el Windbg (Debugging Tools for Windows) podemos ver los call stack de alguna aplicación común, como notepad.exe o calc.exe por ejemplo.

Aquí os dejo un procedimiento que habría que seguir para determinar la causa y ubicar el fallo de nuestro Sistema Operativo.

Los volcados.

Modo-kernel:

Completo: volcado de tamaño más grande, contendrá la memoria física del equipo en el momento del error. 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  %systemroot%\Minidump con el nombre de memory.dmp, y en el caso de volcados posteriores, irían sustituyendo al existente (si tenemos la pestaña de sobrescribir marcada) de lo contrario si la pestaña no está marcada, se grabaran los archivos .dmp con el siguiente nombre Mini011811-01.dmp (donde se muestra la fecha y el nº de fichero creado este día, si hay varios reinicios serian 01,02,03,04,etc.

Memoria Kernel: Con un tamaño significativamente menor contiene la memoria ocupada por el kernel en el momento del error. 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 (este nombre lo tendrá si tenemos la pestaña de sobrescribir marcada).

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).

Procedimiento a seguir para resolver problemas:

Determinar el tipo de fallo: Access Violation, resultado inesperado…

Documentar los síntomas: Memory Leak, 100% CPU, Crash…

Elegir las herramientas y técnicas adecuadas:

  - Habilitar tracing en la aplicación.

  - Usar logs de debug o “checked builds”.

  - Perfmon, EventLogs, Netmon, Filemon, logs de IIS, MSDN, etc.

  - Conseguir dumps y analizarlos.

Bien, una vez que tenemos claro todo esto, podemos empezar a hablar de las herramientas de Debbuging.

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

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

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.

Saludos