初探windows异常处理

windows系统里，为了保证系统内核的强壮和稳定，为了保证用户程序的强壮和稳定，提供了异常处理机制，来帮助程序员和系统使用人员处理异常。如果想要更加深入的掌握操作系统，异常处理的知识是必不可少的，不仅如此，软件调试也与异常处理息息相关。

异常执行流程

CPU检测到异常 -> 查中断表执行处理函数 -> CommonDispatchException -> KiDispatchException -> KiUserExceptionDispatcher -> RtlDispatchException ->VEH -> SEH

异常产生后，首先是要记录异常信息(异常的类型、异常发生的位置等)，然后要寻找异常的处理函数，我们称为异常的分发,最后找到异常处理函数并调用，我们称为异常处理。

异常的分类

• CPU产生的异常

• 软件模拟产生的异常

CPU异常

CPU指令检测到异常(例：除0)

查IDT表，执行中断处理函数

CommonDispatchException

KiDispatchException

找到IDT表的0号中断

首先保存现场

然后向下走，但是并没有直接异常处理的代码，这里有一个跳转跟进去。为什么操作系统没有直接将异常处理写进去，这是因为操作系统希望我们自己首先能够将异常给处理掉

跟进去后发现调用了CommonDispatchException函数

CommonDispatchException主要是把一些异常的信息存储到了自己的结构体_EXCEPTION_RECORD里面，结构如下

type struct _EXCEPTION_RECORD		
{								
	DWORD ExceptionCode;				//异常代码
	DWORD ExceptionFlags;				//异常状态
	struct _EXCEPTION_RECORD* ExceptionRecord;	//下一个异常
	PVOID ExceptionAddress;				//异常发生地址
	DWORD NumberParameters;			//附加参数个数
	ULONG_PTR ExceptionInformation 
	[EXCEPTION_MAXIMUM_PARAMETERS];		//附加参数指针	
}  

然后通过KiDispatchException去找到异常处理函数

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dKXCM7f4-1652031739279)(/images/异常处理/image-20220327154532542.png)]

在前面的跳转中，带过去了两个寄存器eax、ebx，eax我们可以发现它的值为0c000094，这个值是操作系统定义的

然后再是ebx，ebp指向的是_Trap_Frame结构体的栈顶，+68指向的就是eip

这两个值就对应了结构里面的ExceptionCode和ExceptionAddress

再看ExceptionFlags，CPU导致的异常这个值为0，软件调试导致的异常这个值为1

CPU异常执行的流程：

1、CPU指令检测到异常

2、查IDT表，执行中断处理函数

3、调用CommonDispatchException(构建EXCEPTION_RECORD)

4、KiDispatchException(分发异常：目的是找到异常的处理函数)

模拟异常记录

调用过程

CxxThrowException

(KERNEL32.DLL)RaiseException(DWORD dwExceptionCode, DWORD dwExceptionFlags, DWORD nNumberOfArguments, const ULONG_PTR *lpArguments)

NTDLL.DLL!RtlRaiseException()

NT!NtRaiseException

NT!KiRaiseException

首先手动抛出异常

然后去到返回表发现调用了CxxThrowException

CxxThrowException

__CxxThrowException@8:
00401290   push        ebp
00401291   mov         ebp,esp
00401293   sub         esp,20h
00401296   push        esi
00401297   push        edi
00401298   mov         ecx,8
0040129D   mov         esi,offset string "The value of ESP was not properl"...+0E0h (00423118)
004012A2   lea         edi,[ebp-20h]
004012A5   rep movs    dword ptr [edi],dword ptr [esi]
004012A7   mov         eax,dword ptr [ebp+8]
004012AA   mov         dword ptr [ebp-8],eax
004012AD   mov         ecx,dword ptr [ebp+0Ch]
004012B0   mov         dword ptr [ebp-4],ecx
004012B3   lea         edx,[ebp-0Ch]
004012B6   push        edx
004012B7   mov         eax,dword ptr [ebp-10h]
004012BA   push        eax
004012BB   mov         ecx,dword ptr [ebp-1Ch]
004012BE   push        ecx
004012BF   mov         edx,dword ptr [ebp-20h]
004012C2   push        edx
004012C3   call        dword ptr [__imp__RaiseException@16 (0042b15c)]

该代码所做的事情如下：

① 先从内存中拷贝一段0x20字节的固定结构体到堆栈中;

② 将ExceptionList也拷贝到堆栈中（该结构体内部）

③ 传入有关参数调用RaiseException函数。

注意，ThrowCode虽然从用户代码传入进来，但分析其函数并没有用到，而是直接调用一段固定的异常码。而&ThrowCode以及异常链被作为其参数存储，这样通过分析就可以轻易找到其ThrowCode值，其作为参考之后来处理SEH。

RaiseException

跟进去调用了Kernel32.dll的RaiseException

这里跟CPU异常不同的是，CPU异常会将错误代码跟着寄存器一起传入，但是软件异常并没有，这里看一下

