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

最新推荐文章于 2025-05-25 11:19:21 发布

breaksoftware

最新推荐文章于 2025-05-25 11:19:21 发布

阅读量1.8w

点赞数 7

CC 4.0 BY-SA版权

分类专栏：安全

本文链接：https://blog.youkuaiyun.com/breaksoftware/article/details/13989025

安全专栏收录该内容

11 篇文章

订阅专栏

本文介绍了一个多线程访问共享变量导致程序崩溃的典型案例。通过构造特定代码演示并发问题，并利用Windbg生成完整内存转储文件进行故障定位。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

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

// Dump.cpp : 定义控制台应用程序的入口点。
//
//////////////////////////////////////////////////////////////////////////
// 这是一个多线程访问全局变量导致崩溃的例子
//////////////////////////////////////////////////////////////////////////

#include "stdafx.h"
#include <Windows.h>
#include <vector>

#define INTPTR int* 
typedef std::vector<INTPTR> VecINTPTR;
typedef VecINTPTR::iterator VecINTPTRIter;
typedef VecINTPTR::const_iterator VecINTPTRCIter;

VecINTPTR g_VecInt;

static DWORD WINAPI ReadRoutine(LPVOID)
{
    // 读取线程
    for ( VecINTPTRIter it = g_VecInt.begin(); it != g_VecInt.end(); it++ ) {
        // 故意将读取时间设置长，这样更大概率导致崩溃
        Sleep(10);
        printf("%d %d\n", **it);
    }
    return 0;
}

static DWORD WINAPI WriteRoutine(LPVOID)
{
    // 写入线程
    for ( VecINTPTRIter it = g_VecInt.begin(); it != g_VecInt.end();  ) {
        // 故意将修改时间设置短，这样更大概率导致奔溃
        delete *it;
       *it = NULL;
    }
    return 0;
}

int _tmain(int argc, _TCHAR* argv[])
{
    // 初始填充数据
    for ( int n = 0; n < 128; n++ ) {
        int* p = new int();
        *p = n;
        g_VecInt.push_back(p);
    }
    system("pause");
    HANDLE hRead = CreateThread( NULL, 0, (LPTHREAD_START_ROUTINE)ReadRoutine, NULL, 0, NULL);
    HANDLE hWrite = CreateThread( NULL, 0, (LPTHREAD_START_ROUTINE)WriteRoutine, NULL, 0, NULL);
    HANDLE hArray[] = {hRead, hWrite};
    WaitForMultipleObjects( ARRAYSIZE(hArray), hArray, TRUE, INFINITE);
    printf("Success");
         return 0;
}

这个例子是典型的多线程访问共享变量，导致崩溃的问题。这个例子还是很清晰的，但是，如果这段逻辑揉入复杂的业务逻辑，问题的排查可能就没那么简单了。
那我们看下如何分析这个问题。

运行程序（程序会暂停在system(“pause”)）
安装windbg,使用“附加”功能
在windbg中输入g，让程序继续执行
在dump.exe按任意键，重现崩溃路径
崩溃发生，windbg发现异常并中断
在windbg中输入.dump /f C:/dump.dmp，其中.dump是dump生成命令，/f是生成全信息dump,生成的dump文件会很大，C:/dump.dmp是路径

至此，我们在客户机器上已经抓到了完整的dmp文件，现在我们回到我们自己的电脑上，配置windbg，并分析这个dump文件。在这个配置中，我们要涉及几块信息的填充。一般，我们发布的产品（release版）不是在我们开发者的机器上编译链接的，而是在某一个编译链接服务器上。在服务器上，我们工程的目录和我们本地的目录极有可能是不同的。一般情况下，最容易配置不正确的是下面的第3步。