This presentation covers overview of Windows Driver Framework (WDM) which explains Windows Architecture, Windows Driver Overview, WDM Layered Architecture and basic data structures. This has detail explanation of all basic modules and layers of WDM. Helpful for beginners.
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
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.
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.
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.