Introduction to seh mechanism in Windows

1. Exception category

In general, we divide exceptions into two categories. One is the CPU exception, which we call a CPU exception (or hardware exception ). Another type is software exceptions generated by calling the raiseexception API.

Windows uses the same method (kidispatchexception) to describe and distribute these two types of exceptions. However, it is slightly different when handling exceptions.

 

Generally, the exception handling process can be divided into two stages: Stage 1: exception registration process; Stage 2: exception distribution process. The following is a brief introduction.

 

2. Abnormal Registration

1) CPU exception (hardware exception) Registration:

In Windows kernel, there is an Interrupt Descriptor Table (IDT, interupt Descriptor Table). IDT is a linear table located in the physical memory of the kernel state, with 256 table items. Each table item in IDT is called the gate descriptor ). The basic function of the gate descriptor is to associate the interrupt number corresponding to the CPU exception with the corresponding exception handling function kitrapxx.

For example, the processing routine corresponding to the 0 interrupt (except for the 0 error) is NT! Kitrap00

At the same time, we can use the following debug comnand to list each table item in the IDT table.

Lkd>! IDT-

 

When a CPU exception is found through the interrupt vector, the kitrapxx calls the commdispatchexception function, and obtains the appropriate parameters for initializing the exception_record struct, start to call kidispatchexception for exception distribution.

(Brief Description: interrupt vector> kitrapxx> commondispatchexception> kidispatchexception)

The prediction_record structure is as follows:
0: 000> dt ntdll! _ Prediction_record
+ 0x000 predictioncode: int4b
+ 0x004 exceptionflags: uint4b
+ 0x008 predictionrecord: ptr32 _ prediction_record
+ 0x00c exceptionaddress: ptr32 void
+ 0x010 numberparameters: uint4b
+ 0x014 predictioninformation: [15] uint4b

 

2) software exception Registration

Software exceptions are generated by directly or indirectly calling the kernel service ntraiseexception. In user mode, the kernel service can be called through the raiseexception API or advanced languages such as try-catch. The process of registering software exceptions through raiseexception can be described as follows:

After initializing an exception_record struct, raiseexception starts to call rtlraiseexception in Ntdll. After initializing the context struct, rtlraiseexception starts to call ntraiseexception in the kernel. ntraiseexception then calls another kernel function kiraiseexception. Next, kiraiseexception calls kidispatchexception to start exception distribution.

As follows:

Context is a data structure used to save the user State-core state switching field. It mainly refers to the status of each register during Switching. Its structure is as follows:
Struct _ Context
+ 0x000 contextflags: uint4b
...

...

+ 0x09c EDI: uint4b
+ 0x0a0 ESI: uint4b
+ 0x0a4 EBX: uint4b
+ 0x0a8 edX: uint4b
+ 0x0ac ECx: uint4b
+ 0x0b0 eax: uint4b
+ 0x0b4 EBP: uint4b
+ 0x0b8 EIP: uint4b
+ 0x0c4 ESP: uint4b
...

...

 

3. Dispatch exception)

When a CPU or software exception occurs, the system service kidispatchexception is called to dispatch and process the exception. For CPU and software exceptions, the processing process is slightly different. The following is a brief introduction.

1) CPU exception distribution process:

For the first round of exceptions, the kernel debugger will try to handle the exceptions first (kidebugroutine ). If kidebugroutine returns true, that is, if the kernel debugger processes the exception, the exception distribution will stop. Otherwise, rtldispatchexception (ntoskrnl) in kernel mode will be called to try to find the registered structured exception processor.

 

If no exception processor exists, the system will try to distribute it for the second time. If the current kedebugroutine still returns false, it indicates that this is an unattended exception and calls kebugcheckex to cause a blue screen.

The process is as follows:

2) abnormal software distribution process:

