Crash Dump自动化分析的尝试

其实另一个产品线的同事已经开发了自动分析的工具，但是非常不好用。同组的同事花了好几天也没能应用到目前的产品上来。
后来我接手了Crash Dump分析的工作，也了解了一下那个工具（称为A），它还需要调用另一个工具（称为B），过程繁琐，并且几乎无法维护和扩展。可以看出B也是尝试进行Crash Dump自动分析的结果，但需要人工干预和交互，算个半自动工具。一个C#的WinForm程序，仅通过windbg获得调用栈，然后自己实现一套本应由windbg来做的功能，当然，效果肯定不如windbg。因为B的维护不便，有人开发了A，作为B的补充，使得分析工作可以自动化，但是受限于B，做的还不够好。
A+B的组合还有个致命的问题，dump只能一个一个的分析，慢！我也是个懒人，每天大把的时间花在不顺手的工具上显然让我不爽。于是利用我之前的crash分析经验，用Python写了一个新的工具DumpDigger。
大致思路就是利用 cdb/windbg的!analyze命令获得crash dump的分析结果，用FAILURE_BUCKET_ID作为问题标识，取出关键字段的信息保存到数据库。运行时会启动多个进程同时分析，这样虽然!analyze比k 1000慢不少，但仍然能获得几倍的效率提升。最后，待指定的dump都分析完成，会根据数据库中保存的信息生成详尽的分析报告，报告url通过邮件自动发送。
基于Django写了分析报告的展示功能。DumpDigger的分析报告为XML格式，同样保存在数据库中，展示时通过xslt转换为html。用Twitter的Bootstrap写前端页面确实很轻松，最终的实现效果还不错，得到大家的好评。将分析脚本添加到计划任务中后，每天自动分析、发布日报，完全不需要人工干预，我也终于从机械的劳动中解放了。
下一步的目标是将DumpDigger与缺陷跟踪系统结合起来，用于跟踪发布版本的crash问题。