理解操作系统对程序的反馈：异常（Exception）和通知（Debug Event）

本小节首先介绍异常的原理和相关资料，再举例说明异常跟崩溃和调试是如何紧密联系在一起的。最后说明如何利用工具来监视异常，获取准确的信息。

2.3.1 异常（Exception）的方方面面和一篇字字珠玑的文章

异常是CPU，操作系统和应用程序控制代码流程的一种机制。正常情况下，代码是顺序执行的，比如下面两行：

*p=11;

printf（“%d”,*p）;

这里应该会打印出11。 但若p指向的地址是无效地址呢？那么这里对*p赋值的时候，也就是CPU向对应地址做写操作的时候，CPU就会触发无效地址访问的异常，接下来的printf很可能就不会执行了。

从这个简单的例子可以看到，当程序行为跟预期相左的时候，很可能就是异常的发生改变了程序的执行逻辑。在很多案例中，抓准异常的原因，其实就解决了问题。

异常发生的时候，由于操作系统在内核挂接了对应的 CPU异常处理函数，CPU就会跳转去执行操作系统提供的处理函数，所以printf就不一定会被执行了。在操作系统的处理函数里面，如果检测到发生在用户态的程序的异常，操作系统会再把异常信息发送给用户态进程对应的处理函数，让用户态程序有处理异常的机会。

用户态程序处理完了异常，代码会继续执行，不过执行的次序可以是紧接着的下一个指令，比如printf，也可以跳到另外的地址开始执行，比如catch block，或者重新执行一次出错的指令。这些都是用户态的异常处理函数可以控制的。

如果用户态程序没有处理这个异常，那操作系统的默认行为就是中止程序的执行，然后用户可以看到给Microsoft发送错误报告的界面，或者干脆就是一个红色的框框，说某某地址上的指令在访问某某地址的时候遭遇了访问违例的错误。

除了上面的非预期异常，也可以手动触发异常来控制执行顺序，C++/C# 中的throw关键字就可以触发异常。手动触发异常需要依赖于编译器和操作系统API来实现。

异常的类型，是通过异常代码来标识的。比如访问无效地址的号码是0xc0000005，而C++异常的号码是0xe06d7363。其他很多看似跟异常无关的东西，其实都是跟异常联系在一起的，比如调试的时候设置断点，或者单步执行，都有通过break point exception来实现的。越权指令，堆栈溢出的处理也依靠异常。在Windbg帮助文件的Controlling Exceptions and Events主题里面，有一张常用异常代码表。

程序的行为跟预期的不一样，直接原因是代码执行次序跟预期的不一样。异常改变了代码执行次序，比如代码中从来都没有什么函数跳一个红框框出来，说某某地址上的指令在访问某某地址的时候遭遇了访问违例。弄清楚异常发生的时间、地址、导致异常的指令和异常导致的结果对排错是至关重要的。

异常如此重要，所以操作系统提供了对应的调试功能，可以使用调试器来检视异常。异常发生后，操作系统在调用用户态程序的异常处理函数前，会检查当前用户态程序是否有调试器加载。如果有，那么操作系统会首先把异常信息发送给调试器，让调试器有观察异常的第一次机会，所以也叫做first chance exception，调试器处理完毕后，操作系统才让用户态程序来处理。

如果用户态程序处理了这个异常，就没调试器什么事了。否则，程序在unhandled exception崩溃前，操作系统会给调试器第二次观察异常的机会，所以也叫做second chance exception。

请注意，这里的1st chance, 2nd chance是针对调试器来说的。虽然C++异常处理的时候也会有first phrase find exception handler, second phrase unwind stack这样的概念，但是两者是不一样的。

操作系统提供的异常处理功能叫做 Structrued Exception Handle（SEH），C++和其他高级语言的异常处理机制都是建立在SEH上的。如果要直接使用SEH，可以在C/C++中使用__try，__except关键字。

关于异常处理的详细信息，所有的来龙去脉，操作系统做了些什么事情，C++编译器做了些什么事情，SEH和C++异常处理的关系，以及调试器是如何参与的，下面几篇文章有非常详细的介绍。

A Crash Course on the Depths of Win32™ Structured Exception Handling

http://www.microsoft.com/msj/0197/Exception/Exception.aspx