After a software exception is distributed to user-mode, how can this exception be handled? In fact, there is a very important struct in Teb called _ nt_tib. In _ nt_tib, There Is A _ prediction_registration_record type field called predictionlist. Its value is the first address pointing to the abnormal processor (_ exception_handler. Prediction_registration_record is a one-way linked list.

 

So where does the first address value of prediction_registration_record come from? It is stored in the FS: [0] register. In other words, when an exception occurs, obtain the value in FS: [0], that is, the first address of prediction_registration_record. We can obtain the verification from windbg as follows:

 

Code

0 : 000 >   ! Teb
Teb at 7ffdf000
Predictionlist: 0012fd04
Stackbase: 00130000
Stacklimit: 0012e000
Subsystemtib: 00000000
Fiberdata: 00001e00
Arbitraryuserpointer: 00000000
SELF: 7ffdf000
Environmentpointer: 00000000
Clientid: 2017312c. g01a50
Rpchandle: 00000000
TLS storage: 00000000
Peb address: 7ffdb000
Lasterrorvalue: 0
Laststatusvalue: c0000135
Count owned locks: 0
Harderrormode: 0
0 : 000 > R FS
FS = 10000003b
0 : 000 > Dd FS :[ 0 ] L4
003b: 00000000 0012fd04 00130000 0012e000 00000000

 

 

After the exception handling linked list is obtained, the linked list is traversed. In the process of a traversal table, the prediction_hanlder of the current node determines whether the current exception of handle can be handled. If not, a value of the enumeration type _ prediction_disposition (predictioncontinuesearch) is returned so that it can traverse the linked list backward until the prediction_handler is found and the predictioncontinueexecution is returned, in order to stop the downward traversal process. The process is shown in:

 

However, if the exception handler of the current handle exception is not found at the end of the traversal, the unhandled exception will be triggered and NTDLL will be finally called! Rtlunhandledexceptionfilter for desktop applicationsProgramIt will crash. For the server program, for a better user experience, such as the runtime of Asp.net, this exception will be caught, and the client may see the service unavailable, or server errors.

 

Code

_ Teb (thread environment blcok is the thread environment block) is defined as follows:
==================
Typedef struct _ Teb {
+ 0x000 Nttib: _ Nt_tib
+ 0x01c Environmentpointer: ptr32 void
+ 0x020 Clientid: _ client_id
+ 0x028 Activerpchandle: ptr32 void
+ 0x02c Threadlocalstoragepointer: ptr32 void
+ 0x030 Processenvironmentblock: ptr32 _ peb
+ 0x034 Lasterrorvalue: uint4b
... ... } Teb
The structure of _ nt_tib is defined as follows:
==============
Typedef struct _ Nt_tib {
+ 0x000   Predictionlist : Ptr32 _ Prediction_registration_record
+ 0x004 Stackbase: ptr32 void
+ 0x008 Stacklimit: ptr32 void
... ... + 0x018 SELF: ptr32 _ nt_tib
} Nt_tib
Ntdll ! _ Prediction_registration_record is defined as follows:
============== Typedef struct _ exception_registration_record {
+ 0x000 Next: ptr32 _ prediction_registration_record
+ 0x004 Handler: ptr32 _ exception_disposition
} Prediction_registration_record Ntdll! _ Prediction_disposition is defined as follows: ================
Typedef Enum _ exception_disposition { Predictioncontinueexecution = 0
Predictioncontinuesearch = 1
Predictionnestedexception = 2
Predictioncollidedunwind = 3
} Prediction_disposition

 

Appendix 1:
Several common system services and related functions related to exception handling in the NTDLL Module

 

Code

Ntdll ! Rtlpunhandledexceptionfilter
Ntdll ! Rtlpdphraiseexception
Ntdll ! Rtlpheapexceptionfilter
Ntdll ! Rtlpdphunexpectedexceptionfilter
Ntdll ! Rtlunhandledexceptionfilter2
Ntdll ! Rtlsetunhandledexceptionfilter
Ntdll ! Rtldispatchexception
Ntdll ! Rtlraiseexception
Ntdll ! rtlpexecutehandlerforexception

NTDLL ! kiraiseuserexceptiondispatcher
NTDLL ! kiusercallbackexceptionhandler
NTDLL ! kiuserexceptiondispatcher
NTDLL ! kiuserapcexceptionhandler

reference:

=======

a crash course on the depths of Win32 structured exception handling

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