Windows debugging 3

Overview of all components

Picture from Windows internal

Above the horizontal line is a user-state process, and the following components are kernel-State services.

User-mode threads run in a protected process space, although they still have the right to access system space in kernel execution mode. Therefore, the processes, service processes, user applications, and environment subsystems supported by the system use their own private process address space.

 

Note the subsystem DLL section in the figure. In Windows 2000, user applications do not directly call the system native service, and they call the service through the dynamic link library of the Environment Subsystem. The role played by subsystem DLL is to convert a Windows public function call to an appropriate internal (non-public) operating system service call.

 

User processes include the following:.

* Processes supported by the system, such as login processes or session managers, are not started by Service Control Manager.

* Service process-the host of the Win32 service, such as the scheduled task and background print program. Many server applications have components that run like services. For example, Timer service and search service of SharePoint.

* User applications, such as Win32 and MS-DoS

* Environment Subsystem-exposes components of the operating system native service to the user application through a series of callable functions. Win32 is an environment subsystem.

The kernel-mode components include the following:.

* Executable components-including some basic operating system services, such as memory management, process thread management, security, Io, and inter-process communication.

* The kernel is composed of underlying operating system functions, such as thread planning, interrupt and exception allocation, and multi-processor synchronization. A series of common objects and basic objects are also provided. Other executable components use these objects to implement other advanced architectures.

* Device Drivers-including hardware drivers, for example, converting users' I/O function calls to an I/O request of a hardware device, which is the same as the file system and network system.

* Hardware Abstraction Layer (HAL) is equivalent to a layer of isolation layer established for the kernel, device drivers, and other executable parts, shielding them from the differences between real hardware. That is to say, what the kernel and device drivers see is not hardware, but hardware abstraction. Hal deals with real hardware.

* Window System and Graphic System-implement GUI functions, that is, Win32 user functions and GDI functions. Processing window, user interface controls and plotting.

This table lists some important components of the Windows operating system.

Filename	Components
Ntoskrnl.exe	Executive and Kernel	Kernel and performer
Ntkrnlpa.exe	Executive and kernel with support for physical address extension (PAE), which allows addressing of up to 64 GB of physical memory	Supports the kernel and executor for physical address expansion, and supports 64 GB physical memory addressing.
Hal. dll	Hardware hardware action Layer	Hardware Abstraction Layer
Win32k. sys	Kernel-mode part of the Win32 subsystem	Kernel Status of Win32 subsystem
Ntdll. dll	Internal support functions and System Service dispatch stubs to executive functions	Internal Support for functions and system services
Kernel32.dll, Advapi32.dll, User32.dll, Gdi32.dll	Core Win32 subsystem DLLs	Core Win32 subsystem DLL

 

Interruptions and exceptions

Picture from Windows internal

Both the interrupt and exception are functions that the operating system uses to transfer the processor from the normal control flow. The term "trap" refers to a mechanism of the processor, which can capture the threads being executed when exceptions or interruptions occur, and converts the control flow to a place specified by the operating system. This is the trap handler, which is used to handle interruptions and exceptions.

What is the difference between interruptions and exceptions? Interruption is an asynchronous event, and it has nothing to do with the current processor being executed. Interruptions are mainly caused by Io devices and processor clock. They can be blocked and enabled. In contrast, an exception is a synchronization event caused by a specific command. For example, if you execute the same code twice with the same data under the same conditions, an exception is thrown. For example, exceptions include illegal access to memory, specific debugger commands, and division by zero.

Note that the kernel treats system service calling as an exception.

Both hardware and software can cause exceptions and interruptions. For example, the exception caused by a bus error is caused by hardware, while the exception of 0 is a software bug. Likewise, Io devices can interrupt, and the kernel itself can generate a software interrupt (APC, DPC ).

