Windows – Las aplicaciones mandan


Hola Blogeros! una semana más aquí estamos, y no fallamos oiga!
La semana pasada estuvimos luchando contra los elementos, una lucha sin cuartel en el que mostramos como ganar las diferentes batallas que nos puedan surgir en ésta guerra tecnológica en la que nos encontramos día a día.
La semana pasada prometimos hablar el fichero memory.dmp y de cómo analizarlo en caso de que un servidor se nos vaya al cuerno inesperadamente. Sin embargo, puesto que llevamos dedicando mucho tiempo al servidor en sí, le vamos a dar algo de protagonismo a la razón por la que los servidores existen, las aplicaciones. Porque ellas también se van al cuerno alguna vez… Y porque sin ellas, estamos listos…

Toda aplicación corre en uno o varios procesos, esto que a priori parece simple, es fundamental, saber qué aplicación corre en nuestros sistemas, donde y qué proceso hace que la aplicación corra, nos permite ir al grano. Depende del nivel de error en el aplicativo iremos de un simple error en el DrWatson (drwtsn32.exe) hasta a un dump completo muy parecido al generado por el sistema cuando se produce un crash.

Un ejemplo de un crash simple podría ser el siguiente:

Application exception occurred:
App: C:\Program Files\iTunes\iTunes.exe (pid=1200)
When: 10/17/2010 @ 22:19:32.133
Exception number: c0000005 (access violation)

Vale, no es que sea mucha información pero algo si nos da, el pid o número de proceso con el que corria el proceso, el timestamp de cuando ocurrió y el código de error. Con esta información disponible podemos ir al log de Windows y ver que estaba pasando en el momento del crash de la aplicación.

En el log veremos más información referente a direcciones de memoria y demás caracteres raros que no harán otra cosa más que hundirnos en la miseria porque no entenderemos nada.. sin embargo, ya que la tecnología está al servicio del ser humano, existen herramientas para hacer debugging, es decir, traducir hasta cierto punto la información del log o dump.

Existen muchas y muy variadas, yo personalmente recomiendo la herramienta de Microsoft Windbg, disponible en la web de Microsoft dentro del paquete Debugging Tools de Windows.
Con él, y una vez configurado los símbolos (Si no sabéis como preguntarme y os lo diré) podremos abrir el fichero dump generado y empezar a ejecutar una serie de comandos que nos llevarán en un alto por ciento de las veces a la causa raíz.
El comando más usado y por el que generalmente se empieza es por el comando !analyze -v, este comando nos proporciona groso modo el módulo que causó el error.

Un ejemplo resumido para no llenaros la cabeza de caracteres raros sería el siguiente :
********************************************************************

Exception Analysis

********************************************************************

*** ERROR: Symbol file could not be found. Defaulted to export symbols for wuaueng.dll –
FAULTING_IP:
msvcrt!_woutput+6aa
77bd4817 66833800 cmp word ptr [eax],0
DEFAULT_BUCKET_ID: APPLICATION_FAULT
PROCESS_NAME: svchost.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 – The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
READ_ADDRESS: 80070002
BUGCHECK_STR: ACCESS_VIOLATION
FOLLOWUP_IP:
msvcrt!_woutput+6aa

STACK_TEXT:
0214f59c 77bd0f6e 0214f5b4 5009b680 0214f904 msvcrt!_woutput+0x6aa
0214f5d4 5009fb9c 0214f710 000000d5 5009b680 msvcrt!_vsnwprintf+0x30
0214f600 5013f897 0214f710 000000d6 000001ac wsusmsp!DllRegisterServer+0x130a
0214f628 5013fc9f 0214f710 000000d6 0214f660 wsusmsp!SCCMAtShutdown+0xa7e5
0214f664 501404a9 00000000 00000001 0214f6bc wsusmsp!SCCMAtShutdown+0xabed
0214f8c0 50140101 00000001 00000002 00000000 wsusmsp!SCCMAtShutdown+0xb3f7
0214f8ec 5016b76c 0214f918 00000000 00000001 wsusmsp!SCCMAtShutdown+0xb04f

Fijaros bien en la cabecera STACK_TEXT puesto que nos da el hilo que falló, en este caso wsusmsp. El siguiente paso sería conseguir la información de ese modulo, lo haremos a través de lmvm .

Una vez ejecutado este comando nos proporcionará información relevante como pudiera ser:

– Path o carpeta donde se encuentra la dll asociada al proceso que falló
– Timestamp
– Nombre de la compañia que lo construyó
– Versión y descripción del fichero

De tal manera que podremos descartar si la dll que falla pertenece a Microsoft, saber si tenemos la versión apropiada y comprobar si hay actualizaciones que corrijan ciertos bugs, etc..
Existen un montón de comandos que como siempre recomiendo miréis y probéis dentro de Windbg en los que según vayamos investigando y sacando más información nos iremos metiendo en una vorágine de información cada vez más al detalle, todo el detalle que estemos dispuestos a conocer.

Y eso es todo por hoy amigos, como siempre espero que os haya servido de ayuda u orientación. La semana que viene seguiremos profundizando en el mundo del problema de la mano de una de las aplicaciones introducidas en Windows 7 y Windows 2008 R2.. el nombre? La semana que viene.. :-)

Artículos relacionados

Acerca del autor

Deja tu comentario

Mostrar
Ocultar