如何分析Windows的dump文件 (usermode篇)

    Windows的dump文件一般分为两种，一种是usermode的dump，比如一些应用程序崩溃之后生成的dump文件，另外一种是kernelmode的dump，比如一些驱动出错导致的蓝屏之后生成的dump文件。

    这里我打算就这两种情况各举一例分别进行说明。

    最常用的分析windows的dump文件的软件当属windbg了，虽然visualstudio也能用来分析，但一般用的不多。

    现在windbg集成在windows的WDK里面，只需要安装WDK就可以了，如下图所示：

这篇文档里面使用的是windows8.1 RTM版本的WDK。

下面就先分析一个 Usermode的dump

第一步： 打开windbg.exe，输入正确的symbol文件的地址，source文件的地址

输入symbol文件的路径

输入源文件的路径

   

第二步：用windbg打开dump文 件，从dump中可以获得一些系统消息

从初步分析来看，这个dump是因为访问冲突导致的，Access violation

 

第三步： 运行.ecxr获取发生异常时的寄存器的信息

PS:在64bit OS里面有些memory的值是不正确的，这时候需要通过看寄存器和汇编代码来分析

  

第四步：运行!analyze –v 来获取详细的现场信息 

如果symbol文件和sourcecode文件都加载正确的话，可以得到正确的信息，从现有信息来看，是Handsfree.dll里面的HFG_CreateServiceLink这个函数里面出错了，而且也具体定位到了在执行if(IsNodeOnList(&HFG(channelList, &Chan->node))这一行code出错。

 

第五步：根据内存信息，汇编代码，寄存器信息来分析哪里出错

1.      从汇编代码里可以很清楚地看到尝试访问内存0x0000000000001000时出错，这是系统保护的内存

 

2.      进一步分析汇编代码, 0x00007ffb'25557880是HFG(channelList)的地址。

3.      查看0x00007ffb`25557880存储的结构体内容，这里可以看到双向循环链表channelList被破坏了，Flink和Blink都是NULL值，尝试访问这个双向循环链表导致了程序崩溃。

4.      最后怎么修复呢？

这个没有上下文环境的话，很难知道是哪段代码导致这个问题的，只能加上一些预防机制，比如检测到这个channelList被破坏的话就直接返回，打印errorlog，但这时候这个channelList已经不能用了。

 

下一章再谈谈kernelmodedump的例子。