Windbg分析dump崩溃

首先抓dump.在任务管理器->进程里面进行抓dump.

然后需要的原材料有dump、源码、pdb

1. 打开windbg把源码路径和pdb路径添加进去。
2. 需要打开的窗口包括线程窗口(Processes and Threads)、Calls窗口、Command窗口。
3. 把dump拖进去，如果Dump文件是64位的，在分析时，需要根据被转储文件的位数来判断是否转为32位的，转换的命令如下：

.load wow64exts  !sw 这两个命令可以将64位的Dump转为32位的;s再次输入!sw则可将转为32位的Dump再次转为64的

将微软调试库下载到本地的命令：SRV*C:/dbg/symbols*http://msdl.microsoft.com/download/symbols

 

1. !analyze –v    通过这个命令，可以自动的分析出出错的代码段
2. ~* kb         打印所有线程信息。结合线程窗口可以在Command窗口中看到各个可能出错的代码段。
3. 快速查找可以打印完线程信息后寻找一下exception.或者是unhand这类信息。然后只能对照源码看。
4. lmvm+模块名  查看版本或者看是否已经加载上相应exe或dll了。
5. ~33s          切换线程，33为线程ID
6. .reload /i    重新加载调试symbol

 

手动打断点命令：

抓dump:

传统意义上的用任务管理器抓取的dump有可能不能正确的抓到崩溃瞬间合适的dump.

用winDbg挂起进程运行，崩溃后，输入.dump /ma C:/dumps/myapp.dmp就可以获得此刻的dump.

1. .dump /m C:/dumps/myapp.dmp: 缺省选项，生成标准的minidump， 转储文件通常较小，便于在网络上通过邮件或其他方式传输。 这种文件的信息量较少，只包含系统信息、加载的模块（DLL）信息、 进程信息和线程信息。

2. .dump /ma C:/dumps/myapp.dmp: 带有尽量多选项的minidump（包括完整的内存内容、句柄、未加载的模块，等等），文件很大，但如果条件允许（本机调试，局域网环境）， 推荐使用这中dump。

3. .dump /mFhutwd C:/dumps/myapp.dmp: 带有数据段、非共享的读/写内存页和其他有用的信息的minidump。包含了通过minidump能够得到的最多的信息。是一种折中方案。