Windows 2000 kernel-mode driver design

Source: Journal of Chongqing University of Posts and Telecommunications

A device driver is a software module that deals directly with hardware. In Windows 2000, Microsoft introduced the plug-and-play feature of Windows 9x Based on the driver structure of Windows NT4.0, and introduced a new driver structure (WDM ). WDM simplifies driver development by providing a flexible way, reducing and reducing the number and complexity of necessary drivers based on the implementation of new hardware support. In Windows 2000, drivers can be divided into two categories: User-mode drivers and kernel-mode drivers. User-mode drivers are subsystem-specific and contain Win32 multimedia drivers and Virtual Device Drivers (VDD) that support MS-DOS applications ). There are three basic types of kernel-mode drivers, each of which has a slightly different structure and completely different functions, that is, the highest-level Drivers (such as file system drivers (FSD )), middle-layer drivers (such as virtual disks, images, or peripheral devices specific to the device type), underlying drivers (such as PNP hardware bus drivers ). Driver development in Windows is divided into three main areas: WDM drivers, file system drivers, and Small-port drivers. See figure 1. The Small and Medium port drivers are for display devices, SCSI and network devices, and the file system drivers are for storage devices; WDM drivers are designed for the majority of computer application systems. This article discusses the general design of drivers in the WDM kernel mode. Although development of drivers of other types is different from development of drivers in the WDM kernel mode, however, as long as you master the basis of driver development in the WDM kernel mode and combine the characteristics of the two basic types, you can quickly master the design method.

1Basic Principles of WDM
WDM is a modular, hierarchical micro-driver structure, as shown in Level 2. The left side is a device object stack, and the right side is the layered structure of the driver. In the WDM driver model, each hardware must contain at least two layers: Functional drivers and bus drivers. The bus driver creates the physical device object PDO for each device found on the bus, and each functional device driver creates its own functional device object fdo. In the driver, instead of operating the hardware directly, the corresponding PDO and fdo operations are performed. The I/O Request Packet (IRP) from the user mode API is sent to the upper-layer driver of the device stack, and then the lower-layer driver is gradually filtered out. Each layer of drivers can determine how to handle IRP. Kernel-mode WDM drivers have portability, configurability, Object-based, package-driven, and other common attributes.

The user State Program and the kernel access the device of the device driver through the device object. There are two methods to provide the WDM Driver
Name available for Win32 program. The old method is to create a symbolic link name through iocreate-symboliclink when the driver device is created, the new method is to use a 128-bit guid ). In the driver programming, the guidcan be generated through the guidgen.exe tool in windows.
2Structure and Design of WDM drivers
Different from conventional applications, the kernel-mode driver can regard a complete driver as a container, which contains many routines. When the operating system encounters an IRP, it calls the routines in the container to execute various operations on the IRP. Figure 3 shows this concept. Each WDM driver must have five routines: DriverEntry, adddevice, dispatchpnp, dispatchpower, and dispatchwmi. Other routines are optional. Drivers that need to queue for IRP generally have a startio routine. the driver that executes DMA transmission should have an adaptercontrol routine. For most devices that can generate hardware interruptions, their drivers have an interruption service routine (ISR) and a delay process call (dpcforisr) routine. Drivers generally have several distribution routines that support different types of IRPs. The main task of the WDM driver developer is to select the container shown in 3 and complete the required routine.

