中断通常是由CPU外部的输入输出设备（硬件）所触发的，供外部设备通知CPU”有事情要处理“，因此又称为中断请求。中断请求的目的是希望CPU暂时停止执行当前执行的程序，转去执行中断请求所对应的中断处理例程。

与中断不同，异常通常是CPU在执行指令时，即当CPU在执行程序指令时遇到操作数有错误或检测到指令规范中定义的非法情况。前者的一个典型例子是执行除法指令时遇到除数为0，后者的典型例子包括在用户模式下执行特权指令等。第二种来源是某些特殊指令，这些指令的预期行为就是产生相应的异常，比如INT 3指令的目的就是产生一个断点异常，让CPU中断进调试器。换句话说，这个异常是”故意“产生的，是预料内的。这样的指令还有INTO，INT O和BOUND。第三种来源是奔腾CPU引入的机器检查异常，即当CPU执行指令期间检测到CPU内部或外部的硬件错误。

中断与异常的根本差异是：异常来自于CPU本身，是CPU主动产生的；而中断则是来源于外部设备，是中断源发起的，CPU是被动的。

根据CPU报告异常的方式和导致异常的指令是否可以安全地重新执行，IA-32 CPU把异常分为3类：错误(fault)，陷阱(trap)和中止(abort)。

导致错误类异常地情况通常可以被纠正，而且一旦纠正以后，程序可以无损失地恢复执行，此类异常最常见地一个例子就是缺页异常。

当CPU报告错误类异常时，CPU将其恢复成导致该异常的指令被执行之前的状态。而且在CPU转去执行异常处理程序前，在栈钟保存的CS和EIP指针是指向导致异常的这条指令（而不是下一条指令）。因此，当异常处理程序返回继续执行时，CPU接下来执行的第一条指令依然是刚才导致异常的那条指令。所以，如果导致异常的情况没有被消除，那么，CPU将会再次产生异常。

与错误类异常不同，当CPU报告陷阱类异常时，导致该异常的指令已经执行完毕，压入栈钟的CS和EIP值（即异常处理程序的返回地址）是导致该异常的指令执行后紧接着要执行的下一条指令。值得说明的是，下一条指令并不一定是与导致异常的指令相邻的下一条。如果导致异常的指令是跳转指令或函数调用指令，那么下一条指令可能是内存地址不相邻的另一条指令。

导致陷阱类异常的情况通常也是可以无损失地恢复执行的。比如INT 3指令导致的断点异常就属于陷阱类异常，该异常会使CPU中断到调试器，从调试器返回后，被调试器程序可以继续执行。

中止类异常主要是用来报告严重的错误，比如硬件错误和系统表中包含非法值或不一致的状态等。这类异常不允许恢复继续执行。原因有二：首先，当这类异常发生时，CPU并不总能保证报告的导致异常的指令地址是精确的。其次，出于安全性考虑，这类异常可能是由于导致该异常的程序执行非法操作导致的，因此就应该强迫其中止退出。

下表是这三类异常的关键特征：

在保护模式下，当有中断或异常发生时，CPU是通过中断描述符表（IDT）来寻找处理函数的。因此，可以说IDT是CPU（硬件）与操作系统（软件）交接的中断和异常的关口。操作系统在启动早期的一个重要任务就是设置IDT，准备好处理异常和中断的各个函数。每个中断或异常都被赋予了一个整数ID，称为向量号。系统根据向量号从IDT表中查找相应的中断或异常的处理例程。IA-32架构规定0~31号向量供CPU设计者使用，32~255号向量（224个）供操作系统和计算机系统生产厂商或其他软硬件开发商使用。下表归纳了PC系统中常见向量号对应的中断和异常：

CPU在同一时间只能执行一个程序，如果多个中断请求或异常情况同时发生，CPU就会按照优先级高低次序依次处理，先处理优先级最高的。下表是IA-32架构定义的10个中断/异常优先级别：

在操作系统层次有两类异常：

CPU异常（硬件异常）：由CPU产生的

软件异常：通过软件方式模拟出的异常，比如调用RaiseException API而产生的异常和使用编程语言的throw关键字抛出的异常

无论是哪类异常，Windows操作系统都用EXCEPTION_RECORD结构来描述它，该结构的定义如下：

