调试Release发布版程序的Crash错误（六）

上一篇我们已经给出了方案，能够非常方便的通过dump文件对crash错误进行调试和定位；从整个流程上看还差最后一步，即怎样拿到crash时产生的dump文件。如果可以让用户把文件发送过来自然不错，但对于类似免费共享软件等在互联网上发布的程序呢？我们的用户是不确定的，而且用户量有可能非常大，即使我们能想办法联系到用户，总不能挨个去收集crash信息吧。

    我们需要一种方案，能够提供crash信息汇报功能。

    我们可以架设一台服务器专门进行信息收集，只要客户端在crash时正确汇报即可，但是相应的维护成本和开发难度也不可忽视。有没有更简单的方法呢？还记得我的博文“为程序添加自动发送Email功能”吗？这就是简单有效的方法！

 

    方案六：minidump + email

    我们只需要在异常处理时，先生成minidump信息文件，再用email方式将文件发送到指定邮箱就行了。剩下的就是我们每天查看邮箱，提取dump文件进行调试了。

    1、Email功能

    首先我们来看一下email发送都需要哪些相关信息。

    a、发送端邮箱帐户；

    b、接收端邮箱帐户；

    c、email标题，一般应有软件名称及版本信息；

    d、email正文，一般应有简单的crash信息提示，以区别不同原因造成的crash；

    e、email附件，当然就是我们的dump文件了，还可以加上软件生成的log文件等。

    当然，对于标题应该尽量多加一些信息区别引起crash的原因，比如将crash的地址信息加到标题中；因为当每天有成百上千的crash汇报上来，重复的crash占大多数，把时间都花在区分它们身上有点太浪费。由此看来，前面方案中提到的StackWalker还是有些用处的，我们可以用它来生成一些crash的文字描述信息，写到标题或正文中去。

    dump文件的大小是否适合作为邮件的附件呢？实际上minidump产生的文件一般在几K到几十K之间，作为email的附件没有任何问题。

    关于发送email相关技术细节，已经在“为程序添加自动发送Email功能”文中介绍了，大家可以参考。其实，对接受邮箱中邮件的处理还是很费时费力的，大家可以考虑写一些脚本将处理流程自动化，提高效率。

    2、google breakpad

    google breakpad是一个开源的跨平台crash report系统，光从开源和跨平台这两个特点上来看，它就足以称的上是一个完善而有效的工具了。其实，breakpad在整个crash report层次上给出了一个系统级的解决方案，也就是说它几乎能适应各种软件、各种平台的应用要求。

    breakpad的整体思路跟上面介绍的方案是相似的，只不过最后提交dump文件的方式更加完善。大家有兴趣可以去它的官方网址查阅相关资料：http://code.google.com/p/google-breakpad/。

 

    ok，关于调试release发布程序的crash错误系列文章就写完了。这几篇文章给出的方案由简单到复杂，由简陋到完善，对crash调试有了一个比较全面的总结。当然，其中涉及到的概念和技术还很多，需要我们去不断学习和领悟，也希望大家能够互相交流。