当前位置:首页 > 开发 > 编程语言 > 编程 > 正文

Windows 异常处理的研究的总结

发表于: 2014-03-19   作者:aigo   来源:转载   浏览次数:
摘要: 原文: http://www.cnblogs.com/yangchaobj/archive/2013/02/23/2923416.html http://www.cnblogs.com/yangchaobj/archive/2013/02/23.html   最近半年单位的项目集中上线,出了一些 crash 的问题。 程序crash 后,会自动生成一个 dump 文件,这是通过

原文:

http://www.cnblogs.com/yangchaobj/archive/2013/02/23/2923416.html

http://www.cnblogs.com/yangchaobj/archive/2013/02/23.html

 

最近半年单位的项目集中上线,出了一些 crash 的问题。

程序crash 后,会自动生成一个 dump 文件,这是通过调用系统API MiniDumpWriteDump 实现的。

 

通过事后对 dump 文件的分析,工程师可以找到出问题的点。

不方便的是,每次打开dump文件后,堆栈总是停在类似 ntdll!KiFastSystemCallRet 的地方,通过这个 callstack 完全找不到任何程序的蛛丝马迹。而是用 .ecxr 则报错,说没有 ContextRecord. 工程师需要执行 windbg 的 s 命令,在堆栈中寻找 ExceptionContext 去恢复现场,对于做过的人稍有些麻烦,对于生手就比较困难了。

*具体搜索思路是:根据ContextRecord 的定义,第一个成员是异常号,比如 0xc0000005,那就在堆栈上搜这个异常号:s -d esp L1000 0xc0000005

如果是 x64平台,用 s -d rsp L1000 0xc0000005

一般会找到2-3个匹配的堆栈地址,再逐个去试,就很容易找到。

还有一个问题,有时候 dump 文件可以生成,有时候程序直接退出,没有任何 dump。

 

基于这些现象,我有了一些问题:

1. 能否不用每次手动寻找 ExceptionContext ,而让 windbg 直接重现现场。

2. 能否保证所有的异常都被捕获并生成 dump (当然是在外围条件都满足的情况下)

由这个 Dump 文件引发了我一系列的研究和学习。现在将成果总结如下。

 

在windbg 定位的时候,需要用到 .cxr 指令,通过查windbg帮助手册,了解到这个指令是 Display Context Record 的缩写。在异常发生时,windows 会将异常发生时的各个寄存器数值、堆栈位置等记录下来,存在一个 ContextRecord 结构里,并把这个结构压入堆栈。.cxr 命令还带一个地址参数,用来指定 ContextRecord 的位置。这个结构对于能否恢复堆栈起着决定性的作用。

通过读《Windows核心编程(第5版)》,了解到windows会在异常发生时,向堆栈上压入3个结构体:ExceptionRecord, ContextRecord, EXCEPTION_POINTERS。

只要生成 dump 文件时这三个结构体还没有出栈,则通过搜索堆栈是一定可以找到ContextRecord,就一定可以恢复堆栈。

但为什么每次要手动搜索 ContextRecord 呢?经过研究MiniDumpWriteDump,有了答案:

BOOL WINAPI MiniDumpWriteDump(
__in HANDLE hProcess,
__in DWORD ProcessId,
__in HANDLE hFile,
__in MINIDUMP_TYPE DumpType,
__in PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
__in PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
__in PMINIDUMP_CALLBACK_INFORMATION CallbackParam
);

第5个参数 ExceptionParam,是一个结构地址,这个结构的定义如下:

typedef struct _MINIDUMP_EXCEPTION_INFORMATION { 
    DWORD ThreadId; 
    PEXCEPTION_POINTERS ExceptionPointers; 
    BOOL ClientPointers;
} MINIDUMP_EXCEPTION_INFORMATION, *PMINIDUMP_EXCEPTION_INFORMATION;

结构体的第二个参数就是 EXCEPTION_POINTERS,而这个指针的第二个成员就是 ContextRecord。

之前生成 dump 的时候,并没有将这个结构填好传给 MiniDumpWriteDump,所以才造成直接用 .ecxr 命令找不到 ContextRecord 的错误。

