使用windbg抓取崩溃文件和分析的过程

在软件编程中,崩溃的场景比较常见的。且说微软技术再牛X,也是会出现崩溃的场景。网上有一段Win98当着比尔盖茨蓝屏的视频非常有意思。 (转载于breaksoftware的csdn博客)
        我们身边的很多软件都引入了dump生成和收集机制。但是一般情况下,它们都是生成minidump。因为minidump文件相对来说很小,方面我们收集上来进行分析。但是Minidump保存了很少的信息,在一些场景下,可能不能协助我们准确快速定位问题。

        但是,如果我们在测试过程中,发生了必现崩溃,而minidump又不能让我们发现什么,那该怎么办呢?我这儿举一个例子。我们看一下代码

[cpp]  view plain copy
  1. // Dump.cpp : 定义控制台应用程序的入口点。  
  2. //  
  3. //  
  4. // 这是一个多线程访问全局变量导致崩溃的例子  
  5. //  
  6.   
  7. #include "stdafx.h"  
  8. #include <Windows.h>  
  9. #include <vector>  
  10.   
  11. #define INTPTR int*   
  12. typedef std::vector<INTPTR> VecINTPTR;  
  13. typedef VecINTPTR::iterator VecINTPTRIter;  
  14. typedef VecINTPTR::const_iterator VecINTPTRCIter;  
  15.   
  16. VecINTPTR g_VecInt;  
  17.   
  18. static DWORD WINAPI ReadRoutine(LPVOID)  
  19. {  
  20.     // 读取线程  
  21.     for ( VecINTPTRIter it = g_VecInt.begin(); it != g_VecInt.end(); it++ ) {  
  22.         // 故意将读取时间设置长,这样更大概率导致崩溃  
  23.         Sleep(10);  
  24.         printf("%d %d\n", **it);  
  25.     }  
  26.     return 0;  
  27. }  
  28.   
  29. static DWORD WINAPI WriteRoutine(LPVOID)  
  30. {  
  31.     // 写入线程  
  32.     for ( VecINTPTRIter it = g_VecInt.begin(); it != g_VecInt.end();  ) {  
  33.         // 故意将修改时间设置短,这样更大概率导致奔溃  
  34.         delete *it;  
  35.        *it = NULL;  
  36.     }  
  37.     return 0;  
  38. }  
  39.   
  40. int _tmain(int argc, _TCHAR* argv[])  
  41. {  
  42.     // 初始填充数据  
  43.     for ( int n = 0; n < 128; n++ ) {  
  44.         int* p = new int();  
  45.         *p = n;  
  46.         g_VecInt.push_back(p);  
  47.     }  
  48.     system("pause");  
  49.     HANDLE hRead = CreateThread( NULL, 0, (LPTHREAD_START_ROUTINE)ReadRoutine, NULL, 0, NULL);  
  50.     HANDLE hWrite = CreateThread( NULL, 0, (LPTHREAD_START_ROUTINE)WriteRoutine, NULL, 0, NULL);  
  51.     HANDLE hArray[] = {hRead, hWrite};  
  52.     WaitForMultipleObjects( ARRAYSIZE(hArray), hArray, TRUE, INFINITE);  
  53.     printf("Success");  
  54.          return 0;  
  55. }  
        这个例子是典型的多线程访问共享变量,导致崩溃的问题。这个例子还是很清晰的,但是,如果这段逻辑揉入复杂的业务逻辑,问题的排查可能就没那么简单了。
        那我们看下如何分析这个问题。
  1. 运行程序(程序会暂停在system(“pause”))
  2. 安装windbg,使用“附加”功能
  3. 在windbg中输入g,让程序继续执行 
  4. 在dump.exe按任意键,重现崩溃路径
  5. 崩溃发生,windbg发现异常并中断
  6. 在windbg中输入.dump /f C:/dump.dmp,其中.dump是dump生成命令,/f是生成全信息dump,生成的dump文件会很大,C:/dump.dmp是路径
        至此,我们在客户机器上已经抓到了完整的dmp文件,现在我们回到我们自己的电脑上,配置windbg,并分析这个dump文件。在这个配置中,我们要涉及几块信息的填充。一般,我们发布的产品(release版)不是在我们开发者的机器上编译链接的,而是在某一个编译链接服务器上。在服务器上,我们工程的目录和我们本地的目录极有可能是不同的。一般情况下,最容易配置不正确的是下面的第3步。
  1. 将dump.exe符号文件拷贝到你希望的保存目录,我的目录是F:\TmpSymbol
  2. 用!analyze –v分析dump文件
  3. ctrl+P打开windbg代码目录(工程根目录)
  4. Ctrl+S打开windbg符号设置框,设置符号文件路径,并勾选reload
        这样windbg就准确定位到异常的位置

        这个流程非常适合于分析的场景是:

  1. 没有做通过异常方式做保护的程序(否则windbg挂载后会一直陷入中断,非常烦人。或者程序发现自己被调试,就直接退出了……)
  2. VS不便分析的dump
  3. 不破坏用户环境(windbg是个非常小巧独立的程序,试想如果我们给客户装个庞大的VS再去调试是非常难以接受的,且会破坏用户的环境)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值