前言：windbg大家都很熟悉，它是做windows系统客户端测试的QA人员很应该掌握的定位程序崩溃原因的工具，
网上也有很多资料，但是真正适合QA阅读和实用的资料不多，我把我认为最重要最应该掌握的结合以前的使用经验分享一下：
基础篇
1、 打开windbg，打开dmp文件，File——〉open crash dump（其实有更方便的方法，后面会说）
2、 设置符号下载路径和加载路径，File——〉symbol file path，输入srv*d:\\symbolslocal*http://msdl.microsoft.com/download/symbols，中间这个路径可以随意设置，如果有其他符号路径，比如产品的模块PDB，加分号分隔即可。
符号是可以定位到具体函数，甚至具体错在哪一行代码的。在分析过程中只要dmp中牵涉到相关的微软模块的pdb都会被下载和加载。网上也有“集合版”的pdb，可以自行搜索，但是符号对应模块的版本不一定适合。
3、 弹出一个workspace的对话框，选什么都无所谓，yes、no都一样，不需要关注
4、 打开dump以后可以看到命令行窗口，如下图打开一个IE的dump文件:
5、 上图最下方的输入窗口就是用来输入调试命令的
6、 第一条命令: !analyze –v，回车，这条命令是万金油，可以自动分析大概是谁导致的崩溃，那么它执行后要关注什么内容？看下图
7、 上图应该怎么看？从下往上看！这里面就是崩溃时内存里面的模块的执行过程。注意看“Following XXX”，字面意思是接下来的段可以错了，程序在这里崩溃了的意思，因为是从下往上走的，所以“Following XXX”上方的内容就是崩溃后的东西，而“Following XXX”下方的内容就是导致崩溃的“原因”，越接近“Following XXX”的越代表有可能是导致崩溃的直接模块，但是这不一定。如果抓到的dmp时机太迟，会出现堆栈破坏的情景，那么“Following XXX”得到的内容可能就是错误的了，那么这个dmp意义就不大，当然QA可以不关注这个，要关注的是如何让自己抓dmp的时机更及时。
8、 第二条命令：kb，回车，这条命令是上面的补充，用来显示当前线程call stack（调用栈）的内容，它可以查看更详细的内存信息，更好的定位崩溃原因，比如上图内容看不到360相关的东西，是不是说这个崩溃和360没关系呢？不一定！看kb的内容
9、 记住从下往上看！上图可以看到是IE调用了safemon.dll的函数后才开始创建dmp的，是不是有理由怀疑这个崩溃和网盾有关了？提BUG吧！
10、 可惜我们只看到和网盾有关，但是具体是网盾什么函数、什么参数导致的都看不到，如何看？这时就看出符号文件的重要性了！
Ps：还有一个命令是~*kb ，它用来显示dump中所有线程的call stack， 一般用到它说明这个dump已经比较难看了，可以从命令结果中搜索KiUserExceptionDispatcher等关键字，一般可以认为存在KiUserExceptionDispatcher的线程就是导致崩溃的线程。
高级篇
1、 设置DMP类型文件关联用windbg打开
a) cmd到windbg目录运行windbg –IA
2、 手动抓DMP的方法：
a) 如果程序崩溃后没有DMP文件生成可采取下面方法转存DUM。
b) 当程序崩溃还没有退出的时候，开启WINDEBUGGER程序，在FILE——执行attach to a process——选择崩溃的进程。
c) 再执行.dump /ma C:\\testdump.dmp（如果没有/ma，dump大小比较小）
3、自动抓DMP的方法：
a) cmd到windbg目录运行 windbg -IS
b) 进行导致崩溃的操作
c) 即可抓到dmp，执行.dump /ma C:\\testdump.dmp
4、 使用windbg调起进程调试
a) 开启WINDEBUGGER程序，在FILE——执行Open Executable——选择要进行调试的进程文件
b) 当进程没有自保护或者没有反调试时，在input框输入g，回车，即可打开进程，此时如果进程发生崩溃，会被立即捕捉到。这种方法拿到的dmp比第二种更好。
5、 设置Global Flags，自动attach进程。Global Flags（简称gflags），设置它之后，目标进程启动时会立即被attach，主要用于调试一些系统进程，或“有依赖的”进程，这些进程不能直接由方法4打开，只能由其他进程调用，而调用用立即崩溃，所以也不能用方法2。这个方法同时可以设置很多检查项。
本文摘自：http://www.cnblogs.com/idbeta/p/4992128.html