When the I/O manager loads the driver, it calls the DriverEntry routine required by each driver to initialize the data structure and resources within the driver range. In general, the DriverEntry routine usually completes the following functions: ① find the hardware to be controlled; ② set the driver's dispatch-, adddevice, startio in the driver object (if any) and un-load (if any) distribution routines program entry point; ③ create all driver objects or other system resources; ④ returned ntstatus indicates whether the driver is successfully loaded, it can also receive and process configurations from the PnP Manager, add (adddevice), and initiate requests from its devices. For function drivers, the basic function of adddevice is to create a device object and connect it to the device stack with the PDO base. The dispatch routine is the main function provided by the device driver. When an I/O operation is executed, Windows 2000 processes requests from user-Mode Applications or from other places in the system by implementing the dispatch routine.
A complete driver must complete the following tasks: initialization, device creation and deletion, application Open and Close handle requests, and application input/output requests; serializing access to devices; accessing hardware; calling other drivers; canceling I/O requests; handling events that can be added to or deleted from hot swapping devices; power management and WMI; process the interrupted devices.
The operating system uses the data structure of the I/O Request Packet (IRP) to communicate with the kernel-mode driver. IRP is a kernel object. It is a pre-defined data structure with a set of I/O manager routines that operate on it. The I/O manager receives an I/O Request and then allocates and initializes an IRP. An IRP has a fixed header and variable target IRP stack unit block. Each stack unit block corresponds to a driver that will process the IRP, therefore, these stack blocks should be at least as many drivers as the driver stack will process this request. Each I/O Request has a main function code (irp_mj_xxx) and may have a function code (irp_mn_xxx ). The Main Function Code determines the driver entry point of the distribution routine called by this I/O Request. The distribution routine receives an I/O Request and then processes it as follows: confirms the validity of the I/O request, and completes the I/O request directly in the distribution routine as much as possible; if the request cannot be processed in the dispatch routine of the driver, the driver queues the request for later processing. The WDM Driver provides two methods for queuing I/O requests: System queuing managed by the I/O manager and driver queuing managed by the driver.
In Windows 2000 and Windows 98, the PnP Manager is able to automatically detect hardware and allocate I/O resources by using bus drivers. In the WDM driver, the PnP Manager uses the main function code to exchange information and requests with the device driver for the I/O Request package of the IRP-MJ-PNP to complete the detection and configuration of the hardware device. The PNP request package provides two features: it instructs the driver when and how to configure and cancel the hardware and the settings of the driver itself; it instructs the driver to complete a series of state transitions. A pnp request can contain more than 20 functional code, some functional code (such as IRP-READ-CONFIG, IRP-MN-QUERY-RE-SOURCE-REQUIREMENTS, etc.) can only be processed by the bus driver, the function driver and filter driver only send the IRP request to the bus driver. For functional drivers and filter drivers, the more important IRP-MN-START-DEVICE is used to notify functional drivers of what I/O resources their hardware has been granted, and instruct the function driver to make any necessary hardware or software settings so that the device can work properly. The IRP-MN-REMOVE-DEVICE tells the feature driver to close the device and release the device object associated with it.
The ISRs and dpcforisr of the driver provide services to the device when the device is interrupted. When a device experiences an interruption, the driver's ISR will be called. ISR collects information about the hardware by asking the device hardware and tries its best to process it. If it is impossible to completely process the interrupt request, the interruption Information is transmitted to DPC-forisr for processing. ISR runs at the dirql interrupt request level. During execution, all devices on the same processor are blocked from sending lower dirql interruptions. Therefore, when writing a driver, ISR should return control as quickly as possible. In addition, ISR can share data and hardware resources with other parts of the driver, so you need to pay attention to the handling of synchronization issues.
3WDM driver development environment and compilation
The driver compiling environment in Windows 2000 is called DDK for Microsoft Windows 2000 or Windows2000 DDK, and DDK is a command line working environment. Install micro-soft VisualC ++ and Win32 SDK (optional) before installing DDK ). Compile the connector is the main tool for constructing the driver. Compile for the actual compilation and connection work.
In addition, the build compilation connector can also check the pseudo commands in the dirs file to determine the list of driver directories to be compiled. The build. Log, build. WRN, and build. Err log files respectively record the command lines, errors, and warnings executed in the compilation link. After compilation, the file suffix is. sys.
The driver debugging is performed at the original code level. You can use the windbg debugging tool provided by Microsoft, but it must be performed on two computers connected by serial ports. Numbench's SoftICE makes it easier to debug the core code on a computer.