When a hardware exception or interruption occurs, the processor records enough machine States so that it can return to the control flow point, as if nothing has happened before. To achieve this, the processor establishes a trap frame in the kernel stack of the interrupted thread to store the running status of the thread. This trap framework is usually part of the complete Context of a thread. There are two ways to interrupt the kernel processing software, either like some hardware interruptions, or synchronous processing when the thread initiates a kernel function call related to the software interruption.

 

Interrupt handling

Hardware interruptions are typically generated by Io devices that must notify the processor when they need services. The interrupt driver allows the operating system to maximize io-related operations and overlap the main operations. That is to say, to start a thread and complete the device-related Io conversion tasks in the thread, the main operation is still running in parallel in another thread. After the device is complete, the device interrupts the processor and requests the service. Fixed-Point devices, printers, keyboards, disk drivers, and NICs are basically interrupted drivers.

Software can also be interrupted. For example, the kernel starts a software interrupt to initialize thread allocation and asynchronously enters the execution of a thread. The kernel can also disable the interrupt so that the processor can execute without being affected. This approach is not common and is generally used at critical moments, such as when an interrupt is being processed or an exception is being processed.

The kernel installs the interrupt trap processor to respond to device interruption requests. The interrupt trap processor will control, or transfer it to the routine ISR, or to the internal kernel to respond to the interrupted function. The Device Driver provides the device interrupt service for ISR, and the kernel provides the Interrupt Processing for other types of interrupts.

In the following section, you will find out how the hardware notifies the processor of device interruptions, the types of interruptions supported by the kernel, and the interaction between the device driver and the kernel, there are also software interruptions identified by the kernel (some kernel objects will be introduced for implementation ).

 

Exception Handling

 

Compared with interruptions that can occur at any time, exceptions are directly caused by running programs. Win32 introduced a facility named structured exception handling that allows applications to gain control when exceptions occur. The application can fix the error status and then go back to continue the execution. Expand the stack (unwind stack) to terminate the subprogram that reports the error, or declare that the exception is not recognized by the system, please continue to find the appropriate Exception Handling Section.

On x86, all exceptions have predefined interrupt numbers, which are directly related to the entry to the trap processor used in IDT to handle exceptions.

Except for exceptions that are simple enough that trap handler can solve, all exceptions are handled by services from a system module called exception dispatcher. The task of exception dispatcher is to find an exception handler that can solve the exception (dispose ). The architecture independent exceptions defined by the system include illegal memory access, integer division by zero, integer overflow, floating point exceptions, and debugger breakpoints. The complete list of such exceptions can be found in the Win32 API manual.

The kernel captures these exceptions, which is transparent to user programs. For example, a breakpoint is encountered in the debug program. At this time, the kernel will generate an exception. You can call the debugger to handle this exception, so that the program is paused at the place where we specify the breakpoint, And the debugger such as vs2005 is in the active state. When the kernel processes some other exceptions, it only returns an unsuccessful status code to the caller.

Whether it is an explicit software exception or an implicit hardware exception, when it occurs, there will be a series of events in the kernel.

1. The CPU Hardware transfer control flows to the trap handler, And the trap handler creates the trap frame (as in the case of an interruption ). Trap frame enables the system to successfully resume execution after the Exception Processing is completed.

2. Trap handler also creates an exception record, including the cause of the exception and related information.

The breakpoint of a debugger is a very common exception source. Therefore, the first action of the exception dispatcher is to check whether a debugger process is associated with the abnormal process. If yes, it will pass the first-hand debug information of the abnormal process (through the LPC Port) to the debugger port. (Information is sent to the Session Manager Process to assign a suitable debugger process ).

If no debugger is associated, or the debugger does not handle this exception, the exception processor switches to the user mode and calls a routine to find a frame-based) exception processor. If no exception is found, or no part can handle the exception, the exception distributor switches back to the kernel state, and then calls debugger again to allow the user to perform further debugging. (This is called second-chance notification ).

All Win32 threads are declared as an exception handler at the top of the stack for which exceptions are not processed ). This exception processor is declared in the Win32 internal function start-of-process or start-of-thread. The start-of-process function starts to run when the first thread in the process is running. It calls the main entry. The start-of-thread function is called when the user creates another additional thread. It calls the specified thread in the creadthread and enables the routine (thread start routine) provided by the user ).