对于ExceptionFlags标志位，目前已定义的标志位如下：

EH_NONCONTINUABLE(1)：该异常不可恢复继续执行

EH_UNWINDING(2)：当因为执行栈展开而调用异常处理函数时，会设置此标志

EH_EXIT_UNWIND(4)：也是用于栈展开，较少使用

EH_STACK_INVALID(8)：当检测到栈错误时，设置此标志

EH_ENSTED_CALL(0x10)：用于表示内嵌的异常

下图则是ExceptionCode对应的用于异常的状态码：

对于产生的CPU异常，处理器会根据IDT表查询到需要执行的函数，如下所示是部分产生了CPU异常以后会执行的处理例程：

以除0异常调用的KiTrap0为例，函数会首先对陷阱帧进行填充，然后对cs寄存器进行判断

接着对进程的成员进行判断，最终都会跳到loc_5074AB执行

loc_4075AB处的代码会对ebx和eax分别赋值为Eip和异常状态码，然后跳转到loc_407399

而loc_407399的代码仅仅是清空ecx，此时的ecx保存的其实是参数的个数，由于除0异常无需传参，所以ecx为0，而将其他信息作为附带参数（最多3个）的时候，会分别将参数放入EDX(参数一), ESI(参数二), EDI(参数三), 接着调用CommonDispatchException函数

CommonDispatchException会在栈上开辟空间，在根据传递的参数来为开辟的结构体EXCEPTION_RECORD赋值，随后调用KiDispatchException函数来完成异常的分发

软件异常的实现是需要取决于编译器的，对于vs2017来说，可以使用throw关键字来产生软件异常，该关键字是通过调用_CxxThrowException函数来实现的

而_CxxThrowException函数则会调用kernel32.dll中的RaiseException，此时的传入的第一个参数在RaiseException中会赋给ExceptionCode，此时是0xE06D7363，该值取决于编译器，每次调用的时候都是这个数值

在RaiseException函数中会开辟栈空间用来保存EXCEPTION_RECORD结构，异常发生的地址ExceptionAddress则固定为_RaiseException，而不是异常发生地址。随后调用ntdll.dll中的RtlRaiseException，该函数会将执行上下文（通用寄存器等）放入CONTEXT结构，然后通过系统服务调用机制调用内核函数KiRaiseException

NtRaiseException函数会继续调用KiRaiseException

KiRaiseException会将CONTEXT保存到TrapFrame中，调用KiDispatchException来实现异常的分发

综上所述，无论是CPU异常还是软件异常，尽管产生的原因不同，但最终都会调用内核中的KiDispatchException来分发异常，也就是说，Windows系统是使用统一的方法来分发CPU异常和软件异常

Windows内核中的KiDispatchException函数是分发各种Windows异常的枢纽。其函数原型如下：

下图为KiDispatchException函数的执行流程，该函数首先调用KeContextFromKframes函数来将参数TrapFrame中的内容保存到CONTEXT中，以供向调试器和异常处理器函数报告异常时使用，接下来根据先前模式来选择操作流程

根据IDA反汇编的结果可以看到KiDispatchException首先对局部变量进行赋值，然后再根据先前模式以及是否存在调试器来修改CONTEXT结构中的ContextFlags

将TrapFrame中的数据保存到Context中，判断是否为断点异常，如果是断点异常，将EIP减掉1

如果不是断点异常就会根据异常代码选择是否为KI_EXCEPTION_ACCESS_VIOLATION来选择是否要将异常代码改成EXCEPTION_ACCESS_VIOLATION

根据先前模式来选择执行流程

对于内核异常，首先会判断是否是第一次执行，如果是第一次执行就会继续判断是否存在内核调试器，如果存在内核调试器此时的KiDebugRoutine就会保存内核调试引擎的KdpTrap。如果该函数调用成功，返回值就会为1，否则会0

无论是不存在内核调试器还是KdpTrap函数执行失败，都会跳转到loc_4335A6处执行，此时会调用RtlDispatchException函数来处理异常，如果函数执行成功就会返回1，否则返回0

判断返回值是否为1，也就是是否成功处理了异常

如果为1，接下来就会将保存再CONTEXT结构中的数据复制到TrapFrame中，退出函数

