Getting Started Windows Driver Development Part 2: Understanding Driver Architecture and Handling I/O Requests

Recap from Part 1

In the previous part, we introduced the basics of Windows drivers and walked through the process of setting up a development environment. We also created a simple “Hello World” kernel-mode driver. Now, let’s take a deeper dive into the architecture of a Windows driver and learn how to handle I/O requests, a critical part of driver functionality.

Understanding Windows Driver Architecture

At the core of Windows driver architecture lies the concept of the I/O Request Packet (IRP). When an application interacts with hardware, Windows creates an IRP to pass the request to the driver responsible for that hardware.

Windows drivers are layered, meaning multiple drivers can work together to handle a single I/O request. For instance:

• File System Drivers (FSD) handle file I/O operations.
• Bus Drivers control the hardware bus (like USB, PCI).
• Function Drivers are the primary drivers for devices.

Each driver in the stack can handle specific aspects of the I/O request.

The Driver Object and Dispatch Routines

Every driver has a Driver Object, which Windows uses to keep track of the driver’s various routines and other data. One key feature of the Driver Object is that it contains Dispatch Routines, which handle specific types of I/O operations such as read, write, and device control.

Here’s an illustration of how the Driver Object and Dispatch Routines fit together:

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
    UNREFERENCED_PARAMETER(RegistryPath);        

    // Set up driver’s dispatch routines
    DriverObject->DriverUnload = UnloadDriver;
    DriverObject->MajorFunction[IRP_MJ_CREATE] = HandleCreate;
    DriverObject->MajorFunction[IRP_MJ_CLOSE] = HandleClose;
    DriverObject->MajorFunction[IRP_MJ_READ] = HandleRead;
    DriverObject->MajorFunction[IRP_MJ_WRITE] = HandleWrite;    DbgPrint("Driver loaded successfully\n");    return STATUS_SUCCESS;
}        

Explanation:

• DriverEntry: This is still the entry point of the driver.
• DriverObject->MajorFunction[]: This array holds pointers to the driver’s dispatch routines for different I/O operations.
• IRP_MJ_CREATE handles opening a connection to the device.
• IRP_MJ_CLOSE handles closing the connection.
• IRP_MJ_READ handles read requests.
• IRP_MJ_WRITE handles write requests.
• UnloadDriver: A function that is called when the driver is unloaded from memory.

Now that we have an idea of how to register dispatch routines, let’s explore how to handle a simple I/O request.

Handling I/O Requests

An I/O Request Packet (IRP) is created by the OS whenever an I/O operation is needed. The IRP is passed down to the driver’s dispatch routine, which processes the request and returns the status.

A Basic I/O Request Handling Routine

Here’s an example of how to handle an IRP_MJ_CREATE operation:

NTSTATUS HandleCreate(PDEVICE_OBJECT DeviceObject, PIRP Irp)
{
    UNREFERENCED_PARAMETER(DeviceObject);        

    DbgPrint("Device opened\n");    // Complete the IRP and return status
    Irp->IoStatus.Status = STATUS_SUCCESS;
    Irp->IoStatus.Information = 0;
    IoCompleteRequest(Irp, IO_NO_INCREMENT);    return STATUS_SUCCESS;
}        

Explanation:

• PDEVICE_OBJECT: Represents the device object for the driver.
• PIRP: Represents the IRP structure that holds the request details.
• IoCompleteRequest: Completes the IRP, signaling to the OS that the request is handled.
• STATUS_SUCCESS: Indicates that the operation was successful.

In this example, whenever an application opens a connection to the device, the HandleCreate function logs the message “Device opened” and completes the request.

Handling Read and Write Requests

When a read or write operation is requested, the corresponding dispatch routines (IRP_MJ_READ and IRP_MJ_WRITE) are called. Here’s an example of how to handle a read operation:

NTSTATUS HandleRead(PDEVICE_OBJECT DeviceObject, PIRP Irp)
{
    UNREFERENCED_PARAMETER(DeviceObject);        

    // Assume we are reading a fixed 4-byte message "Data"
    char* buffer = "Data";
    ULONG length = 4;    // Copy data to the user buffer
    Irp->IoStatus.Status = STATUS_SUCCESS;
    Irp->IoStatus.Information = length;    // Get the system buffer from the IRP
    PVOID systemBuffer = Irp->AssociatedIrp.SystemBuffer;
    RtlCopyMemory(systemBuffer, buffer, length);    IoCompleteRequest(Irp, IO_NO_INCREMENT);
    
    DbgPrint("Read request handled\n");    return STATUS_SUCCESS;
}        

Explanation:

• In the case of a read request, the driver prepares the data to be read, copies it to the system buffer, and completes the IRP.
• RtlCopyMemory: This function copies the data from the driver to the buffer provided by the application.
• IoCompleteRequest: Again, this function signals that the request has been processed.

Handling Write Requests

Writing data from the user application to the driver works similarly, except the data is copied from the user buffer into the driver.

NTSTATUS HandleWrite(PDEVICE_OBJECT DeviceObject, PIRP Irp)
{
    UNREFERENCED_PARAMETER(DeviceObject);        

    // Get the user buffer from the IRP
    PVOID systemBuffer = Irp->AssociatedIrp.SystemBuffer;
    ULONG length = Irp->Parameters.Write.Length;    DbgPrint("Write request received, Length: %d\n", length);    // Here you would process the buffer data (e.g., store it, or send it to hardware)
    // For now, just complete the request.    Irp->IoStatus.Status = STATUS_SUCCESS;
    Irp->IoStatus.Information = length;    IoCompleteRequest(Irp, IO_NO_INCREMENT);
    
    return STATUS_SUCCESS;
}        

Explanation:

• For a write request, the driver receives data from the user buffer, processes it, and completes the IRP.
• In this simple example, we just log the length of the write operation and complete the request.

Conclusion

In this second part of our series, we’ve explored the architecture of Windows drivers, focusing on dispatch routines and handling basic I/O requests. You now understand how to register dispatch routines in the DriverEntry function and how to process create, read, and write operations in your driver.

In the third part, we’ll cover more advanced topics, such as hardware communication, device control requests, and using tools like WinDbg to debug your drivers.