如何抓取dump文件
在工作中，许多情况下需要将遇到的问题告知客户。但是一般来说，一个问题的重现是需要场景和时间的。如果让客户为了一个不确定有没有价值的去追踪的问题花费时间，很显然，这是不可取的。通过Windbg可以轻松实现对dump文件的抓取，这样就可以将问题(或bug)出现时的场景、现象完全展示给客户，如果你会一点调试技术的话，那无疑是锦上添花了。
在开始之前，首先要弄明白什么是dump文件？
Windbg中的定义是：A file that contains a snapshot of certain memory regions and other data related to an application or operating system. A crash dump file can be stored and then used to debug the application or operating system at a later time.
A user-mode crash dump file can be created by Windows when an application crashes, and a kernel-mode crash dump file can be created by special Windows routines when Windows itself crashes. There are several different types of crash dump files.
我的理解是dump文件相当于一个事故的现场，将触发问题(现象)发生的条件(例如进程、内存空间等)从内存中保存并转移集中起来，这样做的目的是方便给调试者提供详细的信息，以便发现问题的根本点。
弄明白什么是dump文件之后我们还需要知道dump文件的分类。
就像通信服务商一样，有移动和联通之分。Dump文件也一样，在创建的时候也是有区分的，我所接触到的就2大类，也只有这2类：Kernel-Model 和User-Model. 中文的意思是内核模式(或者叫核心态模式)和用户模式。至于什么是内核模式什么是用户模式，你可以看一下用户模式与内核模式，图文并茂，我感觉写的不错，在此就不再赘述了。这里需要注意的是，所指的分类是指根据创建dump文件的环境来区分，如果你调试的程序错误发生在调用win32 API或者系统服务的时候，那么，该dump文件属于Kernel-Model, 反之，属于用户模式。
在这里，我们主要介绍如何创建一个User-Mode 下的dump。
1. 工具的选择
“工欲善其事，必先利其器”，抓取dump也是，这里我将介绍我常用的Windbg，下面是个表格(来自windbg的帮助文档)，包含了各个工具的应用范围：
|
Feature |
||||
|
Creating a dump file when an application crashes (postmortem debugging) |
Yes |
Yes |
Yes |
Yes |
|
Creating a dump file when an application "hangs" (stops responding but does not actually crash) |
Yes |
No |
Yes |
Yes |
|
Creating a dump file when an application encounters an exception |
Yes |
Yes |
Yes |
Yes [ ?? ] |
|
Creating a dump file while an application is running normally |
No |
No |
Yes |
No [ ?? ] |
|
Creating a dump file from an application that fails during startup |
No |
No [ ?? ] |
Yes |
Yes |
|
Shrinking an existing dump file |
No |
No |
Yes |
No |
可以看得出来，Windbg是多么的强大J. 这里顺便说一下，实际上Windbg就是比CDB多了个UI 界面，显得友好一点，实际上也更方便一点，命令的使用都是一样的。
2). Dump 的抓取
.dump 命令：
.dump [Options] <File Name>
Options 表示有很多选项，比如 / o 表示可以重写 (overwrites) 一个已经存在的dump文件并使用相同的文件名。/f表示有2层意思：如果在内核模式，将创建一个完整的Kernel-Model dump 文件。该文件包含所有出错时的内存信息。要注意的是，这样的话dump文件会很大。另一层的意思是如果在用户模式下，将创建包含进程所占的内存大小，程序执行的情况，以及相应的处理和一些有用的其它信息。还有/m[options]，该命令是创建一个小的内存dump文件(内核模式下)或者一个minidump(用户模式下)。这样创建出来的dump文件体积小，又包含有用的信息。如果配合相应的选项，创建出来的dump文件可以说是“短小精悍“了！下面给个事例:
.dump /mf c:\example_dump.dmp
该命令的意思是创建一个mini dump 在c:\盘下，并且命名为example_dump，该文件的后缀名是.dmp。不同的是，在该文件中，添加了所有目标程序可访问的(内存)页面信息在里面。这样更方便调试。
抓取的时机：
实际上，察看dump文件是个很浩大的工程，也和枯燥。所以，如果能够提供给客户一个比较精确的dump文件，他看起来相对来说减少了很多时间，而且又有效率，那么对你的performance 也是大有帮助的。
上面说到了2种dump文件：full dump 和 mini dump。
Full dump 很大，包含的信息多，创建时候相对省力，只需要在debugger中断的时候用下.dump命令就可以了。Mini dump需要找到异常第一次发生的地方，这其中，还有许多异常是程序预期的 ，也就是说，你需要有判断该异常是不是导致程序中断的最终原因的能力。
一般的说，如果调试器出现second chance，那么你可以往上去追踪相同的异常。确定是该异常引发的下面一系列异常，ok，这时候可以抓dump了(mini dump)。
至于出现second chance的原因，是由于调试程序的时候，如果发生了异常(first chance)，程序就会被挂起，那么调试器就会得到通知，如果该异常被处理了，程序将继续运行，如果应用程序没有处理这些异常，调试器会再次接到通知，这时，就是second chance。如果在这时候抓取dump, 那么应该是个full dump。
更好用的是ADPlus工具，可以设定条件断点等等之类的东西，之后我将继续为大家讲解。