如果为0，继续判断是否有内核调试器，如果有就继续调用KiDebugRoutine中保存的函数来处理异常

如果此时不存在内核调试器或者KiDebugRoutine中的函数没有处理掉异常，接下来就会产生蓝屏

如果处理掉了，就会跳转到上面的loc_424AC8来恢复陷阱帧，退出函数。退出函数以后，接下来就会返回到CommonDispatchException执行，该函数会通过iretd返回用户层。

对于用户异常，同样会首先判断是否是第一次执行，是的话继续判断是否存在内核调试器，如果存在内核调试器且调试端口为0，则会调用KdpTrap函数，如果返回值为1，即成功处理了异常，就会跳转到loc_424AC8退出函数

如果不存在内核调试器，或内核调试函数并没有成功处理异常，接下来就会通过调用函数DbgForwardException来将异常发给调试子系统处理，如果成功处理则返回1

如果没有处理成功，就会将陷阱帧中的EIP修改为_KiUserExceptionDispatcher，随后退出函数。这样，当程序返回到用户层的时候，就会执行函数_KiUserExceptionDispacher，该函数是在ntdll.dll中

在KiUserExceptionDispatcher中会通过调用RltDispatchException来处理异常，如果处理成功，返回值为1，接下来就会调用ZwContinue来修正陷阱帧中的EIP恢复执行

否则就会调用ZwRaiseException

ZwRaiseException就会再次进入内核层调用NtRaiseException

此时运行到KiDispatchException先前模式为用户模式清空下，判断是否为第一次运行的时候会跳转到loc_44B196运行，因为此时不是第一次运行

在loc_440F9E中，函数会两次调用DbgkForwardException来处理异常，如果处理成功，则返回值为1，然后正常退出函数，如果处理失败，接下来就会结束进程，出现蓝屏

无论是用户层还是内核层都会通过调用RtlDispatcherException来完成异常处理，只不过前者在ntdll.dll中，后者在内核中，两个函数功能和执行逻辑是基本一致的，不过由于“服务”对象不同，它们分别存在于两个模块中

从Windows XP系统开始，Windows支持通过以下两种异常处理机制来处理异常。

SEH：结构化异常处理机制

VEH：向量化异常处理机制

其中SEH既可以在用户模式下和内核模式下都可以使用，而VEH只能在用户模式下使用。在ntdll.dll中和内核中的异常处理函数RtlDispatchException最大的区别也就是ntdll.dll的异常处理函数是处理用户模式下的异常，此时会先调用函数RtlCallVectoredExceptionHandler函数通过VEH来处理异常，如果返回值非0，则处理完成，否则会继续通过SEH处理异常。

VEH的基本思想是通过注册以下原型的回调函数来接收和处理异常。

参数ExceptionInfo是指向EXCEPTION_POINTERS结构的指针，该结构包含了指向CONTEXT结构和异常记录结构的指针，定义如下：

通过AddVectoredExceptionHandler可以注册回调函数，如下是函数定义：

如果注册成功，返回值指向的是系统为该异常处理器分配的结构(VEH_REGISTERATION)指针，应用程序应该保存这个指针，以便销毁向量化异常处理器时使用；如果注册失败，返回值就为0。

在AddVectoredExceptionHandler内部，会为每个向量化异常处理器分配一个类型如下结构的长度（长为12字节）。

当有多个向量化异常处理器时，这些向量化异常处理器的VEH_REGISTRATION结构组成一个环状链表。ntdll.dll中的全局变量RtlpCalloutEntryList指向该链表的头。

RemoveVectoredExceptionHandler函数用来注销向量化异常处理器，也就是将一个向量化异常处理器从RtlpCalloutEntryList所指向的链表中移除，该函数定义如下：

其中的参数就是通过AddVectorExceptionHandler注册异常处理器成功时的返回值。

前面说过，和内核的异常处理函数相比，ntdll.dll中的异常处理函数会首先通过调用函数RtlCallVectoredExceptionHandler来给向量化异常处理器优先的处理机会。

RtlCallVectoredExceptionHandler会直接判断全局链表RtlpCalloutEntryList中是否有向量化异常处理器，如果没有则将al清空作为返回值，也就是返回FALSE

