When an exception occurs, theCPU finds the exception handler through the IDT table, the KITRAPXX series function in the kernel , and then goes to execute. However, the KITRAPXX function is usually just a simple representation and description of the exception, in order to support debugging and the software's own definition of the exception handler, the system needs to distribute the exception to the debugger or the application's handler function.
To better manage exceptions,Windows Systems define specialized data structure Exception_record to describe exceptions.
typedef struct _exception_record {DWORD ExceptionCode; DWORD ExceptionFlags; struct _exception_record * *pexception_record;
Exceptioncode: The exception code , the four-bit integer.
ExceptionFlags: Used to record exception flags, each of which represents a flag.
ExceptionRecord: Used to point to another exception record related to the exception.
ExceptionAddress; used to record the exception address, the error class exception and the trap class exception will be different.
Numberparameters: The number of additional parameters, that is, the number of valid exceptioninformation arrays.
Registering CPU Exceptions
For CPU exceptions,theKiTrapxx routine will typically call the Commondispatchexception function after completing a special action for this exception, which allocates a exception_ in the stack Record structure, and stores the exception information in the structure. Once the structure is ready, it will call the Kidispatchexcption function in the kernel to distribute the exception.
Login Software Exception
Simple to catch, software exceptions are generated by invoking the kernel service kiraiseexception directly or indirectly. Inside the function, the context text is copied to the kernel stack of the current thread, and then the Kidispatchexcption function is called to distribute.
In summary, the Kidispatchexcption function in the kernel is called for distribution, regardless of the exception, which means Windows manages exceptions in a uniform way.
Voidkidispatchexception (in Pexception_record ExceptionRecord, in Pkexception_frame exceptionframe, in PKTRAP_FR AME Trapframe, in Kprocessor_mode Previousmode, in BOOLEAN firstchance)
ExceptionRecord: Used to describe the exception to be distributed.
Exceptionframe: A pointed ktrap_frame structure that describes the processor state when an exception occurs, including various general-purpose registers, debug registers, segment registers, and so on.
Previousmode: Enumeration that indicates whether the previous state is kernel mode or user mode.
Firstchance: Indicates the first rounds of distribution.
Let's take a look at kidispatchexception distribution.
As we can see, kidispatchexception will call the Kecontextfromkframes function first to produce a context structure based on the ktrap_frame structure that the Trapframe parameter points to. Used when reporting exceptions to the debugger and exception handler functions.
The next distribution is based on whether the pattern is kernel mode or user mode. Specify below.
Distribution process for kernel-state exceptions
For the first round of exception Kidispatchexception will attempt to notify the kernel debugger to handle the exception, if the exception is not handled, then the RtlDispatchexcption is called, attempting to find a structured exception handler that has already been registered ( SEH).
If it is not found, then the kernel debugger will be given the opportunity to process the second time. If you still return flase , you will be called KeBugCheckEx to trigger a blue screen.
Distribution process for user-state exceptions
First, Kidispatchexception will determine whether to send to the kernel debugger, but the kernel debugger usually does not handle the user-state exception, so Kidispatchexception will attempt to send to the user state debugger, method is to call dbgkforwardexception. If unsuccessful, kidispatchexception next action is to try to find the exception handling block to handle the exception because the user exception occurs in the user-state code, and the exception-handling block is also in the user-state code. So we need to go to the user state to execute. (This is the distribution process relative to the kernel state anomaly, the distribution process of the user-state exception is a bit troublesome, the specific way is no longer cumbersome, refer to "Software debugging") if you eventually return FALSE, then the second round will be distributed.
Windows Exception Distribution