通过修改代码,在异常发生时将 EXCEPTION_POINTER 保存下来(如果能确保生成 dump 时,堆栈上的 ContextRecord 依然有效,则仅保留EXCEPTION_POINTER的地址即可)。

调用 MiniDumpWriteDump 时将这个 EXCEPTION_POINTER 给传进去,就可以做到 .ecxr 指令自动恢复堆栈定位错误行了。

 

问题:有些异常可以捕获,生成 dump,有些则不能。

要解决这个问题,必须对 windows 和 C++ 的异常机制有一个了解。

 

平时我们写程序都这样捕获异常:

 1 try
 2 {
 3     fire_access_violation();
 4 }
 5 catch (exception& ex)
 6 {
 7     // ......
 8 }
 9 catch (...)
10 {
11     // ......
12 }

第3行的函数会触发 ACCESS_VIOLATION (0xC0000005) 异常,第5行用来catch 普通的 C++异常,第9行用来捕获其他异常,ACCESS_VIOLATION 就属于这种异常。

但运行后发现,第9行的 catch (...) 什么也抓不到。要让它起作用,还需要调整默认的编译参数,找到 C++ -> Code Generation -> Enable C++ Exceptions 选项,设为 Yes with SEH Exceptions (/EHa),即通过SEH机制,让C++的 catch (...) 能够捕获所有的异常

这一步做下来,我们已经可以捕获try 块上的所有异常了。但虽然捕获了异常,我们还无法知道异常类型。也没有前文所说的 ContextRecord 信息。要更精确的得到这些信息,还需要多做一步:把 SEH 映射成C++异常。

 

C 提供了一个函数 _set_se_translator

_se_translator_function _set_se_translator(
    _se_translator_function seTransFunction
);

typedef void (*_se_translator_function)(unsigned int, struct _EXCEPTION_POINTERS* );

 

这个函数要尽量早的注册到系统,所以在线程一开始的时候,就要调用这个函数。

它给本线程设置一个异常转换函数,当有 SEH 异常发生时,会调到用户注册的 _se_translator_function,传入 exception code 和 EXCEPTION_POINTERS,这时我们需要自己生成一个结构体,把这些非常有用的信息存在结构体里。还是那句话:如果能确保异常处理还在本堆栈上,并且异常信息还没有出栈,则存一个指针即可,否则要把 EXCEPTION_POINTERS 的整个结构复制过来,在遇到嵌套异常时,他的成员 ExceptionRecord 有可能是一个链表,如何保存这个链表还是件比较麻烦的事儿,所以能在原地处理异常时最好

转换函数看起来可以是这样:

 1 struct StructuredException : public exception
 2 {
 3     PEXCEPTION_POINTERS  exp_ptr;
 4 
 5     StructuredException() : exception() {}
 6     StructuredException(const char* text) : exception(text) {}
 7 };
 8 
 9 void trans_func(unsigned int code, EXCEPTION_POINTERS* p)
10 {
11     cout << "Exception Record: " << p->ExceptionRecord << endl;
12     StructuredException se;
13     se.exp_ptr = p;
14     throw se;
15 }

 

StructuredException 从 C++ 异常 exception 继承。只要安装了 tranlator 的线程内发生了结构化异常,windows 就会在该线程上调用次函数

最后一句即第14行,抛出StructuredException,即抛出一个C++异常。通过 catch (exception& ex) 就可以捕获它。当然为了区别处理结构化异常,也可以这也写 catch (StructuredException& se) {...},毕竟结构化异常的出现时超出预期的。

 

到了这一步,可以保证每个线程都在我们的保护之下。但还有一些线程不是我们自己写的,可能是一些库自己创建的,这些线程有可能没有try块的保护,如果这些线程发生了异常,还是会造成程序悄悄退出,没有 dump。windows 也提供了方法来抓住这种漏网之鱼。

 