如果有的话，会对局部变量赋值，调用RtlEnterCriticalSection函数防止其他线程访问链表

接下来会遍历链表，通过RtlDecodePointer函数来=获得向量化异常处理器的回调函数，然后调用这个回调函数，此时压入会将pExceptRec的地址压入栈中，而紧邻该变量的地址保存的就是参数pContext，所以此时传入的其实是EXCEPTION_POINTERS结构体参数

如果成功处理异常，此时的返回值为-1，就会将局部变量赋值为1，跳转到loc_7C962647处执行代码

如果遍历完链表依然没有成功，就会将局部遍历赋值为0

赋值完以后执行的代码和成功处理异常以后执行的代码是一样的，此时将局部变量保存的结果赋给al作为返回值

最后退出函数

此时如果任何一个向量化异常处理器处理掉异常，那么返回值都会为1。如果都没处理，返回值为0，接下来就要通过结构化异常来处理异常。

为了让系统和应用程序代码都可以简单方便地支持异常处理，Windows系统定义了一套标准的机制来规范异常处理代码的设计（对程序员）和编译（对编译器），这套机制称为结构化异常处理。

从系统（广义）的角度看，SEH是Windows操作系统中的异常分发和处理机制的总称，其实现遍布在Windows系统的很多模块和数据结构中。

从编程（狭义）的角度看，SEH是一套规范，利用这套规范，程序员可以编写处理代码来复用系统的异常处理设施。可以将其理解为是操作系统的异常机制的对外接口，也就是如何在Windows程序中使用Windows系统的异常处理机制。

在用户模式下，fs:[0]寄存器指向的是线程环境块（TEB），TEB的起始处有一个称为线程信息块的结构（TIB）。而在内核模式下，fs:[0]指向的则是KPCR结构的开始处，其第一个成员也是线程信息块结构（TIB）。TIB结构包含了异常，线程栈等信息，该结构定义如下：

TIB起始处保存的是ExceptionList字段，所以fs:[0]的内容就是ExceptionList字段的内容，该字段是_EXCEPTION_REGISTRATION_RECORD结构体，定义如下：

根据定义可以知道，所有异常处理函数通过_EXCEPTION_REGISTRATION_RECORD结构保存在栈中。通过Next字段可以找到其下一个异常处理函数，当Next为0xFFFFFFFF(-1)的时候，代表没有下一个异常处理函数，Handler则指向了异常处理函数，指向的函数原型如下：

可以得出结论，系统可以通过fs:[0]这种便捷方式引用ExceptionList字段，获得一个链表的头指针，这个链表的每个节点是一个_EXCEPTION_REGISTRATION_RECORD结构，描述了一个结构化的异常处理器(handler)，该链表通过成员Next连接起来。当有异常发生时，系统就可以通过Next成员，依次调用这个链表上的处理器来分发异常。

可以把结构化依次处理看作操作系统于用户代码协同处理软硬件依次的一种模型，而fs:[0]链条便是这二者的接口。当有异常需要处理时，操作系统通过fs:[0]链条来寻找异常处理器，给用户代码处理异常清空的机会

由上内容可知道，结构化异常处理器是要保存在栈上的。因此，可以用以下代码来登记一个结构化异常处理器：

其中第一行是将一个具有SEH标准的函数原型的处理函数地址，第二行将fs:[0]，也就是字段ExceptionList的当前值入栈，栈上就建立了一个EXCEPTION_REGISTRATION_RECORD结构，栈顶地址便是这个结构的地址，因此，第3行把esp寄存器的内容赋给fs:[0]，实质上就是把刚刚注册的异常处理器的地址赋给ExceptionList。当CPU继续指向这段代码的下面代码时候，如果有异常发生，那么系统在遍历fs:[0]链条时便会首先找到这个异常处理器，给其处理器机会。因此，以上代码片段一旦插入，那么它之后的代码便进入了它所安装的异常处理器的“保护”范围。

可以使用如下代码来注销前面登记的异常处理器：

此时esp指向的是刚注册的结构化异常处理器的EXCEPTION_REGISTRATION_RECORD结构体的地址，其第一个成员Next指向的是前一个异常登记结构的地址，将其赋给fs:[0]，也就是赋给ExceptionList，这样，fs:[0]的内容就恢复到了安装这个结构化异常处理器前的状态。

