对于软件开发而言，调试无疑是最重要的部分之一，而对于windows 系统而言，dump文件无疑是问题发生时最全面的信息，对于一些问题而言，在对的时候抓取对的.dump文件基本上就相当于解决了一大半的问题。本文由浅入深的介绍了用户模式下抓取.dump文件的几种方式，希望对日夜奋战在加班线上的朋友有所帮助。
入门级-目标是问题发生的时候手动可以抓到dump文件
1. 当问题发生的时候使用windbg attach 到相关的进程然后使用.dump /ma 命令抓取 dump 文件。
2. 当问题发生的时候使用adplus.vbs/adplus.exe –hang 抓取相关进程的dump 文件。
入门级的方法最大的缺点就是要等到问题发生的时候才能去手动抓取.dump文件，如果问题不易重现，那么人们就不得不坐在电脑前等待问题的发生，好惨。
进阶级-目标是crash 发生的时候或者进程退出的时候可以自动抓到dump文件
1. 在问题发生的之前使用adplus.vbs/adplus.exe –crash监控相关进程的, 值得注意的是这个方法不需要手动去抓，只要crash或者进程退出，OS会自动为我们抓取dump文件，再也不用坐在显示器前等待了，来杯咖啡等着就行了。
2. 使用windbg –I 将windbg设置为即时调试器，这样当问题发生的时候，windbg就会弹出来，直到你处理了为止，同样不需要在显示器前面等待。
生活已经很美好了，但是生活可以更美好，进阶级的缺点是只能抓取crash或者进程退出的dump文件，其他情况无能为力。
高级-目标是定制在什么情况下抓取dump文件
这是最灵活的一种方式，但是也是相对最复杂的一种方式，下面为了便于说明我以一个例子来说明。
这个例子中我的目标是在notepad.exe load VERSION.dll的时候抓一个dump然后让程序继续执行。
首先在gflags的debugger中配置如下脚本：
D:\Debuggers\windbg.exe -c $$><"c:\dscript.ds"
c:\dscript.ds内容如下：
sxe ld:VERSION.dll; g; .dump /ma c:\np.dmp;g;
这个时候只要有notepad.exe开始执行，我们就会在它load VERSION.dll的时候抓取到对应的.dump 文件。
这个方法的优势是明显的，几乎任何问题都可以使用，但是它仍然有一个弊端，就是实际上进程是在调试器下运行的，对一些和性能有关的问题可能会有些影响。
总结
本文介绍的这几种方式由浅入深，各有利弊，对于大部分的调试情况已经足够了，希望对大家有所帮助，当然除了本文介绍的方式，大家还可以选择其他一些工具来抓取dump文件，此处不一一列举，另外对于kernel dump 文件的抓取，由于日常的应用开发用的不多，故本文暂不作介绍，如果感兴趣的朋友多，我再写一篇专门抓取内核dump的文章。
喜欢 
顶
难过
囧
围观
无聊