The general code of these internal start functions is shown as follows:

void Win32StartOfProcess(LPTHREAD_START_ROUTINE lpStartAddr,    LPVOID lpvThreadParm){    __try     {        DWORD dwThreadExitCode = lpStartAddr(lpvThreadParm);        ExitThread(dwThreadExitCode);    }    __except(UnhandledExceptionFilter(GetExceptionInformation()))     {        ExitProcess(GetExceptionCode());    }}

 

Note: When exceptions occur in the thread, Win32 unhandled exception filter is called. It searches for the key value HKLM \ Software \ Microsoft \ Windows NT \ CurrentVersion \ AeDebug in the registry to determine whether to directly run debugger or ask the user first.

The default debugger on Windows2000 is dr. watson. it is not a real debugger, but is more like an autopsy tool that collects various states of an application crash and records them into a log file (drwtsn32.log ), and generate a dump file (user. DMP). By default, both of them can be found in the \ Documents ents and Settings \ All Users \ Documents ents \ drwatson directory.

The log file contains basic information, such as Exception Code, name of the image that failed, the list of loaded DLL, call stack, and command information that causes exceptions.

The crash dump file contains the private page of the process when an exception occurs ). The dump file does not contain EXE and DLL files in code pages. This file can be opened by windbg. Because user. the DMP file can be overwritten when any process crashes. You can only have the dump file of the system's last crash, unless you rename the file or copy it after every crash.

If the debugger is not running and no frame-based handler is found, the kernel sends information to the abnormal port associated with the thread process. If this exception port exists, it is registered by the Environment Subsystem that controls this thread. This abnormal port gives the Environment Subsystem a chance to convert this exception into a signal or exception in a specific environment. Finally, if the kernel has reached this step and the subsystem has not handled the exception, the kernel will execute a default exception handler, which simply terminates the thread that causes the exception.

 

System Service Dispatching)

The kernel's trap handler allocates interruptions, exceptions, and system service calls. We have seen the handling of interruptions and exceptions. Let's take a look at the system service.

System Service allocation is triggered when an int 0x2e command is executed on an x86 processor. The result of executing the int command is to trigger the trap. In Windows, enter information in the 46entry of IDT to point to the system service dispatcher ). the execution thread caused by trap is transferred to kernel mode and then enters the service dispatcher system. Some parameters are passed into the eax register to indicate how many system services are requested. The address of the parameter list passed to the System Service is also indicated in the EBX register.

The following code shows the system service call code.

Ntwritefile:

MoV eax, 0x0e; System Service number for ntwritefile

MoV EBX, esp; point to parameters

Int 0x2e; Execute system service trap

RET 0x2c; pop parameters off Stack and return to caller

System Service distributor-kisystemservice, confirm the correct minimum number of parameters, copy caller parameters from the user State stack to the kernel state stack (so that users cannot modify these parameters when they access the kernel state ). Then run the system service.

 

Soft terminal request levelSoftware interrupt request levels (irqls)

Although the interrupt controller sorts the interrupt priority to some extent, windows still gets its own interrupt priority table, that is, interrupt request levels (IRQL ). the kernel internally uses numbers 0 to 31 to internally represent irqls. A larger number indicates a higher priority. Compared to the standard set of irqls defined by the kernel, Hal maps hardware interruptions to IRQL.

Interruptions are responded in order of priority, and high-priority interruptions give priority to services. When a high-level interrupt occurs, the processor stores the state of the interrupt thread and activates the related trap dispatchers. Trap dispatcher loads IRQL and then calls the terminal service routine. After the service routine is executed, interrupt dispatcher degrades the IRQL of the processor to the state when it has not been interrupted, and then loads the state of the saved machine. The interrupted thread returns to the original place to continue execution. When the kernel reduces IRQL, low-level interruptions are implemented. If this happens, the kernel repeat the previous process to handle new interruptions.

 