这篇文章出来后，没见人写第二篇了。深入浅出，字字珠玑。

RaiseException

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/raiseexception.asp

注意，上面链接中，remark section详细介绍了异常处理函数是如何被分发的。

案例分析：如何让C++像C#一样打印出函数调用栈（callstack）

如果用C#或者Java，在异常发生后，可以获取异常发生时刻的call stack。但是对于C++，除非使用调试器，否则是看不到的。现在用户想尽可能少地修改代码，让C++程序在异常崩溃后，能够打印出call stack，有什么方法呢？

我的解法是直接使用SEH，加上局部变量析构函数在异常发生时候会被执行的特点来完成。这个例子当时使用VC6在Windows 2003上调试通过。当重新整理这个例子的时候，发现这段代码在VC2005+Windows 2003 SP1上有奇怪的现象发生。如果用debug模式编译，运行正常。如果用release模式编译，程序会在没有任何异常报告的情况下悄然退出。关于整个源代码和对应的分析，请参考：

SEH,DEP, Compiler,FS:[0] and PE format

      http://eparg.spaces.msn.com/blog/cns!59BFC22C0E7E1A76!712.entry

2.3.2 Adplus，抓取dump的方便工具

前面提到了dump文件能保存进程状态，方便分析。由于dump文件记录的是进程某一时刻的具体信息，所以保存dump的时机非常重要。比如程序崩溃，dump应该选在引发崩溃的指令执行时（也就是1st chance exception发生的时候）获取，这样分析dump的时候就能够看到问题的直接原因。

Adplus是跟Windbg在同一个目录的VBS脚本。Adplus主要是用来抓取dump文件。 详细的信息，可以参考Windbg帮助文件中关于adplus的帮助。有下面一些常见用法：

假设我们的目标程序是test.exe：

假设test.exe运行一段时间崩溃，在test.exe启动后崩溃前的这个时间段，运行下面的命令监视：

Adplus –crash –pn test.exe –o C:\dumps

当test.exe发生2nd chance exception崩溃的时候，adplus在C:\dumps生成full dump文件。当发生1st chance AV exception, 或者1st chance breakpoint exception的时候，adplus在C:\dumps生成mini dump文件。

也可以用：

Adplus –crash –pn test.exe –fullonfirst –o C:\dumps

差别在于，加上-fullonfirst参数后，无论是1st chance exception还是2nd chance exception，都会生成full dump文件。

假如test.exe发生deadlock，或者memory leak，并不是crash，需要获取任意时刻的一个dump，可以用下面的命令：

Adplus –hang –pn test.exe –o C:\dumps

该命令立刻把test.exe的full dump 抓到C:\dumps下。

Adplus更灵活的方法就是用-c参数带配置文件。在配置文件里面，可以选择exception发生的时间，生成的dump是mini dump还是full dump，还可以设定断点等等。对于adplus各项参数的选用原则，在最后一章还会作进一步介绍。

案例分析：华生医生（Dr. Watson）在什么情况下不能记录Dump文件

问题描述

客户声称用VC开发的程序偶尔会崩溃。为了获取详细信息，客户激活了Dr. Watson，以便程序崩溃的时候可以自动获取dump文件。但是问题再次发生后，Dr. Watson并没有记录dump文件。

背景知识

dump文件包含的是内存镜像信息。在Windows 系统上，dump文件分为内核dump和用户态dump两种。前者一般用来分析内核相关的问题，比如驱动程序；后者一般用来分析用户态程序的问题。如果不作说明，本书后面所指的dump都表示用户态dump。用户态的dump又分成mini dump和full dump。前者尺寸小，只记录一些常用信息；后者则是把目标进程用户态的所有内容都记录下来。Windows提供了MiniDumpWriteDump API可供程序调用来生成mini dump。通过调试器和相关工具，可以抓取目标程序的full dump。拿到dump后，可以通过调试器检查dump中的内容，比如call stack，memory，exception等等。关于dump和调试器的更详细信息，后面会有更多介绍。跟Dr. Watson相关的文档是：

Description of the Dr. Watson for Windows (Drwtsn32.exe) Tool

http://support.microsoft.com/?id=308538

Specifying the Debugger for Unhandled User Mode Exceptions