这里的edx为E06D7363就是软件调试的错误代码，这里注意，随着语言和版本的不同，这里的EDX即错误代码并不固定，取决于编译环境

第二个差异就是CPU异常存储的是发生异常的地址，软件异常则是存储RaiseException函数的地址

内核层异常处理流程

前面我们分析过，存在两种异常，CPU异常与用户模拟异常，其异常触发时收集的线路是不同的，但是其最终走经过KiDispatchException函数。

当走到KiDispatchException，CPU异常与用户模拟异常唯一的区别是CPU异常最高位置1（nt!KiRaiseException异常派发时的上一行代码），其余记录的都是一样的。

而KiDispatchException的处理是按照其先前模式来处理的，也就是内核异常与用户异常两种，而不是按照CPU异常与用户模拟异常来进行处理。

1) _KeContextFromKframes  将Trap_frame备份到context 为返回3环做准备

2) 判断先前模式  0是内核调用  1是用户层调用

3) 是否是第一次机会

4) 是否有内核调试器

5) 如果没有或者内核调试器不处理

6) 调用RtlDispatchException

7) 如果返回FALSE 也就是0  

8) 再次判断是否有内核调试器 有就调用 没有直接蓝屏

KiDispatchException

首先定位到KiDispatchException函数

首先备份Trap_Frame结构，如果是用户层的异常则需要返回3环堆栈

首先通过判断先前模式的值来识别是内核异常还是用户层异常，这里有一个是否第一次调用该函数的判断，这是因为这个函数会被调用很多次，如果不是第一次调用则直接跳转

这个函数的最后一个参数就是表示这个函数是第几次被调用

然后继续判断有没有内核调试器的存在(如windbg)

如果有内核调试器的存在就走下面的KiDebugRoutine函数

如果内核调试器没有处理返回失败的话就跳转

RtlDispatchException调用异常处理函数

跟进到RtlDispatchException

又调用了RtlGetRegistrationHead

跟进去发现取的是fs:[0]

_EXCEPTION_REGISTRATION_RECORD

我们知道0环的fs:[0]指向KPCR，KPCR的第一个结构是_NT_TIB，_NT_TIB的第一个成员是ExceptionList，是一个_EXCEPTION_REGISTRATION_RECORD类型的结构体

_EXCEPTION_REGISTRATION_RECORD结构如下

typedef struct _EXCEPTION_REGISTRATION_RECORD {
        struct _EXCEPTION_REGISTRATION_RECORD *Next;
        PEXCEPTION_ROUTINE Handler;
    } EXCEPTION_REGISTRATION_RECORD;

_EXCEPTION_REGISTRATION_RECORD里面有两个成员，*Next是一个指针指向下一个_EXCEPTION_REGISTRATION_RECORD结构，而第二个成员Handler指向的就是一个异常处理函数

RtlDispatchException的作用如下：

遍历异常链表，调用异常处理函数，如果异常被正确处理了，该函数返回1

如果当前异常处理函数不能处理该异常，那么调用下一个，以此类推。

如果到最后也没有处理这个异常，返回0。

调用异常处理函数得到返回值后跳转到地址

然后判断返回值是否为1，1的话就是处理成功，跳转

异常被处理成功则把Context结构放回Trap_Frame里面

如果没有被处理成功则继续往下走进行有无内核调试器的判断，如果有内核调试器则调用KiDebugRoutine

如果没有内核调试器或者有内核调试器但是没有处理异常，则跳转到下面的地方

操作系统蓝屏

用户层异常处理流程

定位到KiDispatchException，进入用户异常的函数

进入函数首先判断是不是第一次调用，然后继续往下走，如果有内核调试器则直接跳转，没有的话继续往下走

然后进行异常的处理，调用DbgkForwardException，这个函数的作用是调用3环的调试器 ，再进行判断有无3环的调试器接收异常，如果没有则返回3环处理

然后进行结构体的修改，这里同用户APC执行的修改过程

然后修改EIP的值为KeUserExceptionDispatcher函数的地址，这时候EIP的值已经是函数地址，这时候再回到原函数

注意这里并没有直接进行返回3环的操作，而是KiDispatchException这个函数执行结束过后回到原函数，用不同的方法回到3环

    CPU异常：CPU检测到异常  ->  查IDT执行处理函数  ->  CommonDispatchException  <->  KiDispatchException   
        通过IRETD返回3环

    模拟异常：CxxThrowException  ->  RaiseException  ->  RtlRaiseException  ->  NT!NtRaiseException  -> NT!KiRaiseException  <->  KiDispatchException   
        通过系统调用返回3环 

无论通过哪种方式，但线程再次回到3环时，将执行KiUserExceptionDispatcher 函数

KiUserExceptionDispatcher

返回三环后，可以看到其调用一个RtlDispatchException。注意，在处理内核异常时，也有一个同名的RtlDispatchException，那是内核模块，这是三环模块。

RtlDispatchException可以认为是异常的核心，区别是如果在内核模块，则处理零环，如果在ntdll模块，则处理三环。