martes, febrero 05, 2013

Comprendiendo archivos .dmp de Windows [GUIA]

Con la promoción que les menciona hace unos días, logre comprar mi licencia de Windows 8, y en medio de todo ha sido una buena experiencia, no me puedo quejar. Sin embargo, Windows... es Windows y siempre da uno que otro problema, especialmente con hardware" no muy estándar  (entiéndase chino), y con problema me refiero a la usual BSOD, solo que ahora es un poco más amena:

Si, esta es la nueva BSOD, cómica ¿verdad?.
Bien, el punto es que la BSOD era muy temida usualmente por la falta de información que esta muestra (o al menos la información comprensible), sin embargo un BSOD siempre esta acompañado por un "dump" (un archivo .dmp que esta en el %systemroot%), que suele ser el volcado de la memoria RAM en ese momento en el que ocurrió el error.
Este curioso archivo .dmp, con las herramientas adecuadas, puede después de unos cuantos simples pasos, ayudar a diagnosticar el problema que genero la BSOD en primer lugar. Sin mayor preámbulo, les comparto la guía practica para diagnosticar un .dmp generado en una BSOD:

Paso 1: Descargar los "debugging tools":
http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx
Este vinculo es valido para las versiones de Windows Server 2012 y Windows 8 Consumer debugger tools, Windows 7, Vista, XP y Windows Server 2003. Como mencione lo único que necesitan para comenzar es descargar es el "Debugging Tools for Windows", los demás paquetes salen del alcance de este artículo.

Paso 2: Después de instalar el "Debugging Tools", abra una consola como administrador (CMD) y vaya a la ruta donde se aloja el programa recién instalado, en mi caso: "C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x86>".

Sea bueno y siga instrucciones.

Paso 3: Una vez ubicado en la ruta mencionada, digita el siguiente comando:

kd.exe –z C:\Windows\MEMORY.dmp (o la ruta a tu archivo .dmp)

Paso 4: Aparecerá un "prompt", donde los comandos empiezan con un punto (vaya, ¡la creatividad!), y en este prompt ahora introduzca:
.logopen c:\debuglog.txt
Paso 5: Otra instrucción más:
 .sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Paso 6: Otra instrucción totalmente comprensible:
.reload;!analyze -v;r;kv;lmnt;.logclose;q
¡Y listo! Después de estas instrucciones donde queda absolutamente claro que es lo que esta sucediendo, podemos tranquilamente ir a revisar el archivo "c:\debuglog.txt" con nuestro editor de texto favorito (Notepad++) y buscar "PROCESS_NAME". Usualmente, a la par de esta cadena de texto, aparece el driver (.sys) o programa (.exe) que causo el incidente:

Maldita sea... WTF?
Si bien el proceso es un poco ... eh... esotérico, ayuda mucho a ubicar el problema raíz que afecte a nuestra PC. Espero que a más de algún alma le sirvan estos pasos, yo ya resolví un problema de driver de sonido con esto, de primera mano les aseguro que funciona ;) cualquier duda estamos a la orden.
¡Saludos!

Sunsetting Sr. Byte.

El Sr. Byte ha estado más de 5 años inactivo. Digamos que estaba en " code freeze ". Pero ahora es el último release. Quizas no...