windows下捕获dump之Google breakpad_client的理解

breakpad是Google开源的一套跨平台工具，用于dump的处理。很全的一套东西，我这里只简单涉及breakpad客户端，不涉及纯文本符号生成，不涉及dump解析。

一、使用

最简单的是使用进程内dump捕获，使用者只需要跟ExceptionHandler打交道，在自己的程序里定义一个ExceptionHandler对象，ExceptionHandler会挂上异常处理、CRT参数错误处理、purecall错误处理，当发生crash时，breakpad会写好dump，然后回调通知使用者。进程内dump并不推荐，但也不算太差，它在程序启动时就开启了一个“Handler thread”，等到有crash，触发该线程去写dump，写完回调使用者，从google的久未更新的ClientDesign文档可以猜到以前是只有进程内写dump的，它已经符合了让dump尽可能真实而设置下的规定。以前所在团队在chromium上做二次开发，使用的是进程内dump，没发现有问题。现在我安装的chrome浏览器，没发现有crash_server进程，估计要么是没抓dump，要么是进程内dump，我看到有文章说有一个GoogleCrashHandler.exe进程，但我这里没有发现，可能是后来修改掉了吧，之前我还一直以为是对crash_server.exe重命名了。

进程外写dump，使用者一样要定义一个ExceptionHandler对象，这对象有管道名称。另外还需要写一个server进程，server进程负责：写dump、上传dump，当客户进程发生crash时，只需要通过Event置位通知服务进程。server进程只需要定义一个breakpad提供的CrashGenerationServer类对象。客户进程和服务进程是通过管道通信的，通信可以只发生在客户进程初始化阶段，server进程要先于客户进程启动，否则客户进程就会因为管道连接不上而使用进程内dump捕获。

进程内、外dump捕获，都是异步而阻塞的，异步具体是说，进程内dump会让写dump、回调通知使用者写dump完成在另一个安全的线程中做；进程外dump会让写dump在另一个进程中做、回调通知写dump完成在crash线程中做、dump上传可以放到另一个进程中做。阻塞具体是说，虽然发生crash的线程把dump相关的工作扔给别人做了，但是它会等待别人的工作做完才继续完下走。

二、内部实现 

ExceptionHandler部分。

当使用进程内dump时，会有一个handler thread，该线程启动之后，等待semaphore触发写dump行为，进程外dump则没有该线程。另外，异常处理初始化是在ExceptionHandler对象构造中做的，如果没有进程外dump的需求，那么只需要ExceptionHandler就可以搞定，不需要CrashGenerationClient 和 CrashGenerationServer。

生成dump的流程在ExceptionHandler里面跑的很杂，还提供了非崩溃产生dump的接口。画个流程图出来（流程图只是函数的罗列，块与块之间可能存在包含关系）：

 

 

CrashGenerationClient 和 CrashGenerationServer。

这两个类主要用于进程间通信，包括：管道数据传输、Event通知。跟ExceptionHandler有关联的就是CrashGenerationClient，这里的client可以当作管道的client来理解。ExceptionHandler已经做了异常处理初始化，而进程外dump的生成是另外的进程做的，所以CrashGenerationClient，并不涉及异常、dump生成，它只是为了进程间通信而存在。 

以CrashGenerationClient为主线来介绍客户进程服务进程间的交互。CrashGenerationClient对外提供Register、RequestDump、RequestUpload。

1、Register

     1-1 客户进程连接上服务进程：连接上管道，设置管道状态

     1-2 客户进程向服务进程注册：通过TransactNamedPipe，将客户进程的信息传递给服务进程，也从服务进程读取到数据。

客户进程传递的数据包括：服务进程ID、dump类型、crash线程id的地址、EXCEPTION_POINTERS指针的地址、参数异常和纯虚函数异常的断言信息地址、客户进程信息。服务进程会监控客户进程的退出。

客户进程接收的数据包括：客户进程用于触发生成dump的Event Handle；客户进程用于监听的dump生成完毕Event Handle；客户进程用于监听的服务进程活着Mutex handle；服务进程进程id（后面没用上）。

