Dump调试
打开Dump文件调试
-
VS方式：
用VS打开dump
VS调试
a 根据截图中“1”的位置确定程序安装路径，将同版本的程序安装到同样的目录下
b 根据截图中“2”的位置，设置符号文件的路径（可将符号文件拷贝到安装目录下，确保符号文件与安装包是同一版本）
c 点击截图中“3”的位置，进行分析 -
windbg方式：
a 配置好symbol file path（即.pdb文件所在目录）
b 用windbg打开dump文件
c 在符号文件正确的情况下，在windbg中输入：!analyze -v后就能查看到崩溃的代码行。
查看模块信息
有时我们拿到dump文件后，却无法知道该dump编译的版本，进而无法知道该dump对应的pdb文件，这时可
以有两个方式获取模块的版本信息：
- windbg中，使用命令
!lmi app.exe或!lmi module.dll[1]来得到模块的相关信息，其中有一项就是模块编译时间，如：
模块编译时间
- VS中，将dump文件拖到VS中，
1 点击“使用仅限本机进行调试”
VS调试
2 加载完毕后，选中模块
查看模块
3 可查看各模块的信息
模块信息
强制加载
有时我们会遇到找不到dump文件对应的pdb文件，但有相近的pdb的情况，这两个版本之间代码差异不大，在这种情况下，我们可以强制加载pdb来定位问题: - 强制加载并分析
先输入命令：.reload /i module.dll[2]，再输入：!analyze -v - 如果上述方式还不行，则可以增加“激活详细符号加载”的步骤
先输入命令：.reload /i module.dll，再输入：!sym noisy;.reload /i module.dll module!*test*，最后输入：!analyze -v
查看堆栈
查看堆栈主要用于以下两种情况：
1 有时我们分析时，会遇到无任何堆栈信息情况，打印出类似如下
字段：APPLICATION_FAULT_WRONG_SYMBOLS_ZEROED_STACK_STACKIMMUNE
2 强制加载后，还是只能打印出模块信息，而无详细的堆栈信息。
此时可以输入命令：.ecxr切换到异常线程，然后再输入kp，kb等命令打印出详细的堆栈信息
查看当前线程状态
命令：~*kv
调试32位程序在64位机器下生成64位dump
命令：.load wow64exts
任务管理器创建dump
在64位系统下使用任务管理器生成dump时，默认打开的任务管理器是64位的，创建dump也是64位的，这样的dump不容易调试；其实，系统还提供了一个32位的任务管理器：C:\Windows\SysWOW64\taskmgr.exe，用它生成的dump是32位的，这样就可以跟代码生成的dump一样去调试了。[3]
代码行错乱
在我们在根据堆栈查找代码行时，堆栈指出的位置要不就是崩溃的那一行，要不就在崩溃的下一行，但有时，我们发现代码行对应不上任何可疑之处，一般有两种情况：
- 本地代码有过更新已经不是崩溃时的代码
- 强制加载的符号文件与崩溃版本的代码差异，刚好是在崩溃文件处。
解决方案：将代码行有出入的文件revert到崩溃版本，崩溃版本的打包时间可以根据上面的“查看模块信息”章节查看。
显示最近的一条异常记录
命令：.exr -1，由于异常是事件的一种，所以使用.exr -1命令得到的异常，可能和使用.lastevent命令获取的事件（其实是异常），是同一个。但二者显示的信息各有侧重点。
查看内存
如果程序本身有内存泄露，在不断的测试过程中，可能出现内存不足的情况，打印出的堆栈信息可能是紊乱的，此时可以考虑查看一下内存，看是否还有可分配的内存：!address -summary，打印出的信息如下：
内存使用情况
如上图中，剩余内存只有46M，明显已经内存不足。
VS得出的堆栈比Windbg少
有时我们会交替的使用VS和Windbg来分析Dump，如果发现用VS得出的堆栈信息比Windbg少，可以把缺少的那个代码文件拉到VS中，找到有显示地址的函数的头部。
函数地址
将函数开头的地址加上，Windbg中显示的地址偏移，跳转到崩溃处。
地址偏移
找到崩溃处：55D0E910+1e15=55D10725，在第一次call，即调用getDrawingMgr时崩溃，调用地址为67，怀疑堆溢出，把该函数地址压了。
偏移后地址
【参考资料】
DUMP文件分析1：DUMP文件简介
Windbg调试命令详解
