Windows Driver Architecture

"Just start it already..!!". Yes, just can't wait to get started with the nitty-gritty of Windows Driver and get some hand dirty.

But before diving into the core driver programming part, it's helpful to get familiarize with basic concept and terms that are used extensively when working with Windows Drivers.

Of course the details of the same can be found in the sources I have mentioned below. I will try to keep it as brief as possible to help us speed up on things.

Let's start with defining drivers.

From the MSDN, "In the most fundamental sense, a driver is a software component that lets the operating system and a device communicate with each other."

This statements itself helps us deduce a lot about drivers:

It’s a software.
Sits between Operating System and device.
Communicates between OS and device.

So, Windows kernel is not actually interacting with the device. It depends on drivers to do all the stuffs like detecting the attached devices, mediating communication with the them and exposing these devices to application by providing an interface.

Basically in bigger sense of things, the driver has two interfaces, one which communicates with the OS and the other that knows how to communicate with the device hardware.

Think of it as follows:

Now, to think of it, that make drivers pretty complex and cumbersome to implement. Is this same driver going to do all the business of detecting the device attached to it, handle all its main functions, even auxiliary function like let's say encrypting and decrypting the flow of data to and from the device.
So, what does a smart person do ?? Divide the work between several drivers and implement them as stack.

Here you go.

Thus, not all the drivers communicate directly with device. For a given I/O request, there are several drivers, layered as stack, that participate in the request. Keep this figure in mind, we will discuss and look into it more in our section "Device Objects and the Device Stack".

For now, to better understand how the driver work, first let's try to understand, how drivers fit in the system

Core Windows Architecture

This section follows closely with the section given in the book "Developing drivers with theMicrosoft Windows Driver Foundation by Penny Orwick."

Windows system architecture is a layered architecture with applications at top and hardware at the bottom.

It consists of two main components: User Mode and Kernel Mode. All Input/output (I/O) requests are packet driven I/O which utilizes I/O request packets (IRPs) and asynchronous I/O. These are passed between system and the driver, and from one driver to another in stack.

Following figure is an oversimplified architectural diagram of Windows, showing how drivers integrate into the overall architecture.

Let's look into some key components given in the diagram. They are so important that as we keep progressing through our understanding of the drivers, these components will form part of our almost every dealing with them.

Applications and Windows API

Before I write anything, do consider getting a copy of "Windows via C/C++by Jeffrey Richter, Christophe Nasarre". It’s a great book and available with Kindle version as well. This book helped me a lot in my understanding (how much ever skim that still is) of how Windows driver works; especially how applications and drivers interact with each other.

Applications run in the user mode and cannot directly call the services of Windows drivers which run in kernel mode (though a bit of generalization as of now, since UMDF drivers run in User mode).

Windows provides a documented interface to the application called Windows API or simply WinAPI. These APIs provides the interaction between the operating system and an application. The application uses these APIs to issue I/O requests which in turn uses appropriate Windows components to pass the request to the appropriate kernel-mode component.

User Mode and Kernel Mode.

Windows is divided into two main operating modes: User mode and Kernel Mode.

User Mode	Kernel Mode
Applications, System defined processes and DLLs.	Core Operating system components: Executive services, Kernel Driver, Kernel and Hardware Abstraction Layer.
Runs in restricted environment and cannot directly access hardware or reference memory.	Full and unrestricted access to underlying hardware. Can execute any CPU instruction and reference any memory address.
Application has a private virtual address space and a private handle table. Because an application's virtual address space is private, one application cannot alter data that belongs to another application.	All code that runs in kernel mode shares a single virtual address space. This means that a kernel-mode driver is not isolated from other drivers and the operating system itself.
Crash is limited to application.	Crash can cause system fault or BSOD.

Kernel Subsystem

Kernel subsystem make up the low-level kernel mode portion and are contained in the file NTOSKRNL.EXE. These subsystems handle much of the core Windows functionality like I/O, object management, power management, security and process management. There are several kernel subsystems in Windows operating system like:

Cache Manager, Configuration Manager, I/O Manager, Local Procedure Call (LPC), Memory Manager, Object Manager, Process Structure, PnP Manager, Power Manager, GDI and Security ReferenceMonitor (SRM).

Let's look into some subsystems which drivers most frequently interact:

I/O Manager
Facilitates communication between application and devices. The I/O manager receives I/O request from user mode, translates them into IRPs and passes them to the appropriate driver. It also receives completes IRP from the driver and passes and data back to user mode and to the application that issued the request.

PnP Manager
Handles Plug and Play tasks such as enumerating the devices attached to the bus, constructing devices stack for the device, and handling the process of adding or removing the devices while the system is running.

Its bulk is actually implemented in user mode, in the Plug and Play service, which handles the often complex tasks of installing the appropriate drivers, notifying services and applications of the arrival of new devices and displaying GUI to the user.

Power Manager
Handles Power events (power-off, stand-by, hibernate, etc.) generated during the changes in the computer's power state.

Drivers and Devices

Drives provide an interface between the kernel subsystem and their devices. The kernel subsystems sends I/O request to the driver which process these requests and communicates with the devices as required. Any data output from the device is passed back to the kernel subsystem that generated the request. Drivers also handle I/O request generated from kernel subsystems such as PnP IRPs and Power IRPs to handle tasks such as preparing device for removal or hibernation.

In the upcoming blog lets dive into the "Device Objects and the Device Stack."