IRQL priority vs thread-scheduling priority

The thread-scheduling priority is an attribute of the thread, while IRQL is an attribute of the interrupt source (mouse, keyboard. In addition, any processor has an option that can modify the operating system code execution function.

The IRQL option of any processor can determine which interrupts the processor can accept. IRQL can also be used to synchronize data structures that access the kernel state. When a kernel-state thread runs, it directly or callsKeraiseirqlAndKelowerirql,Or, more commonly, it indirectly improves or reduces the IRQL of the processor through function calls that require kernel synchronization objects.

The kernel-state thread depends on what it wants to do to improve or reduce the IRQL of the processor. For example, when an interrupt occurs, trap handler (or processor) increases the IRQL of the processor to the same IRQL as the interrupt source. This will block all interruptions lower than that IRQL (for that processor only) and ensure that the processor with service interruptions will not be snatched from interruptions of the same or lower level. The blocked interrupt is not processed by another processor, or is suspended for IRQL downgrading. Therefore, all components in the system, including kernel and device drivers, should maintain a relatively low level of IRQL as much as possible. They do this because when IRQL is not kept at an unnecessary high level for a long time, the driver can respond to hardware interruptions in a timely manner.

Because modifying the IRQL of the processor has such a significant impact on system operations, such modifications can only be completed in the kernel state. The thread in user mode cannot modify the IRQL of the processor. This means that the IRQL of the processor is always kept at a low level when the user State program is executed. IRQL may be higher only when the processor executes the kernel-state code.

Each interruption level has its own purpose. For exampleInter-processor interrupt(IPI) to request another processor to do something (for example, allocate a thread to execute or update its side-by-side mode buffer zone ). The system clock generates a terminal after a certain interval. The Kernel updates the clock to measure the thread execution time to respond to the interruption. If the hardware platform supports dual-clock, the kernel will add another clock interruption level to measure performance. Hal provides several columns of Interrupt levels for devices driven by the interrupt mode. Accurate IRQL values vary with the processor and system settings. The kernel uses software interrupt to initialize Thread Scheduling and asynchronously interrupt thread execution.

 

Predefined irqls

Let's see from high to low.

• High level --- onlyKebugcheckexWhen the system is occupied, the kernel uses high level to block all interruptions.
• Power fail --- indicates the code when the system Power crashes, but this IRQL has never been used.
• Inter-processor interrupt ---It is used only when another processor is requested to perform any action.
• Clock-this level is used by the system clock. The system uses it to track the time of a day, as well as to measure the CPU and thread time.
• PRofile--- This level is used by the System Real-time clock when the kernel collects data (profiling) or when the performance measurement mechanism is enabled. During kernel profiling, the kernel's profiling trap handler records the interrupted Code address. As time passes, an address table is created and can be analyzed by tools. Win2k resources kitpackage contains a tool called kernelprofiler(kernprof.exe), which you can use to view profiling-generated data.
• Device --- the level is used by devices to differentiate their priorities
• DPC/dispatchAndAPC ----Software is interrupted by the kernel and device drivers.
• Passive --- is the lowest level. It is not an interruption level at all. It is a configuration when smooth thread Execution occurs and can be generated by any terminal.

There is an important limitation. When DPC/dispatch-level or higher-level code is running, it cannot wait for an object. If it waits, it will force scheduler to select another thread for running.

Another restriction is that irql dpc/dispatch or higher-level code can only accessNon-Paging memory. This restriction is actually a side effect of the previous restriction. When a paging error occurs, the memory manager initializes disk Io and waits for the file system driver to read the memory paging from the disk. Such a wait will take turns to take a group of balls sched to switch the context of the perform (it may switch to the idle process if no user thread is waiting to run ). Therefore, schedpatch will not be activated because IRQL is still at the DPC/dispatch level or higher level during disk reading ). If any rule is violated, the system will crash and generate an irql_not_less_or_equal crash code. Violation of these rules is a common bug in device drivers.