Reading Notes _ Windows kernel debugging _ Part 2 _ kernel conversation process

 

Kernel Dialog

After Windows starts kernel debugging, it mainly does the following work:

1. Establish a connection

2. the debugger reads the target system information and initializes the debugging engine (target machine ).

3. the kernel debugging engine notifies the debugger to load the debugging symbol (target machine) of the initial module through the status change information package ).

4. the debugger sends an interrupt package, interrupts the target system to the debugger, and resumes execution after interactive debugging.

5. The target system is interrupted to the debugger due to a breakpoint hit.

6. The module in the kernel outputs the debugging string (dbuplint) to the debugger.

The summary of software debugging (490-491) is as follows:

 

Kernel debugging Engine

The kernel debugging engine is equivalent to a proxy for debugging in the target system. The debugging engine represents a debugger to access and control the target system.

Key functions for kernel debugging:

Kdenterdbugger

It is used to freeze the kernel. After the call, interruption is first prohibited. For multi-processor systems, it will raise the IRQL of the current CPU to high_level and freeze all other CPUs. Lock the debug communication port, call kdsave to save the communication status of the communication extension module, and set the global variable kdentereddebugger to true. After the kdenterdebugger is executed, the entire system enters a simple single task state. The current CPU only executes the current thread, and other CPUs are frozen.

Kdexitdebugger resumes kernel operation. The main task is to call kdrestore to restore the communication status of the communication extension module and unlock the locked communication port. Kethawexecution is called to restore the normal running status of the system, including restoring the interruption, reducing the IRQL of the current CPU, restoring multiple CPU Systems and other CPUs.

KdpReportExceptionStateChange CPU reports abnormal class status changes

KdpReportLoadSymbolsStateChange CPU reporting symbol loading class exception

The KdpSendWaitContinue function is used to send information packets and talk to the debugger.

The KeUpdateSystemTime function checks the global variable KdDebuggerEnable each time it updates the system time to determine whether the kernel debugging engine is started. If it is true, call the KdPollBreakIn function to check whether the debugger has sent terminal commands, call DbgBreakPointWithStatus to trigger a breakpoint exception and interrupt it to the debugger.

KdpTrap to handle kernel state exceptions. When an exception occurs in the kernel state, the KiDispatchException function calls the function pointed to by the global variable KiDebugRoutine. When the debugging engine is enabled, the value of this variable is the address of the function KdpTrap. Therefore, once an exception occurs, the system will call KdpTrap. KdpTrap calls KdpReport to report an exception to the debugger.

KiSaveProcessorControlState: saves the CPU control status

KiRestoreProcessorControlState restores the CPU status

Print debugging information for dbuplint, dbuplintex, and vDbbgPirntEx

 

The following is a brief introduction to local kernel debugging:

In addition to kernel debugging between two systems (including virtual machines), you can also perform kernel debugging locally, however, we recommend that you perform simple tasks such as observing variables or checking symbols during local kernel debugging.

In addition to windbg, there is also a small software LiveKD that can be used for local kernel debugging. It can generate a dump file while keeping the system working, and then use Windbg for analysis.

Local kernel debugging of WinDbg is mainly provided through the undisclosed kernel service zwSystemDebugControl. zwSystemDebugControl provides WinDBG with a function to locally access the kernel debugging API.