具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面结合附图对本发明作进一步的详细描述。
在本发明实施方式中,提出了一种自动化的Dump文件分析技术方案。对软件崩溃所产生的Dump文件,调度脚本可以通过命令行等方式调度调试分析引擎进行扫描,得到转储文件分析日志。然后通过特征提取脚本和特征判定脚本,依据特征规则库对转储文件分析日志进行处理,针对Dump文件得到最终的软件Crash判定结果及相关有用信息,从而辅助软件开发者进行修改。
而且,可以将Crash判定结果及相关有用信息等存入历史Crash数据库,对以后的软件Crash分析识别及规则库的完善起到积累作用。
示范性地:软件开发者可以通过WEB站点上传需要分析的Dump文件,依据本发明实施方式的Dump文件自动化分析处理后,返回相应结果页面给软件开发者。比如:在结果页面中包含Crash的类型、Crash是否已知、Crash代码作者等相关信息,从而可以辅助软件开发者快递解决软件Crash问题。
图1为根据本发明的Dump文件分析方法流程图。
如图1所示,该方法包括:
步骤101:接收转储(Dump)文件。
在这里,可以通过多种方式接收由软件崩溃所产生的Dump文件。比如,可以通过WEB方式接收由软件自动发送或者软件开发者人工发送的Dump文件。
Dump文件是用于调试程序所用,这种文件通常需要由专用工具软件打开(比如:使用WinDbg打开)。
示范性地,以WINDOWS 7操作系统为实例,当软件系统发生崩溃时,通常有3类Dump文件可以被捕获:
(1)、完全内存Dump文件:当崩溃发生时,将捕获整个物理内存的状态。此类转储文件大小为内存中页面文件大小+1MB的文件头。在WindowsNT4操作类型中只支持完全内存转储,这也是WindowsServerSystems的默认设置。
(2)、核心内存Dump文件:当崩溃发生时,核心内存转储只捕获物理内存中内核态的页面文件读/写数据。这只是内核态的转储,并不包括用户态进程的页面。不过,由用户态进程页引起系统崩溃是不大可能的,通常都是由内核态引起。核心内存转储中包括:当前运行进程、线程和被加载的驱动等相关信息。
核心内存转储文件大小=操作系统内核态内存占用大小+操作系统为驱动程序分配内存的大小。
(3)、小内存Dump文件(Mini-dump):是一个64K的转储文件(64位系统和Windows 7里的大小为128K,在Vista中为512K)。它包括:终止代码、参数和被加载的驱动列表。主要信息为崩溃时的当前进程、线程和内核堆。
以上虽然以WINDOWS 7操作系统为实例对Dump文件的类型进行了示范性说明。本领域技术人员可以意识到,这种罗列仅仅是阐述性的,并不用于对本发明实施方式的保护范围进行限定。
步骤102:调试分析引擎对Dump文件进行扫描,以得到Dump文件分析日志。
在这里,可以通过生成调试脚本的具体方式来执行该步骤。比如:可以通过多种程序语言或脚本生成工具来生成调度脚本。
具体地,调度脚本可以是使用特定的描述性语言,依据一定的格式编写的可执行文件,又称作宏或批处理文件。简单地说,调度脚本可以包括一条条的文字命令,这些文字命令是可以看到的(如可以用记事本打开查看、编辑)。调度脚本程序在执行时,由预先设置的解释器,将其一条条文字命令的翻译成机器可识别的指令,并按程序顺序执行。
示范性地,调度脚本以命令行的方式调度调试分析引擎,采用多线程对Dump文件进行扫描,以得到Dump文件分析日志。而且,调试分析引擎具体可以为WinDbg或VisualStudio等等。
步骤103:对Dump文件分析日志进行解析,以从中提取出崩溃(Crash)基础特征。
优选地,可以生成特征提取脚本,然有由该特征提取脚本具体执行该步骤。
比如:可以通过多种程序语言或脚本生成工具来生成特征提取脚本,而且当调试分析引擎对Dump文件进行扫描得到Dump文件分析日志之后,可以由该特征提取脚本从Dump文件分析日志中提取出Crash基础特征。
示范性地,特征提取脚本可以根据预先设置的正则表达式,从Dump文件分析日志中提取出Crash基础特征。正则表达式通常被用来检索和/或替换那些符合某个模式的文本内容。许多程序设计语言都支持利用正则表达式进行字符串操作。
Crash基础特征描述了Crash的基本属性,通常包括:崩溃所在的模块名;崩溃所在的进程名;异常类型;崩溃所在的函数及文件;由调试分析引擎分析出的可能引发崩溃的原因;崩溃处的符号(Symbol)名;和/或调用堆栈信息,等等。
示范性地,Crash基础特征包括但是不局限于:
(1)FOLLOWUP_IP:标识Crash所在的函数及文件;
(2)ExceptionCode:标识异常类型。如:c0000005(Access violation);
(3)PRIMARY_PROBLEM_CLASS:标识WinDbg分析出的可能引发Crash的原因。如:BAD_INSTRUCTION_PTR,等等;
(4)PROCESS_NAME:标识Crash所在进程。如:QPlus.exe;
(5)MODULE_NAME:标识Crash所在模块。如:dockbar;
(6)SYMBOL_NAME:Crash处的symbol。如:dockbar!JointSelector::ClearItems+c;
(7)STACK_TEXT:详细栈信息(module!class::fuc[....cpp]....)。
步骤104:特征分析脚本根据Crash基础特征生成Crash辅助特征,并基于Crash基础特征和Crash辅助特征对Dump文件进行判定。
优选地,可以生成特征分析脚本,然有由该特征分析脚本具体执行该步骤。
比如:可以通过多种程序语言或脚本生成工具来生成特征分析脚本,而且,该特征分析脚本可以根据Crash基础特征生成Crash辅助特征,并基于Crash基础特征和Crash辅助特征对Dump文件进行判定。
示范性地,特征规则库可以包括下列特征规则中的至少一个:字符串类型Crash的判定规则;容器类型Crash的判定规则;和/或野指针类型Crash的判定规则。可以根据历史分析经验生成特征规则库,而且特征规则库可以被不断地更新完善。
比如:对于特征规则库,其中包括的规则可以包括:
(1)字符串类型Crash的判定规则:
PRIMARY_PROBLEM_CLASS=STATUS_INVALID_PARAM
SYMBOL_NAME=msvcr80!wcslen、msvcr80!wcscpy_s、msvcr80!strncpy_s.....
(2)容器类型Crash的判定规则:
PRIMARY_PROBLEM_CLASS=STATUS_INVALID_PARAM
SYMBOL_NAME=msvcr80!_invalid_parameter_noinfo
(3)野指针类型Crash的判定规则:
PRIMARY_PROBLEM_CLASS=
BAD_INSTRUCTION_PTR、INVALID_POINTER_WRITE、
INVALID_POINTER_READ;
Crash辅助特征描述了Crash的辅助属性,比如Crash作者、Crash哈希、Crash类型是否已知等等。可以基于Crash基础特征确定出Crash辅助特征。
比如:特征分析脚本可以根据调用堆栈信息获取Crash所在文件;特征分析脚本根据Crash所在文件,查询版本管理(SVN)服务器以得到崩溃代码作者(Crash_Owner);特征分析脚本根据Crash处的符号名(SYMBOL_NAME)和主要问题类(PRIMARY_PROBLEM_CLASS),计算Crash哈希(Crash_Hash);和/或特征分析脚本根据Crash哈希,查询历史Crash数据库以判定该Dump文件的Crash类型是否为已知,等等。
优选地,可以将Dump文件的Crash基础特征和Crash辅助特征保存进历史Crash数据库,并针对历史Crash数据库生成统计报表信息。
比如:可以将历史Crash数据库的表结构设计为如下所示;其中表1为Crash数据库主表结构;表2为Crash数据库明细表结构。
表1
表2
示范性地,在历史Crash数据库中,主表和明细表通过Crash_Hash连接。Crash_Hash唯一标识同一种Crash,不同的Dump文件可能对应同一个Crash_Hash。通过计算Crash_Hash,可以区分出某个Dump文件对应的Crash是否已知,从而避免重复工作。
Crash_Hash的计算公式如下所示:
Crash_Hash=MD5(MAIN_SYMBOL_NAME+SUB_SYMBOL_NAME+PRIMARY_PROBLEM_CLASS)
可以由特征分析脚本取得的Crash_Src(Crash所在文件),通过查询SVN代码服务器,可以获取造成Crash的代码作者(Crash_Owner)。在历史Crash数据库完整记录了某一次Crash相关的所有信息,通过这些信息,既可以归纳完善特征规则库,又可以生成统计报表信息,使软件稳定性的相关运营变得轻松。
基于上述详细分析,可以通过多种方式实施本发明实施方式的技术方案。比如可以在网络侧实施本发明实施方式的Dump文件自动分析方案,而将软件开发现场产生的Dump文件通过Web的方式上传到网络侧,再在网络侧针对该Dump文件执行自动分析,从而可以统一为分散在现场的软件开发者提供Dump文件自动分析服务。
在一个实施方式中,可以将转储文件的判定结果发送到产生转储文件的软件崩溃端,并在该软件崩溃端显示所述转储文件的判定结果;或将转储文件的判定结果发送到第三方崩溃分析端,并在所述第三方崩溃分析端显示所述转储文件的判定结果。
当将转储文件的判定结果发送到产生转储文件的软件崩溃端时,可以辅助软件崩溃端快速寻找到软件崩溃的现场、原因或提供相应辅助信息;当将转储文件的判定结果发送到第三方崩溃分析端时,也有助于该第三方崩溃分析端对软件崩溃的相关信息进行综合分析。
以上虽然示范性地列举出特征规则库中的具体规则以及辅助Crash特征的示范性实例,本领域技术人员可以意识到,这种罗列仅仅是阐述性的,并不用于限定本发明实施方式的保护范围。
以上虽然具体罗列了通过调度脚本、特征提取脚本和特征分析脚本的具体形式来执行本发明实施方式。本领域技术人员可以意识到,这种罗列仅是示范性的,并不用于限定本发明实施方式。比如,还可以预先生成各种格式的可执行文件或批处理命令等方式来执行本发明实施方式,本发明实施方式对于执行方式并无任何约束性限定。
比如:图2为根据本发明实施方式根据Web方式上传Dump文件及分析Dump文件的示意图。
由图2可见,软件开发者可以通过WEB站点上传需要分析的Dump文件到位于网络侧的Crash自动化分析系统。在Dump文件进入Crash自动化分析系统的数据库之前,Crash自动化分析系统可以触发WinDbg等调试分析引擎进行扫描,生成详细分析日志。
Crash自动化分析系统触发特征提取脚本提取Crash的基础特征;然后Crash自动化分析系统触发特征分析脚本依据特征规则库,对提取的Crash特征进行分析和识别,并结合查询历史Crash数据库以得出判定结果并更新历史Crash数据库。最后,Crash自动化分析系统返回分析结果页面给软件开发者,然后管理员可以通过历史Crash数据库生成统计报表信息。
基于上述详细分析,本发明实施方式还提出了一种Dump文件分析装置。
图3为根据本发明实施方式的Dump文件分析装置的结构示意图。
如图3所示,该装置包括:转储文件接收单元301、转储文件分析日志生成单元302、崩溃基础特征提取单元303和转储文件判定单元304。其中:
转储文件接收单元301,用于接收转储文件;
转储文件分析日志生成单元302,用于调度调试分析引擎对所述转储文件进行扫描,以获取转储文件分析日志;
崩溃基础特征提取单元303,用于对所述转储文件分析日志进行解析,以提取出崩溃(Crash)基础特征;
转储文件判定单元304,用于根据所述崩溃基础特征生成崩溃辅助特征,并基于所述崩溃基础特征和崩溃辅助特征对所述转储文件进行判定。
在一个实施方式中,转储文件分析日志生成单元301,用于使能预先生成的调度脚本调度调试分析引擎对所述转储文件进行扫描;
崩溃基础特征提取单元302,用于使能预先生成的特征提取脚本对转储文件分析日志进行解析,以提取出崩溃基础特征;
转储文件判定单元303,用于使能预先生成的特征分析脚本,根据崩溃基础特征生成崩溃辅助特征,并基于崩溃基础特征和崩溃辅助特征对转储文件进行判定。
在一个实施方式中,转储文件分析日志生成单元302,用于使能调度脚本以命令行的方式调度调试分析引擎,采用多线程对所述转储文件进行扫描,以获取转储文件分析日志。
在一个实施方式中,崩溃基础特征提取单元303,用于使能特征提取脚本根据预先设置的正则表达式,从转储文件分析日志中提取出崩溃基础特征。
优选地,崩溃基础特征提取单元303,用于使能特征提取脚本根据正则表达式,从转储文件分析日志中提取出以下崩溃基础特征中的至少一个:崩溃所在的模块名;崩溃所在的进程名;异常类型;崩溃所在的函数及文件;由调试分析引擎分析出的可能引发崩溃的原因;崩溃处的符号(Symbol)名;和/或调用堆栈信息,等等。
优选地,崩溃基础特征提取单元303,用于使能特征分析脚本根据预先设置的特征规则库对崩溃基础特征进行特征分析,以生成崩溃辅助特征。特征规则库包括下列特征规则中的至少一个:字符串类型崩溃的判定规则;容器类型崩溃的判定规则;和/或野指针类型崩溃的判定规则。
具体地,崩溃基础特征提取单元301,用于使能特征分析脚本根据所述崩溃基础特征生成崩溃辅助特征包括下列处理中的至少一个特征:
分析脚本根据调用堆栈信息获取崩溃所在文件;
特征分析脚本根据所述崩溃所在文件,查询版本管理(SVN)服务器以得到崩溃代码作者(Crash_Owner);
特征分析脚本根据崩溃处的符号名(SYMBOL_NAME)和主要问题类(PRIMARY_PROBLEM_CLASS),计算崩溃哈希(Crash_Hash);和/或
特征分析脚本根据崩溃哈希,查询历史崩溃数据库,以判定该转储文件的崩溃类型是否为已知。
在一个实施方式中,进一步包括统计报表信息生成单元305。其中:
转储文件接收单元301,用于通过WEB方式接收转储文件;
统计报表信息生成单元305,用于将所述转储文件的崩溃基础特征和崩溃辅助特征保存进历史崩溃数据库,并针对所述历史崩溃数据库生成统计报表信息。
优选地,转储文件判定单元303,进一步用于将所述转储文件的判定结果发送到产生所述转储文件的软件崩溃端,并在所述软件崩溃端显示所述转储文件的判定结果;或将所述转储文件的判定结果发送到第三方崩溃分析端,并在所述第三方崩溃分析端显示所述转储文件的判定结果。
基于上述详细分析,本发明实施方式还提出了一种转储文件分析系统。
图4为根据本发明实施方式的Dump文件分析系统的结构图。由图4可见,该Dump文件分析系统包括:位于本地端的转储文件发送装置401和位于网络侧的转储文件分析装置402;其中:
转储文件发送装置401,用于采集在本地的程序崩溃(Crash)所产生的Dump文件,并通过与转储文件分析装置的WEB连接向转储文件分析装置发送该Dump文件;
转储文件分析装置402,用于接收该Dump文件,并使能预先生成的调度脚本调度调试分析引擎对Dump文件进行扫描以获取转储文件分析日志;使能预先生成的特征提取脚本从所述转储文件分析日志中提取出Crash基础特征;使能预先生成的特征分析脚本根据所述Crash基础特征生成Crash辅助特征,并基于所述Crash基础特征和Crash辅助特征对所述Dump文件进行判定,并将所述判定结果发送到所述转储文件发送装置401。
综上所述,在本发明实施方式中,接收转储文件;调度调试分析引擎对所述转储文件进行扫描,以获取转储文件分析日志;对所述转储文件分析日志进行分析,以提取出崩溃(Crash)基础特征;根据所述崩溃基础特征生成崩溃辅助特征,并基于所述崩溃基础特征和崩溃辅助特征对所述转储文件进行判定。由此可见,应用本发明实施方式之后,实现了针对Dump文件的自动分析,从而提高了Dump文件分析效率。
而且,应用本发明实施方式之后,可以快速定位和解决软件Crash问题,从而提高了软件的稳定性。
不仅与此,通过实现Dump文件的自动分析,还显著降低了专业人员培训费用,从而降低了软件开发成本。
以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。