This article provides an orientation to WDM. Windows driver model (WDM) is a strategy for making driver development simpler.

The ultimate goal of WDM is a more robust platform for Microsoft Windows operating systems and better user experiences with new hardware for Windows-based PCs. WDM provides a common set of services for developers to create drivers that are compatible across Windows operating systems for certain device classes. A WDM driver can be source-code-compatible for Windows XP, Windows 2000, Windows Millennium Edition (Windows Me), and Windows 98.

The above figure is a simplified architectural diagram of Windows, showing how WDM kernelmode drivers integrate into the overall architecture. Windows is divided into two different operating modes: user mode and kernel mode. User Applications run in user mode whereas the core operating system -which includes the kernel and all kernel-mode drivers-runs in kernel mode. User-mode programs are not trusted by the Windows core operating system. They run in a restricted environment that prevents them from compromising other applications or the core operating system. Kernel-mode programs (including drivers) are trusted components of the Windows core operating system. They operate with relatively few restrictions and some corresponding risks. A error on their part can cause the system to crash. Applications and the Windows API Applications which typically initiate I/O requests, run in user mode. They have no direct access to kernel-mode components. They issue I/O requests by calling the appropriate Windows API function, which in turn passes the request to the appropriate kernel-mode component. The Win32 API is divided into 3 component parts, each one a .DLL: kernel32.DLL: High-level functions for performing a variety of system tasks. gdi32.DLL: Basic functions for drawing. user32.DLL: Functions that implement the user-interface of Windows (message boxes etc). Kernel Subsystems Kernel subsystems handle the core Windows functionality. They expose Device Driver Interface routines (DDI routines) that allow drivers to interact with the operating system. Drivers and Devices Drivers provide an interface between their devices and the kernel subsystems. The kernel subsystems send I/O requests (which could be on behalf of user applications) to the drivers. The drivers process the request and communicate with the devices as required.

This the true picture of how the WDM drivers are positioned in the windows kernel. The single driver (per device) shown previously has been broken down into the following layers:
Bus drivers Provide a (hardware) bus interface on a per slot basis. They create one or more Physical Device Objects (PDOs). Function drivers Provide read, write, and other functional logic for an individual device. They create one or more Functional Device Objects (FDOs)

Filter drivers Provide modifications to an I/O request before presentation to lower layer drivers. Filters can be placed either above or below a functional driver. They create one or more Filter Device Objects (Filter DOs). Each driver has one or more associated device object. Device objects help the drivers to maintain the device's characteristics and state. Since two or more devices can share the same driver object, it the Device object that serves as the (unique) target of all operations on the device.
The device objects are arranged in a device stack, with a separate stack for each device. Typically, device stack refers to the stack of device objects, plus the associated drivers. However, a device stack is associated with a single device, whereas a set of drivers can service multiple device stacks. The set of drivers is sometimes referred to as a driver stack.

Driver contains a collection of routines that can be called by the I/O Manager. The I/O Manager typically calls a driver routine at the following conditions: i. When a driver is loaded ii. When a driver is unloaded or the system is shutting down iii. When a device is inserted or removed iv. When a user-mode program issues an I/O request (which is routed through the device object) v. When a shared hardware resource becomes available for driver use
I/O request packets (IRPs) are kernel mode structures that are used to facilitate communication between each of the WDM drivers as well as when the operating system needs to communicate with the drivers. Life-cycle of IRP: I. With each user-mode request for I/O, the I/O Manager allocates an IRP from nonpaged system memory. The I/O Manager is responsible to pass the IRP to the appropriate driver. II. When the operation is complete, the driver stores a final status code in the IRP and returns it to the I/O Manager. III. The I/O Manager uses the information in the IRP to complete the request and send the user the final status.

The driver object is basically a group of pointers to various driver functions.

The I/O Manager creates a driver object whenever it loads a driver. When driver needs to be unloaded, the I/O Manager uses the driver object to find an Unload routine. When the Unload routine returns, the I/O Manager deletes the Driver object. The dispatch routine is the first routine that processes a IRP. It checks the parameters of the request, and if valid, passes the IRP to the driver's Start I/O routine begin the start of a data transfer. When an IRP is sent to a specific device, the I/O Manager uses the MajorFunction[] table (indexed by I/O operation code) to find the right Dispatch routine. If a request involves an actual device operation, the I/O Manager uses the driver object to locate the driver's Start I/O routine.

The operating system represents devices by device objects. Kernel-mode drivers must create at least one device object for each device. Device objects serve as the target of all operations on the device.
The Device object is created by the DriverEntry routine. It gets deleted when the driver unloaded using the unload routine. However for Plug and Play devices the corresponding device objects get created and destroyed in the AddDevice and RemoveDevice PNP routines. The I/O Manager maintains the current IRP and a queue of pending IRPs in the device object. The "Driver Object" pointer is used by the I/O manager to find the corresponding driver object. There it can find driver dispatch routines (using the MajorFunction table) to operate on I/O requests. Device extension is a memory block from the non-paged pool which is used to hold any information associated with a particular device. The driver author specifies both the size and contents of the device extension. Its structure is defined in the driver's header file.