http://support.microsoft.com/?id=121434

INFO: Choosing the Debugger That the System Will Spawn

http://support.microsoft.com/?id=103861

也就是说，通过设定注册表中的AeDebug项，可以在程序崩溃后，选择调试器进行调试。选择Dr. Watson就可以直接生成dump文件。

问题分析

回到这个问题，客户并没有获取到dump文件，可能性有两个：

1.         Dr. Watson工作不正常。

2.         客户的程序根本没有崩溃，不过是正常退出而已。

为了测试第1点，提供了如下的代码给客户测试：

int *p=0;

*p=0;

测试上面的代码，Dr. Watson成功地获取了dump文件。也就是说，Dr. Watson工作是正常的。那看来客户声称的崩溃可能并不是unhandled exception导致的。说不定在非预料情况下调用了ExitProcess，被客户误认为是崩溃。所以，抓取信息不应该局限于unhandled exception，而应该检查进程退出的原因。

当程序在Windbg调试器中退出的时候，系统会触发调试器的进程退出消息，可以在这个时候抓取dump来分析进程退出的原因。

如果让客户每次都先启动Windbg，然后用 Windbg启动程序，操作起来很复杂。最好有一个自动的方法。Windows提供了让指定程序随调试器启动的选项。设定注册表后，当设定的进程启动的时候，系统先启动指定的调试器，然后把目标进程的地址和命令行作为参数传递给调试器，调试器再启动目标进程调试。这个选项在无法手动从调试器中启动程序的时候特别有用，比如调试先于用户登录而启动Windows Service程序，就必须使用这个方法：

How to debug Windows services

http://support.microsoft.com/?kbid=824344

有趣的是，好多恶意程序也通过这个方法来达到加载进程的目的。很多人把这个方法叫做IFEO 劫持（Image File Execution Option Hacking）。

在Windbg目录下，有一个叫做adplus.vbs的脚本可以方便地调用Windbg来获取dump文件。所以这里可以借用这个脚本：

How to use ADPlus to troubleshoot "hangs" and "crashes"

http://support.microsoft.com/kb/286350/EN-US/

脚本的详细说明可以参考adplus /?的帮助。

新的做法

结合上面的信息，具体做法是：

1.         在客户机器的Image File Execution Options注册表下面创建跟问题程序同名的键。

2.         在这个键的下面创建Debugger字符串类型子键。

3.         设定Debugger= C:\Debuggers\autodump.bat。

4.         编辑C:\Debuggers\autodump.bat文件的内容为如下：

cscript.exe C:\Debuggers\adplus.vbs -crash -o C:\dumps -quiet -sc %1

通过上面的设置，当程序启动的时候，系统自动运行 cscript.exe来执行adplus.vbs脚本。Adplus.vbs脚本的-sc参数指定需要启动的目标进程路径（路径作为参数又系统传入，bat文件中的%1代表这个参数），-crash参数表示监视进程退出，-o参数指定dump文件路径，-quiet参数取消额外的提示。可以用 notepad.exe作为小白鼠做一个实验，看看关闭notepad.exe的时候，是否有dump产生。

根据上面的设定，问题再次发生后，C:\dumps目录生成了两个dump文件。文件名分别是：

PID-0__Spawned0__1st_chance_Process_Shut_Down__full_178C_DateTime_0928.dmp

PID-0__Spawned0__2nd_chance_CPlusPlusEH__full_178C_2006-06-21_DateTime_0928.dmp

注意看第二个的名字，这个名字表示发生2nd chance的C++ exception！打开这个dump后找到了对应的call stack，发现的确是客户忘记了catch潜在的C++异常。修改代码添加对应的catch后，问题解决。

问题解决了，可是为什么华生医生（Dr. Watson）抓不到dump呢

当然疑问并没有随着问题的解决而结束。既然是unhandled exception导致的crash，为什么Dr. Watson抓不到呢？首先创建两个不同的程序来测试Dr. Watson的行为：

int _tmain(int argc, _TCHAR* argv[])

{

throw 1;

return 0;

}

int _tmain(int argc, _TCHAR* argv[])

{

int *p=0;

*p=0;

return 0;

}

果然，对于第一个程序，Dr. Watson并没有保存dump文件。对于第二个，Dr. Watson工作正常。看来的确跟异常类型相关。