这里Handle，都是服务进程通过DuplicateHandle API 复制到客户进程的，为什么不使用命名Handle呢？这样子两个进程只需要约定名字就好，不需要DuplicateHandle，然后再通过管道传递。我的理解：命名Handle之所以不用，是因为服务进程要为多个客户进程提供dump服务，如果使用命名Handle，那么命名会是一个很麻烦的事情，再则，约定名字也增加了耦合，breakpad现在的做法使得客户和服务的耦合只有管道名、管道数据协议。

客户进程在TransactNamePipe函数执行完毕之后，再执行了一次WriteFile操作，发送MESSAGE_TAG_REGISTRATION_ACK消息给服务进程，服务进程收到该ACK消息时，关闭跟客户进程的连接。服务进程对管道的操作顺序为：读-->写-->读，第二次读是客户进程通知服务进程关闭管道。

2、RequestDump

当发生crash时，或者是在非crash状态下要求生成dump，就需要调用RequestDump函数。客户进程触发之前从服务进程收到的崩溃Event Handle，等待dump完成Event和服务进程Event处于触发状态，release下最多等15秒，debug下无限等待，异步阻塞，为了不让现场被破坏。

服务进程通过RegisterWaitForSingleObject注册了崩溃Event Handle的回调函数。回调函数里做了这么几件事情：（1）、通过ReadProcessMemory读取客户进程的信息；（2）、生成dump；（3）、触发dump生成事件，通知客户进程，复位触发dump事件。

3、RequestUpload

首先客户进程连接上服务进程，接着客户进程写MESSAGE_TAG_UPLOAD_REQUEST消息到管道，写完关闭管道。

服务进程读取数据，发现是MESSAGE_TAG_UPLOAD_REQUEST消息，则调用创建服务进程时注册的上传回调函数。注意到chromium并没有使用这个通道，而是在服务进程生成dump的回调里做了dump上传操作，这样子似乎更好，减少了crash时两进程的沟通。客户进程、服务进程、breakpad客户端之间的联系图：

 

可以看到breakpad客户端主要包含了CrashGenerationServer\ExceptionHandler\CrashGenerationClient三部分，另外有dump上传未画出。

三、从代码中学到的

学习breakpad_client的代码，不是为了在工作上使用，以前的、现在的团队都已经有成熟的dump捕获、dump分析工具。学习它，是为了体会它的优点和缺点。

breakpad_client的层次划分很好，使用者不需要知道进程间通信的存在，通过回调实现层次间的通知。（这种比较简单，一般人都可以做到。）

crash之后崩溃线程尽可能少的操作，在客户进程初始化时就把崩溃时服务进程需要用的全局数据的地址通知服务进程，崩溃时，只需要触发Event。（我之前的做法是在crash的时候再把崩溃信息通知服务进程，现在看来是不合理的。）

API的使用。RegisterWaitForSingleObject的使用，这个API是我之前没用过的，非常方便，直到前阵子才通过QueueUserWorkItem API（chromium通过它异步上传dump）知道windows有自带线程池的存在；进程间通信对管道+Event的善用（管道的异步操作 + RegisterWaitForSingleObject 非常漂亮）；dump生成的各种处理，不仅仅是MiniDumpWriteDump。（这可以说是我知识面不广带来的惊喜。）

阅读ClientDesign文档，虽然文档可能老了，但引导我明白了为什么进程内dump会导致现场破坏，最直接的理解是：因为堆坏了导致的崩溃，这时候异常处理函数里又干了堆内存分配的事情，那肯定就又继续crash。

breakpad_client对使用者的通知是用回调函数做的，回调函数是在对象初始化时传递的函数指针，有一个函数有三个回调函数指针（客户进程连接、客户进程崩溃、客户进程要求上传dump）， 我更喜欢用抽象类指针，这样子只需要一个指针就够了，参数不需要那么多，而且代码更像C++。（这是目前唯一能想到的不喜欢。）

四、资料推荐

http://code.google.com/p/google-breakpad/wiki