WDM - Windows Driver Model overview
- 1. Windows Driver Model Overview Prasad Talekar Windows Driver Model Overview 1
- 2. Agenda Windows Driver Model Overview 2 Windows Architecture1 Device Driver Overview2 What is WDM3 WDM Layered Architecture4 WDM Device Objects5
- 3. Windows Architecture Windows Driver Model Overview 3
- 4. Device Driver • Only one that can touch hardware, handle interrupts, etc. • Has a SYS extension • Its routines always run in kernel mode • Also called “Privileged mode” • Ring 0 on 80x86 • Always uses the kernel mode stack • Unhandled exceptions will crash the system • Producing the infamous “Blue Screen of Death” • Usually invoked by a user mode code (ReadFile, WriteFile, DeviceIoControl) Windows Driver Model Overview 4
- 5. Windows Driver Model (WDM) • A model for writing device drivers • Source compatibility between Windows 98/ME and Windows 2000/XP • Be designed as a bus driver, a function driver, or a filter driver, as described in Types of WDM Drivers. • Create device objects as described in WDM Device Objects and Device Stacks. • Standard handling for Plug & Play (P&P), Power Management and Windows Management Instrumentation (WMI) • Supports a wide range of buses (PCI, USB, IEEE1394 and more) • Extensible to support future buses • Supports a wide range of device classes (HID, Scanners, Modems, etc.) Windows Driver Model Overview 5
- 6. Benefits of Windows Driver Model • WDM helps developers produce more robust drivers with less effort. • Driver developers can gain substantial benefits from studying the WDM model for their device class during early driver development and test planning: • Developers can write one driver for multiple platforms. • Developers can use one development environment, the latest Windows DDK, which will be released concurrently with the release of Windows XP. • Writing one driver for multiple platforms means that developers can create and manage a single source-code base rather than writing a separate driver for each platform, and this reduces the amount of code that must be tested and debugged. Windows Driver Model Overview 6
- 7. Benefits of Windows Driver Model • The WDM strategy is a cornerstone of Microsofts driver quality initiative, which includes: • The Windows DDK, which provides build environments, sample code, and documentation for developing WDM drivers. • Test tools, such as Driver Verifier and the Windows Hardware Compatibility Tests, supplied with the Windows DDK. • All bus drivers are supplied by Microsoft. • For as many device classes as possible, contribute WDM code that enables a port/miniport driver model. • Microsoft Technical Support for driver developers. • Driver signing, which contributes to the stability of the Windows operating system in the field by guarding against the installation of untested device drivers. • Testing of final versions of third-party device drivers by Windows Hardware Quality Labs (WHQL). Windows Driver Model Overview 7
- 8. WDM Driver Stack Windows Driver Model Overview 8 • There are three kinds of WDM drivers: – Bus drivers, which drive an I/O bus and provide per-slot functionality that is device-independent. – Function drivers, which drive an individual device. – Filter drivers, which filter I/O requests for a device, a class of devices, or a bus. • In this context, a bus is any device to which other physical, logical, or virtual devices are attached; a bus includes traditional buses such as SCSI and PCI, as well as parallel ports, serial ports, and i8042 ports.
- 9. WDM Driver Stack Windows Driver Model Overview 9 • A bus driver services a bus controller, adapter, or bridge. • Bus drivers are required drivers; there is one bus driver for each type of bus on a machine. • Microsoft provides bus drivers for most common buses. IHVs and OEMs can provide other bus drivers. • A bus filter driver typically adds value to a bus and is supplied by Microsoft or a system OEM. There can be any number of bus filter drivers for a bus. • Lower-level filter drivers typically modify the behavior of device hardware. • They are optional and are typically supplied by IHVs. There can be any number of lower-level filter drivers for a device.
- 10. WDM Driver Stack Windows Driver Model Overview 10 • A Function driver is the main driver for a device. • Function Driver is something which is a called as Driver. • A function driver is typically written by the device vendor and is required (unless the device is being used in raw mode). • Upper-level filter drivers typically provide added- value features for a device. They are optional and are typically provided by IHVs.
- 11. Bus Driver • The primary responsibilities of a bus driver are to: – Enumerate the devices on its bus. – Respond to Plug and Play IRPs and power management IRPs. – Multiplex access to the bus (for some buses). – Generically administer the devices on its bus. During enumeration, a bus driver identifies the devices on its bus and creates device objects for them. The method a bus driver uses to identify connected devices depends on the particular bus. • A bus driver performs certain operations on behalf of the devices on its bus, including accessing device registers to physically change the power state of a device. For example, when the device goes to sleep, the bus driver sets device registers to put the device in the proper device power state. Windows Driver Model Overview 11
- 12. Bus Driver • A bus driver does not handle read and write requests for the devices on its bus. Read and write requests to a device are handled by the device's function driver. Only if the device is being used in raw mode does the parent bus driver handle reads and writes for the device. • A bus driver acts as the function driver for its controller, adapter, or bridge, and therefore manages device power policy for these components. • A bus driver can be implemented as a driver/minidriver pair. Windows Driver Model Overview 12
- 13. Function Driver • A function driver is the main driver for a device and is typically written by the device vendor and is required (unless the device is being used in raw mode). • The PnP Manager loads at most one function driver for a device. • A function driver provides the operational interface for its device. Typically the function driver handles reads and writes to the device and manages device power policy. • The function driver for a device can be implemented as a driver/minidriver pair, such as a port/miniport driver pair or a class/miniclass driver pair. • If a device is being driven in raw mode, it has no function driver and no upper or lower-level filter drivers. All raw-mode I/O is done by the bus driver and optional bus filter drivers. Windows Driver Model Overview 13
- 14. Filter Driver Filter drivers are optional drivers that add value to or modify the behavior of a device. A filter driver can service one or more devices. There are three types of Filter Drivers – Bus Filter Driver – Lower Level Filter Driver – Upper Level Filter Driver Bus Filter Drivers - Typically add value to a bus and are supplied by Microsoft or a system OEM. Bus filter drivers are optional. There can be any number of bus filter drivers for a bus. A bus filter driver could, for example, implement proprietary enhancements to standard bus hardware. Windows Driver Model Overview 14
- 15. Filter Driver (Conti) Lower-Level Filter Drivers - Typically modify the behavior of device hardware. They are typically supplied by IHVs and are optional and can be any number of lower-level filter drivers for a device. A lower-level device filter driver monitors and/or modifies I/O requests to a particular device. Typically, such filters redefine hardware behavior to match expected specifications. A lower-level class filter driver monitors and/or modifies I/O requests for a class of devices. For example, a lower-level class filter driver for mouse devices could provide acceleration, performing a nonlinear conversion of mouse movement data. Upper-Level Filter Drivers. Upper-level filter drivers typically provide added-value features for a device. Such drivers are usually provided by IHVs and are optional. An upper-level device filter driver adds value for a particular device. For example, an upper- level device filter driver for a keyboard could enforce additional security checks. Windows Driver Model Overview 15
- 16. WDM Driver Stack Windows Driver Model Overview 16 •Above the driver stack is an application. The application handles requests from users and other applications, and calls either the Win32 API or a routine that is exposed by the user-mode client driver. •A user-mode client driver handles requests from applications or from the Win32 API. For requests that require kernel-mode services, the user-mode client driver calls the Win32 API, which calls the appropriate kernel-mode client or support routine to carry out the request. User-mode client drivers are usually implemented as dynamic-link libraries (DLL). •A kernel-mode client driver handles requests similar to those handled by the user-mode client, except that these requests are carried out in kernel mode, rather than in user mode.
- 17. WDM Driver Stack Windows Driver Model Overview 17 •A device class and miniclass driver pair provides the bulk of the device-specific support. • The class driver supplies system-required but hardware-independent support for a particular class of device. Class drivers are typically supplied by Microsoft. • A miniclass driver handles operations for a specific type of device of a particular class. For example, the battery class driver supports common operations for any battery, while a miniclass driver for a vendor's UPS device handles details unique to that particular device. Miniclass drivers are typically supplied by hardware vendors.
- 18. WDM Driver Stack Windows Driver Model Overview 18 •A corresponding port driver (for some devices, this is a host controller or host adapter driver) supports required I/O operations on an underlying port, hub, or other physical device through which the device attaches. •Whether any such drivers are present depends on the type of device and the bus to which it eventually connects. All driver stacks for storage devices have a port driver. •A corresponding miniport driver handles device-specific operations for the port driver. For most types of devices, the port driver is supplied with the operating system, and the miniport driver is supplied by the device vendor. •At the bottom of the figure is the hardware bus driver. Microsoft supplies bus drivers for all the major buses as part of the operating system. You should not attempt to replace these drivers.
- 19. Device Objects Windows Driver Model Overview 19 •Represents a stack of devices • PDO: Physical Device Object • Created by the bus driver •FiDO: Filter Device Object • Optional lower/upper device objects •FDO: Functional Device Object • The “actual” WDM driver created device object
- 20. Device Enumeration • Upon boot, the P&P Manager performs enumeration of buses and devices • Starts from an imaginary “Root” device • Scans the system recursively to walk the device tree • Creates a PDO for each physical device • Loads lower filter drivers (if exist) • They create their FiDOs • Loads “the driver” • It should create the FDO • Loads upper filter drivers (if exist) • They create their FiDOs Windows Driver Model Overview 20
- 21. Two Basic Data Structures Windows Driver Model Overview 21 • DRIVER_OBJECT Represents the driver for the I/O system Includes dispatch routine pointers, AddDevice routine pointer, Unload routine pointer, etc. Created by the Kernel, passed to driver and filled by it
- 22. Two Basic Data Structures Windows Driver Model Overview 22 • DEVICE_OBJECT Defines a specific device (usually hardware) Associated with File objects Allows for driver-defined extensions Provides a DPC object for after Interrupt processing Created by the driver using IoCreateDevice Several may be created
- 23. Windows Driver Model Overview 23 Q & A
Editor's Notes
- #14: Device Function Drivers A function driver is the main driver for a device. A function driver is typically written by the device vendor and is required (unless the device is being used in raw mode). A function driver can service one or more devices. Class drivers: These are a type of function drivers and can be thought of as built-in framework drivers that miniport and other class drivers can be built on top of. The class drivers provide interfaces between different levels of the WDM architecture. Common functionality between different classes of drivers can be written into the class driver and used by other class and miniport drivers. The lower edge of the class driver will have its interface exposed to the miniport driver, while the upper edge of top level class drivers is operating system specific. Class drivers can be dynamically loaded and unloaded at will. They can do class specific functions that are not hardware or bus-specific (with the exception of bus-type class drivers) and in fact sometimes only do class specific functions like enumeration. Miniport drivers: These are also function drivers for USB, Audio, SCSI and network adapters. They should usually be source and binary compatible between Windows 98 and Windows 2000 and are hardware specific but control access to the hardware through a specific bus class driver.
- #22: DeviceObject (PDEVICE_OBJECT) anchors a list of device object data structures, one for each of the devices managed by the driver. The I/O Manager links the device objects together and maintains this field. The DriverUnload function of a non-WDM driver would use this field to traverse the list of device objects in order to delete them. A WDM driver probably doesn’t have any particular need to use this field. DriverExtension (PDRIVER_EXTENSION) points to a small substructure within which only the AddDevice (PDRIVER_ADD_DEVICE) member is accessible to the likes of us. AddDevice is a pointer to a function within the driver that creates device objects; HardwareDatabase (PUNICODE_STRING) describes a string that names a hardware database registry key for the device. This is a name like “\Registry\Machine\Hardware\Description\System and names” the registry key within which resource allocation information resides. WDM drivers have no need to access the information below this key because the PnP Manager performs resource allocation automatically. The name is stored in Unicode. (In fact, all kernel-mode string data uses Unicode.) FastIoDispatch (PFAST_IO_DISPATCH) points to a table of function pointers that file system and network drivers export. DriverStartIo (PDRIVER_STARTIO) points to a function in your driver that processes I/O requests that the I/O Manager has serialized for you. DriverUnload (PDRIVER_UNLOAD) points to a cleanup function in your driver. MajorFunction (array of PDRIVER_DISPATCH) is a table of pointers to functions in your driver that handle each of the roughly two dozen types of I/O requests. This table is also something of a big deal, as you might guess, because it defines how I/O requests make it into your code.
- #23: DriverObject (PDRIVER_OBJECT) points to the object describing the driver associated with this device object, usually the one that called IoCreateDevice to create it. NextDevice (PDEVICE_OBJECT) points to the next device object that belongs to the same driver as this one. This field is the one that links device objects together starting from the driver object’s DeviceObject member. CurrentIrp (PIRP) is used by the Microsoft IRP queuing routines StartPacket and StartNextPacket to record the IRP most recently sent to your StartIo routine. WDM drivers should implement their own IRP queues and may have no use for this field. Flags (ULONG) contains a collection of flag bits. FlagDescription DO_BUFFERED_IO - Reads and writes use the buffered method (system copy buffer) for accessing user-mode data. DO_EXCLUSIVE - Only one thread at a time is allowed to open a handle. DO_DIRECT_IO - Reads and writes use the direct method (memory descriptor list) for accessing user-mode data. DO_DEVICE_INITIALIZING - Device object isn’t initialized yet. DO_POWER_PAGABLE IRP_MJ_PNP must be handled at PASSIVE_LEVEL. DO_POWER_INRUSH Device requires large inrush of current during power-on. Characteristics (ULONG) is another collection of flag bits describing various optional characteristics of the device. The I/O Manager initializes these flags based on an argument to IoCreateDevice. FlagDescription FILE_REMOVABLE_MEDIA Media can be removed from device. FILE_READ_ONLY_DEVICE Media can only be read, not written. FILE_FLOPPY_DISKETTE Device is a floppy disk drive. FILE_WRITE_ONCE_MEDIA Media can be written once. FILE_REMOTE_DEVICE Device accessible through network connection. FILE_DEVICE_IS_MOUNTED Physical media is present in device. FILE_VIRTUAL_VOLUME This is a virtual volume. FILE_AUTOGENERATED_DEVICE_NAME I/O Manager should automatically generate a name for this device. FILE_DEVICE_SECURE_OPEN Force security check during open. DeviceExtension (PVOID) points to a data structure you define that will hold per-instance information about the device. The I/O Manager allocates space for the structure, but its name and contents are entirely up to you. A common convention is to declare a structure with the type name DEVICE_EXTENSION. To access it given a pointer (for example, fdo) to the device object, use a statement like this one: PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo->DeviceExtension; It happens to be true (now, anyway) that the device extension immediately follows the device object in memory. It would be a bad idea to rely on this always being true, though, especially when the documented method of following the DeviceExtension pointer will always work. DeviceType (DEVICE_TYPE) is an enumeration constant describing what type of device this is. The I/O Manager initializes this member based on an argument to IoCreateDevice. Filter drivers might conceivably need to inspect it. StackSize (CCHAR) counts the number of device objects starting from this one and descending all the way to the PDO. The purpose of this field is to inform interested parties regarding how many stack locations should be created for an IRP that will be sent first to this device’s driver. WDM drivers don’t normally need to modify this value, however, because the support routine they use for building the device stack (IoAttachDeviceToDeviceStack) does so automatically. AlignmentRequirement (ULONG) specifies the required alignment for data buffers used in read or write requests to this device.