仔细回忆一下。当AeDebug下的Auto设定为0的时候，系统会弹出前面提到的红色框框。对于上面这两个程序，框框的内容是不一样的。

在我这里，看到的对话框分别是（对话框出现的时候用Ctrl+C保存的信息）：

---------------------------

Microsoft Visual C++ Debug Library

---------------------------

Debug Error!

Program: d:\xiongli\today\exceptioninject\debug\exceptioninject.exe

This application has requested the Runtime to terminate it in an unusual way.

Please contact the application's support team for more information.

(Press Retry to debug the application)

---------------------------

Abort   Retry   Ignore  

---------------------------

---------------------------

exceptioninject.exe - Application Error

---------------------------

The instruction at "0x00411908" referenced memory at "0x00000000". The memory could not be "written".

Click on OK to terminate the program

Click on CANCEL to debug the program

---------------------------

OK   Cancel  

---------------------------

两者行为完全不一样！如果做更多的测试，会发现对话框的细节还跟编译模式release/debug 相关。

程序可以通过 SetUnhandledExceptionFilter函数来修改unhanded exception的默认处理函数。这里，C++运行库在初始化CRT（C Runtime）的时候，传入了CRT的处理函数（msvcrt!CxxUnhandledExceptionFilter）。如果发生unhandled exception，该函数会判断异常的号码，如果是C++异常，就会弹出第一个对话框，否则就交给系统默认的处理函数（kernel32!UnhandledExceptionFilter）处理。第一种情况的call stack 如下：

USER32!MessageBoxA

MSVCR80D!__crtMessageBoxA

MSVCR80D!__crtMessageWindowA

MSVCR80D!_VCrtDbgReportA

MSVCR80D!_CrtDbgReportV

MSVCR80D!_CrtDbgReport

MSVCR80D!_NMSG_WRITE

MSVCR80D!abort

MSVCR80D!terminate

MSVCR80D!__CxxUnhandledExceptionFilter

kernel32!UnhandledExceptionFilter

MSVCR80D!_XcptFilter

第二种情况CRT交给系统处理。Callstack如下：

ntdll!KiFastSystemCallRet

ntdll!ZwRaiseHardError+0xc

kernel32!UnhandledExceptionFilter+0x4b4

release_crash!_XcptFilter+0x2e

release_crash!mainCRTStartup+0x1aa

release_crash!_except_handler3+0x61

ntdll!ExecuteHandler2+0x26

ntdll!ExecuteHandler+0x24

ntdll!KiUserExceptionDispatcher+0xe

release_crash!main+0x28

release_crash!mainCRTStartup+0x170

kernel32!BaseProcessStart+0x23

详细的信息可以参考：

SetUnhandledExceptionFilter

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/setunhandledexceptionfilter.asp

UnhandledExceptionFilter

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/unhandledexceptionfilter.asp

上面观察到的信息能解释Dr. Watson的行为吗？看起来似乎有关系。为了进一步确认这个问题，可以通过下面的测试，使用Windbg代替Dr. Watson，看看是否可以获取dump。如果仅仅换一个调试器就可以获取dump，那说明问题是跟调试器相关，跟程序抛出的异常无关。具体做法是：

1.         运行drwtsn32.exe –i注册Dr. Watson。

2.         打开AeDebug注册表，找到Debugger项，里面应该是drwtsn32 -p %ld -e %ld -g。

3.         修改Debugger为: C:\debuggers\windbg.exe -p %ld -e %ld -c ".dump /mfh C:\myfile.dmp ;q"。

当unhanded exception发生后，系统会启动windbg.exe作为调试器加载到目标进程。但是windbg.exe不会自动获取dump，所以需要用-c参数来指定初始命令。命令之间可以用分开分割。这里的.dump /mfh C:\myfile.dmp命令就是用来生成dump文件的。接下来的q命令是让windbg.exe在dump生成完毕后自动退出。用这个方法，对于 unhandled C++ exception，windbg.exe是可以获取dump文件的。所以我认为Dr. Watson这个工具在获取dump的时候是有缺陷的。研究的发现在：

    http://eparg.spaces.msn.com/blog/cns!59BFC22C0E7E1A76!1213.entry