对于ntdll.dll中的RtlDispatcherException，如果VEH没有成功处理异常，接着就会通过SEH来处理异常。

通过调用RtlpGetStackLimits来获取栈基址和栈界限

RtlpGetStackLimits函数实现如下（根据Tib结构可以知道，fs:[0x8]为栈边界，fs:[0x4]为栈基址）：

调用RtlpGetRegistrationHead来获取ExceptionList字段

根据其函数实现可以知道，是将ExceptionList赋给eax

判断获取的ExceptionList的Next成员是否为-1

如果为-1，就会退出函数，此时局部变量var_res为0，将其赋给eax，就是指定返回值为0

判断ExceptionList是否在栈空间内以及其最低两位是否为1

如果任何一个条件不满足，接下来就会为ExceptionFlags赋值以后退出函数

如果都满足条件，接下来就会判断异常处理函数地址是否不在栈内，如果在栈内就会跳转到上面的loc_7C94A316退出函数，该机制就是为了支持DEP功能的

如果不在栈中，通过RtlIsValidHandler来判断异常处理函数是否合法，不合法的话依然会跳转到上面的loc_7C94A316退出函数，该机制是为了支持SAFESEH

通过验证以后就会通过RtlpExecuteHandlerForException来处理异常，并将返回值赋给edi

该函数返回值会是一个枚举类型EXCEPTION_DISPOSITION的常量，含义如下：

接下来就是根据返回值进行操作，首先判断是否为0，且ExceptionFlags是否满足条件，如果满足条件就会将局部变量var_res赋值为1，接下来就会继续执行上面的loc_4C994AA21的代码，将var_res的值赋给eax作为局部变量返回，代表处理成功，然后退出函数

如果ExceptionFlags不满足条件，会调用RtlRaiseException分发异常

如果返回值为1，且ExceptionFlags符合条件，就会跳转到上面的loc_7C94AA21处退出函数

否则就取出下一异常处理器，判断Next是否为-1，不为-1就会跳转到loc_7C94A994继续上面操作，为-1则退出函数

如果返回值不为0, 1, 2就会调用RtlRaiseException来分发异常

如果为2，对pNestedRegistration继续判断，如果地址小于pExecptRec，来决定是否要为pExecptRec赋值，随后跳转到上面的loc_7C94A306来取下一个异常处理器后继续执行上述循环过程

下图是对上述过程的展现:

对于异常处理函数RtlpExecuteHanlderForException，首先将函数地址SehHandler赋给edx，随后跳转到ExecuteHandler

而ExecuteHandler则是通过ExecuteHandler2实现的

ExecuteHandler2则是会将SehHandler函数登记到SEH异常链条中，随后在调用传入的函数，此时的edx在前面被赋值为SehHandler函数地址

异常处理的一个特征就是线程相关性。也就是说，异常的分发和处理是在线程范围内进行的，异常处理器的注册也是相对线程而言

从应用范围来：SEH既可以在用户态（应用程序）代码中，也可也在内核态（比如驱动程序）代码中，但VEH只能在用户态代码中。另外，VEH只有在XP或更高版本的Windows系统中才能使用。

从优先级的角度：对于同时注册了VEH和SEH的代码所触发的异常，VEH比SEH先得到处理权

从注册方式角度看：SEH的注册信息是以固定的结构存储在线程栈中，不同层次的各个SEH的注册信息依次被压入栈中，分布栈的不同位置，依靠结构内的指针和联系，因为人们经常将一个函数所对应的区域称为栈帧，所以结构化异常处理器又经常称为基于帧的异常处理器；VEH的注册信息是存储在进程的内存堆中

从作用域看：VEH处理器相对于整个进程都有效，具有全局性；结构化异常处理器是动态建立在所在函数的栈帧上，会随着函数的返回而注销，因此SEH只对当前函数所这个函数所调用的子函数有效

从编译角度看：SEH的注册和销毁都依靠编译器编译时所生成的数据结构与代码的，VEH的注册和销毁都是通过系统的API显示完成的，不需要编译器特殊处理

下篇：Windows内核学习笔记之异常（下）

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)