Windows 提供了 UnhandledExceptionFilter 来处理那些没被 catch 住的异常。

 1 LPTOP_LEVEL_EXCEPTION_FILTER WINAPI SetUnhandledExceptionFilter(
 2   __in  LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter
 3 );
 4 
 5 LONG WINAPI UnhandledExceptionFilter(
 6   __in  struct _EXCEPTION_POINTERS* ExceptionInfo
 7 );
 8 
 9 LONG WINAPI unhandled_exception_filter(__in struct _EXCEPTION_POINTERS *ExceptionInfo)
10 {
11     // do something
12     return EXCEPTION_CONTINUE_SEARCH; // EXCEPTION_EXECUTE_HANDLER
13 }

 

整个进程设置一个 filter 就可以拦住进程内任何线程抛出的漏网的异常。如果你用 debugger 调试 filter 代码,会发现它从来不会被调到,因为异常已经被 debugger 拦下来了,于是就不是“漏网之鱼”,所以这个 filter 不会被调到。

可以看到 filter 的参数里也有 EXCEPTION_POINTERS,所以在这个 filter 函数里我们可以调用 MiniDumpWriteDump 生成我们需要的 dump 文件。filter被调到的线程就是发生异常的线程。

 

做到这一步,进程内几乎所有的异常都会被我们捕获到并通过 mini dump 文件把现场保存下来以供事后分析。

为什么说是“几乎所有”呢,还是有一些特殊情况下的异常无法被捕获到:

当遇到 Heap Corrupt 异常时(两次 delete 同一块内存地址就会出现这种异常),windows有两种处理策略:杀掉进程或者不杀。在64位的 windows server 下,当堆发生错误时,系统会直接杀死进程,不会有全局展开,异常捕获函数什么都不活不到,这种异常代码是:0xc0000374,这时需要外挂 windbg 或 cdb 来帮助我们 dump。

如果 mini dump 的参数设的过于“求全”,既要保存堆栈信息又要保持堆信息,系统很可能没有足够的硬盘空间来保持 dump 文件,这样 mini dump 也会失败。

但无论如何,只要进程非正常退出,总会在系统事件中记上一笔,我们在 Event Viewer 里就可以看到。

 

总结:

通过 /Eha 编译参数,我们可以既捕获C++异常,又捕获结构化异常。

通过 _set_se_tranlator 可以把结构化异常转换成C++异常,并保存异常发生的现场(需要 /Eha 参数)。

通过 SetUnhandledExceptionFilter,可以捕获没有 try-catch/__try __except 保护的线程上抛出的异常。

通过 MiniDumpWriteDump 加上我们保存的异常现场信息,我们可以在生成 mini dump 时把 进程id、线程id、发生异常的时间、ContextRecord 都写进 mini dump(前三项通过文件名的形式),极大的方便后期调试。

通过以上努力,可以保证绝大多数异常都会被捕获并保存下现场信息。

Windows 异常处理的研究的总结

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

编辑推荐
一、 异常的概念和Java异常体系结构 异常是程序运行过程中出现的错误。本文主要讲授的是Java语言的
异常:是在程序执行期间中断指令的正常流程的事件。 关键字:try、catch、throw、finally、throws。
原文:http://www.ibm.com/developerworks/cn/java/j-lo-exception-misdirection/index.html 本文着
原文:http://www.ibm.com/developerworks/cn/java/j-lo-exception-misdirection/index.html 本文着
哈尔滨理工大学软件工程专业08-7李万鹏原创作品,转载请标明出处 http://blog.csdn.net/woshixingaa
哈尔滨理工大学软件工程专业08-7李万鹏原创作品,转载请标明出处 http://blog.csdn.net/woshixingaa
有两种方式可以在 PHP 中以异常的方式处理错误: ① PHP 内置的 ErrorException 类(也是 Exception
一、摘要 由于硬件问题、系统资源紧缺或者程序本身的BUG,Java服务在线上不可避免地会出现一些“系
目录 Windows Phone 7页面导航的方法 2 NavigationService.Navigate Method 2 Parameters 2 Return
声明: 原创作品, 转载时请注明文章来自 SAP师太 技术博客( 博/客/园www.cnblogs.co
版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号