Wdm windows driver model

From Wikipedia, the free encyclopedia

In computing, the Windows Driver Model (WDM) – also known at one point as the Win32 Driver Model – is a framework for device drivers that was introduced with Windows 98 and Windows 2000 to replace VxD, which was used on older versions of Windows such as Windows 95 and Windows 3.1, as well as the Windows NT Driver Model.

WDM drivers are layered in a stack and communicate with each other via I/O request packets (IRPs). The Microsoft Windows Driver Model unified driver models for the Windows 9x and Windows NT product lines by standardizing requirements and reducing the amount of code that needed to be written. WDM drivers will not run on operating systems earlier than Windows 98 or Windows 2000, such as Windows 95 (before the OSR2 update that sideloads the WDM model), Windows NT 4.0 and Windows 3.1. By conforming to WDM, drivers can be binary compatible and source-compatible across Windows 98, Windows 98 Second Edition, Windows Me, Windows 2000, Windows XP and Windows Server 2003 on x86-based computers. WDM drivers are designed to be forward-compatible so that a WDM driver can run on a version of Windows newer than what the driver was initially written for, but doing that would mean that the driver cannot take advantage of any new features introduced with the new version. WDM is generally not backward-compatible, that is, a WDM driver is not guaranteed to run on any older version of Windows. For example, Windows XP can use a driver written for Windows 2000 but will not make use of any of the new WDM features that were introduced in Windows XP. However, a driver written for Windows XP may or may not load on Windows 2000.

WDM exists in the intermediary layer of Windows 2000 kernel-mode drivers and was introduced to increase the functionality and ease of writing drivers for Windows. Although WDM was mainly designed to be binary and source compatible between Windows 98 and Windows 2000, this may not always be desired and so specific drivers can be developed for either operating system.

Device kernel-mode drivers

[edit]

With the Windows Drivers Model (WDM) for devices Microsoft implements an approach to kernel mode drivers that is unique to Windows operating systems. WDM implements a layered architecture for device drivers, and every device of a computer is served by a stack of drivers. However, every driver in that stack can chain isolate hardware-independent features from the driver above and beneath it. So drivers in the stack do not need to interact directly with one another. WDM defines architecture and device procedures for a range of devices, such as display and the network card, known as Network Driver Interface Specification (NDIS). In the NDIS architecture the layered network drivers include lower-level drivers that manage the hardware and upper-level drivers that implement network data transport, such as the Transmission Control Protocol (TCP).[1]

While WDM defines three types of device drivers, not all driver stacks for a given device contain all types of device drivers. The three WDM device driver types are:[1]

Bus driver: For every bus on the mainboard there is a one bus driver, with the primary responsibility for the identification of all devices connected to that bus and responding to plug and play events. Microsoft will provide bus drivers as part of the operating system,[1] such as PCI, PnPISA, SCSI, USB and FireWire.

Function driver: this is the principal driver for a device and it provides the operational interface for a device by handling read and write operations. Function drivers are written by the device vendors, and for their interaction with the hardware they depend on a specific bus driver being present in the Windows operating system.[1]

Filter driver: This driver is optional, and can modify the behaviour of a device, such as input and output requests. These drivers can be implemented as lower-level and upper-level filter drivers.[1]

Object-oriented driver stack

[edit]

Function drivers and bus drivers are often implemented as driver/minidriver pairs, which in practice is either a class or miniclass, or a port or miniport pair.[2]

Bus drivers for devices attached to a bus are implemented as class drivers and are hardware-agnostic. They will support the operations of a certain type of device. Windows operating systems include a number of class drivers, such as the kbdclass.sys driver for keyboards. Miniclass drivers on the other hand are supplied by the vendor of a device, and only support device specific operations, for a particular device of a given class.[2]

Port drivers support general input/output (I/O) operations for a peripheral hardware interface. The core functionality of port drivers is mandated by the operating system, and Windows operating systems integrate a variety of port drivers. For example, the i8042prt.sys port driver for the 8042 microcontroller connects PS/2 keyboards to the mainboard peripheral bus. The miniport drivers, like the miniclass drivers, are supplied by the hardware vendors and support only device specific operations of peripheral hardware that is connected to a port on the mainboard.[3][4]

Each driver that processes an I/O request for a device has a corresponding object, which is loaded into main memory. A device object is created by the Windows operating system from the associated device class. Device objects contain structures of type DEVICE_OBJECT, which store pointers to their driver. At run time these pointers are used to locate a driver’s dispatch routine and member functions. In the WDM driver stack, the filter driver device object, known as the upper filter, will receive an I/O request packet (IRP) for a device from the I/O manager. If the upper filter driver can not serve the request, it will locate the object of the driver one step down in the driver stack. The IRP is passed down the driver stack by calling the function IoCallDriver(), and processed by the function driver device object, also known as functional device object. The function driver device object in turn may pass the IRP to the lower filter, another filter device object. Then the IRP may be passed down to the bus driver, which operates as the physical device object. The bus driver object is at the bottom of the driver stack, and interacts with the hardware abstraction layer, which is part of the Windows operating system kernel and allows Windows operating systems to run on a variety of processors, different memory management unit architectures, and a variety of computer systems with different I/O bus architectures.[5] The execution of an IRP is finished when any of the driver objects in the stack returns the request back to the I/O manager, with the result and a status flag.[6]

Device drivers for different Windows operating systems

[edit]

The WDM framework was developed by Microsoft to simplify the communication between the operating system and drivers inside the kernel. In Windows operating systems, drivers are implemented as Dynamic Link Libraries .DLL or .SYS files. WDM compliant drivers must follow rules of design, initialisation, plug-and-play, power management and memory allocation. In practice WDM driver programmers reuse large pieces of code when building new object-oriented drivers. This means that drivers in the WDM stack may contain residual functionality, which is not documented in specifications.[6] Drivers that have passed the Microsoft quality test are digitally signed by Microsoft. The Microsoft Hardware Compatibility Tests and the Driver Development Kit include reliability and stress tests.[7]

A device driver that is not designed for a specific hardware component may allow another device to function. This is because the basic functionality of a hardware device class is similar. The functionality of the video card class, for example, allows the Microsoft Basic Display Adapter driver to work with a wide variety of video cards. However, installing the wrong driver for a device will mean that the full functionality of the device can not be used, and may result in poor performance and the destabilization of the Windows operating system. Hardware device vendors may release updated device drivers for particular Windows operating systems, to improve performance, add functionality or fix bugs. If a device is not working as expected the latest device drivers should be downloaded from the vendor website and installed.[8]

Device drivers are designed for particular Windows operating system versions, and device drivers for a previous version of Windows may not work correctly or at all with other versions. Because many device drivers run in kernel mode installing drivers for a previous operating system version may destabilise the Windows operating system. Migrating a computer to a higher version of a Windows operating system therefore requires that new device drivers are installed for all hardware components. Finding up to date device drivers and installing them for Windows 10 has introduced complications into the migration process.[8]

Common device driver compatibility issues include: a 32-bit device driver is required for a 32-bit Windows operating system, and a 64-bit device driver is required for a 64-bit Windows operating system. 64-bit device drivers must be signed by Microsoft, because they run in kernel mode and have unrestricted access to the computer hardware. For operating systems prior to Windows 10 Microsoft allowed vendors to sign their 64-bit drivers themselves, assuming vendors had undertaken compatibility tests. However, Windows 10 64-bit drivers now need to be signed by Microsoft. Therefore, device vendors have to submit their drivers to Microsoft for testing and approval. The driver installation package includes all files in the .inf directory, and all files in the package need to be installed, otherwise the installation of the device driver may fail. For operating system versions before Windows 10 not all files necessary for the driver installation were included in the package, as this requirement was not consistently enforced. Some device driver installers have a user interface GUI, often requiring user configuration input. The absence of a user interface does not mean that the installation of the device driver is not successful. Besides, Windows 10 device drivers are not allowed to include a user interface. The Network Driver Interface Specification (NDIS) 10.x is used for network devices by the Windows 10 operating system. Network device drivers for Windows XP use NDIS 5.x and may work with subsequent Windows operating systems, but for performance reasons network device drivers should implement NDIS 6.0 or higher.[8]

The Device Manager is a Control Panel applet in Microsoft Windows operating systems. It allows users to view and control the hardware attached to the computer. It allows users to view and modify hardware device properties, and is also the primary tool to manage device drivers.[8]

The Windows Driver Model, while a significant improvement over the VxD and Windows NT Driver Model used before it, has been criticised by driver software developers,[9] most significantly for the following:

  • Interactions with power management events and plug and play are difficult. This can lead to situations where Windows machines cannot enter or exit sleep modes correctly due to bugs in driver code.
  • I/O cancellation is difficult to get right.[10]
  • Complex boilerplate support code is required for every driver.
  • There is no support for writing pure user-mode drivers.

There were also a number of concerns about the quality of documentation and samples that Microsoft provided.

Because of these issues, Microsoft has released a new set of frameworks on top of WDM, called the Windows Driver Frameworks (WDF; formerly Windows Driver Foundation), which includes Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF). Windows Vista supports both pure WDM and the newer WDF. KMDF is also available for download for Windows XP and Windows 2000, while UMDF is available for Windows XP and above.

  • Windows Driver Frameworks (WDF)
    • Kernel-Mode Driver Framework (KMDF)
    • User-Mode Driver Framework (UMDF)
  • Windows Display Driver Model (WDDM)
  1. ^ a b c d e Marco Vieira; Joao Carlos Cunha, eds. (2013). Dependable Computing: 14th European Workshop, EWDC 2013, Coimbra, Portugal, May 15-16, 2013, Proceedings. Springer. p. 64. ISBN 9783642387890.
  2. ^ a b Bill Blunden (2009). The Rootkit Arsenal: Escape and Evasion. Jones & Bartlett Publishers. p. 460. ISBN 9781449661229.
  3. ^ Bill Blunden (2009). The Rootkit Arsenal: Escape and Evasion. Jones & Bartlett Publishers. p. 460. ISBN 9781449661229.
  4. ^ «Introduction to the Windows Driver Foundation». Microsoft Developer Network. 2006-10-13. Retrieved 2010-12-06. The device class-specific driver models are typically structured as a port driver written by Microsoft paired with a miniport driver written by an independent hardware vendor. The port driver does much of the work required for the device class, and the miniport driver supports device-specific characteristics.
  5. ^ Bill Blunden (2009). The Rootkit Arsenal: Escape and Evasion. Jones & Bartlett Publishers. pp. 460–461. ISBN 9781449661229.
  6. ^ a b Dave Penkler; Manfred Reitenspiess; Francis Tam, eds. (2006). Service Availability: Third International Service Availability Symposium, ISAS 2006, Helsinki, Finland, May 15-16, 2006, Revised Selected Papers. Springer Science & Business Media. p. 124. ISBN 9783540687245.
  7. ^ Dave Penkler; Manfred Reitenspiess; Francis Tam, eds. (2006). Service Availability: Third International Service Availability Symposium, ISAS 2006, Helsinki, Finland, May 15-16, 2006, Revised Selected Papers. Springer Science & Business Media. p. 132. ISBN 9783540687245.
  8. ^ a b c d Byron Wright; Leon Plesniarski (2016). Microsoft Specialist Guide to Microsoft Windows 10 (Exam 70-697, Configuring Windows Devices). Cengage Learning. p. 96. ISBN 9781285868578.
  9. ^ Oney, Walter (May 6, 2003). «Introducing Windows Driver Framework». Windows Driver Developer’s Digest. Vol. 1, no. 3. Archived from the original on 2016-01-25.
  10. ^ «I/O Completion/Cancellation Guidelines». MSDN. Microsoft. May 5, 2003. Archived from the original on February 9, 2018. Retrieved 2018-02-08.
  • Finnel, Lynn (2000). MCSE Exam 70-215, Microsoft Windows 2000 Server. Microsoft Press. ISBN 1-57231-903-8.
  • Oney, Walter (2003). Programming the Windows Driver Model, Microsoft Press, ISBN 0-7356-1803-8.
  • WDM Input Output Concepts — This article gives a high level overview of the I/O concepts as defined in the Windows Driver Model.
  • Windows driver API basics — This article informs you about the basics behind sound card drivers such as WDM, ASIO, MME, DirectX, etc.
  • Channel 9 Video — Interview with the Device Management and Installation team at Microsoft, primarily covering Plug-and-play.
  • Lecture Notes on Windows Kernel Programming at the Wayback Machine (archived March 3, 2016) — Free lecture notes book fragment detailing basic creation of Windows Drivers, Kernel Mode programming, and Memory management

Источник

Updated: April 15, 2002

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.

This article provides an orientation to WDM for non-developers. Driver developers should see the Windows DDK for in-depth information about developing WDM and non-WDM drivers for Windows operating systems.

Windows DDK

http://msdn.microsoft.com/en-us/windows/hardware/gg487428.aspx

On This Page

  Why WDM Is Important
  How WDM Benefits Developers
  WDM for Windows XP, Windows 2000, and Windows Me
  WDM Bus and Device Support
  Layered Driver Architecture
  Function Drivers Structured as Class Drivers and Minidrivers
  Writing WDM Drivers

Why WDM Is Important

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.

The WDM strategy is a cornerstone of Microsofts driver quality initiative, which also 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, in the operating system, and from the web.

  • 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 early versions of third-party device drivers through the Microsoft Windows Beta program.

  • Testing of final versions of third-party device drivers by Windows Hardware Quality Labs (WHQL).

How WDM Benefits Developers

WDM development at Microsoft has developed, tested, and released code for each version of the Windows operating system since Windows 95. Microsoft WDM developers:

  • Contribute to a development environment that is common across all releases of Windows as listed earlier. A completely common development across all Windows platforms would enable third-party driver developers to create a single driver binary for their device that would run on all versions of Windows.

  • Write WDM bus drivers. 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 builds the port driver as part of the Windows product, and third-party vendors write minidrivers for their particular hardware. Minidrivers use services exported by the Microsoft port driver to perform many of the functions common to a device driver.

WDM for Windows XP, Windows 2000, and Windows Me

All versions of Microsoft Windows after Windows 95 have implemented WDM, which has continued to evolve for Windows XP, Windows 2000, and Windows Me. With a few special-case statements in the code, WDM drivers for supported device classes can be source-code compatible across Windows XP/Windows 2000 and Windows 98/Me operating systems.

Binary compatibility is possible on processors that are compatible with the Intel Architecture. Achieving a single binary still requires rigorous testing on all versions of all operating systems.

Later operating system releases support WDM features that were not available in earlier releases. For details about differences between WDM versions, see «Writing Drivers for Multiple Platforms and Operating Systems» in the Beta release of the Windows DDK to be released with Windows XP.

WDM Bus and Device Support

Bus Support. In the context of WDM, a bus is any device to which other physical, logical, or virtual devices are attached. Windows XP contains WDM support for these buses:

  • PCI

  • Dynamic Plug and Play serial I/O buses, including USB and IEEE 1394

  • SCSI

  • NDIS

  • Remote NDIS (RNDIS)

The goals of new RNDIS support are consistent with the WDM strategy:

  • Simplify the development experience for network device hardware manufacturers

  • Reduce the need for device-specific Windows network drivers

  • Simplify the installation experience for end-users of network devices

RNDIS Information for Developers

http://msdn.microsoft.com/en-us/windows/hardware/gg463293.aspx

Device Support. Windows XP contains WDM support for:

  • USB device classes, such as the Human Interface Device (HID) class

  • Cameras/scanners

  • Video capture over IEEE 1394

  • Audio

  • WinModem, for controllerless modems

  • USB and IEEE 1394 storage devices

Layered Driver Architecture

WDM uses a layered approach in which a given device is served by at least two drivers: a bus driver and a function driver. A device might also have filter drivers that add value or modify the behavior of the device. The chain of drivers that serve a device is called a driver stack.

Bus drivers. A bus driver serves an I/O bus, such as IEEE 1394. In context of WDM, a bus is any device to which other physical, logical, or virtual devices are attached. This includes traditional buses such as SCSI and PCI, as well as parallel ports, serial ports, and i8042 ports.

Microsoft supplies the bus drivers for Windows operating systems. A bus driver provides the following services for third-party driver developers:

  • Enumerates the devices on its bus

  • Responds to Plug and Play and power management I/O requests

  • Provides device-independent administration for the devices on its bus

Function drivers. A function driver is the main driver for a device and is typically written by the device manufacturer. The primary responsibilities of a function driver are to:

  • Provide the operational interface for the device

  • Handle reads and writes to the device

  • Manage device power policy

Filter drivers. Filter drivers are an option available to driver writers who must add value to or modify the behavior of a device, a class of devices, or a bus. A filter driver is installed above or below one or more other drivers in a driver stack. A filter driver intercepts requests for a device, a class of devices, or a bus, evaluates these requests, and may modify the content or destination of the request. For example:

  • An upper-level filter driver for a USB keyboard might enforce additional security checks.

  • A lower-level class filter for a mouse device might provide acceleration by performing a non-linear conversion of mouse movement data.

Function Drivers Structured as Class Drivers and Minidrivers

Common operations for a class of devices can be implemented in a class driver. Driver developers write a much smaller minidriver that interacts with their hardware and that calls the class driver to do most of the work. Taken together, a class driver and a minidriver serve as the function driver for a device.

  • Microsoft-supplied class drivers handle common system tasks, such as Plug and Play and power management, for all devices of a particular class. Class drivers ensure that the operating system handles such tasks consistently, resulting in a more consistent user experience.

  • Vendor-supplied minidrivers implement hardware-specific operations and call the appropriate class driver to perform the common tasks. The smaller amount of driver code in the minidriver means fewer code paths that can potentially fail and cause a bad experience for the user.

If an industry standard exists for a device class, the Microsoft-supplied WDM class driver may be able to handle all the necessary tasks for a device that fully implements the standard, which eliminates the need for a third-party minidriver. For example, the Microsoft-supplied HID class driver is based on the USB HID Class Specification, v1.1, and eliminates the need for a third-party minidriver for many USB keyboards, mice, and game controllers.

Microsoft provides the following WDM class drivers:

  • Stream class driver to support kernel-mode streaming of data for video capture, MPEG decoders, audio, DVD, and broadcast architectures

  • HID class driver to support input devices

  • USB and IEEE 1394 bus class drivers

  • Storage protocol support for serial and parallel buses

Support routines for WDM Drivers
Various components of the operating system kernel expose support routines for WDM drivers.  
Component Description
Kernel Synchronization primitives, performance counters and timers, stall and IRQ control
Object Manager Object reference counting
Executive Memory allocations, interlocked operations, list operations
I/O Manager I/O Request Packet (IRP) handling, device objects, work items, registry access, system state notifications, DMA and interrupts
Memory Manager Virtual-to-physical memory mapping, physical memory commitment and locking, driver image memory locking, portable I/O space
Process Service System thread creation and deletion
Run-time Library Bulk memory, Unicode, and data type conversions
Power Manager Power state changes, power IRP handling, device idle detection
Plug and Play Subsystem Hardware detection and resource allocation, Plug and Play IRP handling, hardware events
Windows Management Instrumentation (WMI) Support and infrastructure for exposing device measurement and instrumentation data
Kernel Streaming Support and infrastructure for streaming-data device connections
Hardware Abstraction Layer Platform abstraction; access and usage for I/O ports and memory-mapped devices

Writing WDM Drivers

Any new kernel-mode driver should be a WDM driver, and Windows XP is the recommended development platform. All WDM drivers must support Plug and Play and power management and can also implement WMI, as documented in the Windows DDK.

In general, it is always better to start driver development on Windows XP and then migrate support back to other Windows versions. This is true even if driver support for the targeted device does not fit completely within the WDM model.

To write a WDM driver, developers must understand differences among Windows platforms as documented in the latest Windows DDK. Developers should also understand bus- and device-specific issues, and Windows kernel concepts such as:

  • Thread-based and interrupt-based scheduling

  • Synchronization

  • Device objects and driver objects

  • I/O theory, including handling IRPs, queuing, and asynchronous I/O

  • Security

  • Debugging

Differences among Windows platforms are documented in the Windows DDK. Here are some brief examples:

  • Driver code generally executes differently on the different Windows platforms; this is because WDM allows for significant architectural differences between Windows XP/Windows 2000 and Windows 98/Windows Me. After a driver is working on one platform, it must be thoroughly tested on the other platform, especially with multiprocessor systems.

  • WDM does not support all types of hardware. For example, separate printer or video drivers must be developed for each platform.

  • INF files must accommodate differences among platforms. In most cases, a driver can be installed with a single INF file, but will generally require separate sections for Windows XP/Windows 2000 and Windows 98/Windows Me.

Resources

Windows beta testing

Beta releases of Windows are distributed as part of MSDN Professional Subscriptions:
http://msdn.microsoft.com/en-us/subscriptions/default.aspx

Windows DDK

http://msdn.microsoft.com/en-us/windows/hardware/gg487428.aspx

Microsoft Technical Support for driver developers

http://support.microsoft.com/default.aspx?scid=fh;EN-US;CNTACTMS

Debugging tools and resources

http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx

Driver Verifier Preview in Windows XP

http://msdn.microsoft.com/en-us/windows/hardware/gg487389.aspx

Digital signatures for drivers

http://msdn.microsoft.com/en-us/windows/hardware/gg487317.aspx

Windows Hardware Quality Labs (WHQL)

http://msdn.microsoft.com/en-us/windows/hardware/gg463010.aspx

News and white papers for developing Windows drivers

http://msdn.microsoft.com/en-us/windows/hardware/gg454507.aspx

Programming the Microsoft Windows Driver Model

Walter Oney (Microsoft Press)
http://www.microsoft.com/mspress/books/2507.aspx

Terms

device object

A kernel-mode object, defined by the I/O Manager, that represents a physical, logical, or virtual device.
HID
Human Interface Devices
IEEE 1394
A high-speed serial bus that provides enhanced PC connectivity for a wide range of devices, including consumer electronics audio/video appliances, storage peripherals, other PCs, and portable devices.
INF file
A file that provides the operating system with information required to install and configure a device.
IRP
I/O Request Packet. A data structure used to send I/O requests between the operating system and device drivers.
kernel mode
The Windows kernel manages the most basic functions of the operating system, such as sharing the processor between different blocks of executing code. Kernel mode allows full, unprotected access to the system. A driver or thread running in kernel mode has access to system memory and hardware.
NDIS
Network Driver Interface Specification
PCI
Peripheral Component Interconnect
SCSI
Small Computer System Interface
USB
Universal Serial Bus
WHQL
Windows Hardware Quality Labs
WMI
Windows Management Instrumentation

Related Links
  • WDM: Introduction to Windows Driver Model
  • When to Write WDM Class Drivers

Источник

The Windows Driver Model (WDM) has been the foundation of modern driver development since Windows 98.

While Windows Driver Framework (WDF) has simplified many aspects of driver writing, WDM remains relevant for low-level and legacy hardware support.

What is WDM?

WDM (Windows Driver Model) was introduced to unify driver development across Windows versions.

Before WDM, Windows 9x used VxDs, while Windows NT had a completely different driver model.

VERY VERY DIFFFERENT!!!!!!!!!

WDM provided a single driver framework that worked across all modern Windows versions, making it easier for developers to write cross-compatible drivers.

The Evolution of WDM

1. WDM in Windows 98/2000/XP

  • Introduced structured layers: Bus Drivers, Function Drivers, Filter Drivers.
  • Provided a unified driver model for consumer and enterprise Windows.
  • Required extensive knowledge of kernel memory management and synchronization.

2. WDM in Windows Vista/7

  • Improved Plug and Play (PnP) support.
  • Added better power management.
  • Introduced Windows Driver Framework (WDF) to simplify driver development.

3. WDM in Windows 10/11

  • Still supports legacy drivers but encourages KMDF (Kernel-Mode Driver Framework).
  • Improved security with stricter driver signing requirements.
  • Added better debugging tools like WinDbg Preview and Verifier.

Why WDM is Still Relevant

Despite the introduction of WDF, some scenarios still require pure WDM development:

  • Legacy Hardware Support – Older devices without WDF support still need WDM drivers.
  • Real-Time Performance – WDM gives more direct control over kernel resources.
  • Custom Power Management – WDM allows for fine-tuned power control, useful for battery-sensitive devices.
  • Low-Level System Components – Security software and monitoring tools may need deep kernel access.

Writing a Modern WDM Driver

If you’re still writing a WDM driver, make sure to follow best practices to avoid crashes, memory leaks, and BSODs.

Tools You’ll Need:

  • Windows Driver Kit (WDK) – The essential toolkit for writing and testing drivers.
  • Visual Studio – Fully integrated with WDK.
  • WinDbg – The debugger you’ll love (or hate).
  • Driver Verifier – Helps catch bad behavior before deployment.

A Simple WDM Driver Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

#include <ntddk.h>

void DriverUnload(PDRIVER_OBJECT DriverObject)
{
    DbgPrint("WDM Driver Unloaded!\n");
}

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
    DbgPrint("Hello from the WDM driver!\n");
    DriverObject->DriverUnload = DriverUnload;
    return STATUS_SUCCESS;
}

What This Code Does:

  • Loads a minimal WDM driver.
  • Prints a message to the Windows debug console.
  • Unloads without crashing the system (very important).

Best Practices for WDM Development

1. Use Windows Driver Framework (WDF) When Possible

WDM is complex. If your hardware supports it, use KMDF or UMDF instead.

2. Always Implement Proper Memory Management

  • Use ExAllocatePoolWithTag instead of raw pointers.
  • Free all allocated memory to avoid leaks.

3. Handle Plug and Play Events Correctly

  • Register proper IRP_MJ_PNP handlers.
  • Implement Start, Stop, Remove device callbacks.

4. Test Your Driver with Verifier

Run Driver Verifier to detect memory leaks and crashes:

1

verifier /standard /driver MyDriver.sys

5. Debug Using WinDbg and !analyze -v

When a driver crashes (and it will crash), analyze the crash dump with:

6. Sign Your Driver for Windows 10/11

Windows requires signed drivers for security. To enable test signing for development:

1

bcdedit /set testsigning on

Common WDM Driver Issues (And Fixes)

1. BSOD on Driver Load

Fix: Check memory access and function pointers.

2. Driver Doesn’t Load

Fix: Make sure it’s properly signed or use Test Mode.

3. Memory Leaks

Fix: Use Driver Verifier and ensure proper deallocation.

4. System Freeze on Device Removal

Fix: Handle IRP_MJ_PNP properly and return correct status codes.

Windows Driver Framework (WDF): Modernizing Windows Driver Development

WDF is a modern, structured approach to driver development, designed to handle the complexities of kernel-mode and user-mode drivers while improving stability and security.

What is Windows Driver Framework (WDF)?

Windows Driver Framework (WDF) is a collection of libraries that simplifies Windows driver development by abstracting much of the complexity associated with WDM.

Instead of manually handling Plug and Play (PnP) requests, power management, and IRPs, WDF provides a structured way to build drivers with minimal boilerplate code.

WDF is split into two major frameworks:

  • Kernel-Mode Driver Framework (KMDF) – For drivers that need kernel access.
  • User-Mode Driver Framework (UMDF) – For drivers that can run in user space.

Why WDF is Better than WDM

1. Simplified Driver Development

  • WDF removes the need to manually process IRPs, reducing complexity.
  • Built-in event-driven model handles PnP and power management automatically.

2. Improved Stability and Security

  • KMDF provides better memory protection, reducing system crashes.
  • UMDF isolates drivers from the kernel, preventing BSODs.

3. Built-in Power and PnP Management

  • No need to manually write IRP_MJ_PNP or IRP_MJ_POWER handlers.
  • Automatically supports modern Windows power management features.

4. Easier Debugging and Maintenance

  • WDF provides structured logging and debugging tools.
  • WinDbg and WDF Verifier simplify troubleshooting.

Choosing Between KMDF and UMDF

Feature KMDF (Kernel-Mode) UMDF (User-Mode)
Performance High Moderate
Security Moderate High (Runs in user mode)
System Stability Lower (can crash system) Higher (isolated process)
Best for Low-level hardware, storage, networking Printers, scanners, USB devices

Writing a Basic WDF Driver

If you’re transitioning from WDM to WDF, you’ll notice how much cleaner WDF code is. Let’s write a simple Hello World KMDF driver.

Tools You’ll Need:

  • Windows Driver Kit (WDK) – Required for compiling drivers.
  • Visual Studio – Provides a built-in driver development environment.
  • WinDbg – Debugging tool for kernel-mode drivers.
  • WDF Verifier – Ensures compliance with WDF best practices.

A Simple WDF (KMDF) Driver

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#include <ntddk.h>
#include <wdf.h>

VOID DriverUnload(WDFDRIVER Driver)
{
    KdPrint(("WDF Driver Unloaded!\n"));
}

NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath)
{
    WDF_DRIVER_CONFIG config;
    WDFDRIVER driver;
    
    WDF_DRIVER_CONFIG_INIT(&config, WDF_NO_EVENT_CALLBACK);
    
    NTSTATUS status = WdfDriverCreate(DriverObject, RegistryPath, WDF_NO_OBJECT_ATTRIBUTES, &config, &driver);
    if (!NT_SUCCESS(status)) {
        return status;
    }
    
    KdPrint(("Hello from the WDF driver!\n"));
    return STATUS_SUCCESS;
}

Key Differences from WDM

  • No IRP handling required – WDF handles it for you.
  • Built-in PnP and power management – No need for complex code.
  • Cleaner, modular structure – Easier to maintain.

Installing and Testing a WDF Driver

  1. Build the driver using Visual Studio with the WDK.
  2. Sign the driver – Windows requires kernel drivers to be signed.
  3. Install using pnputil: 
    1

    pnputil -i -a MyDriver.inf
  4. Enable test mode (for unsigned drivers): 
    1

    bcdedit /set testsigning on
  5. Debug with WinDbg:

Best Practices for WDF Development

1. Use KMDF for Kernel Drivers, UMDF for User-Space Drivers

  • Use KMDF if you need low-level hardware access.
  • Use UMDF if security and stability are priorities.

2. Let WDF Handle PnP and Power Management

  • Avoid manually writing IRP_MJ_PNP handlers.
  • Use WDF event callbacks for device state changes.

3. Enable WDF Verifier

  • Run WDF Verifier to catch common issues before deployment.

4. Follow Windows Security Guidelines

  • Sign your drivers – Unsigned drivers won’t load in Windows 10/11.
  • Avoid direct kernel memory access whenever possible.

Common WDF Issues (And Fixes)

1. Driver Doesn’t Load

Fix: Check signature status, enable test signing mode.

2. BSOD on Device Removal

Fix: Ensure proper EvtDeviceReleaseHardware and EvtDeviceD0Exit handlers.

3. System Performance Drops

Fix: Optimize memory usage, avoid excessive kernel calls.

References

  • Microsoft Docs: Windows Driver Framework
  • KMDF vs UMDF
  • Windows Driver Kit (WDK)
  • Debugging WDF Drivers

Источник

What is the Windows Driver Model (WDM)?

Картинка с сайта: cellularnews.com

Unlocking the Mystery of Windows Driver Model (WDM)

Have you ever wondered what makes Windows devices function seamlessly? Behind the scenes, there is a sophisticated system known as the Windows Driver Model (WDM) that ensures the smooth operation of hardware devices on your Windows computer. In this article, we will uncover the secrets of WDM and shed light on its importance in the world of computing.

Key Takeaways:

  • The Windows Driver Model (WDM) is a framework that allows communication between the operating system and hardware devices.
  • WDM provides a consistent interface for device drivers, making it easier for developers to create drivers that are compatible with different Windows versions.

Breaking it Down: What is the Windows Driver Model (WDM)?

The Windows Driver Model (WDM) is a framework developed by Microsoft that facilitates communication between the operating system and hardware devices. It acts as a bridge, enabling the operating system to interact with various hardware components, such as printers, network adapters, USB devices, and more. Essentially, it allows the computer’s software to utilize the capabilities of the hardware.

Here are some key aspects to understand about WDM:

  1. Standardization: WDM provides a standardized interface that device drivers use to communicate with the operating system. With this uniform interface, developers can create drivers that are compatible with different versions of Windows without the need for major modifications. This streamlines the driver development process and ensures device compatibility across Windows platforms.
  2. Plug and Play: WDM supports Plug and Play functionality, allowing the operating system to automatically detect and configure hardware devices as they are connected or disconnected. This means that when you connect a new device to your computer, the operating system can automatically install the necessary drivers and make the device ready for use.
  3. Kernel Mode and User Mode Drivers: WDM distinguishes between kernel mode and user mode drivers. Kernel mode drivers operate at a lower level, directly accessing hardware resources and interacting with the operating system’s kernel. User mode drivers, on the other hand, provide a simpler and more restricted interface, mainly used for applications requiring less direct hardware control.

In essence, the Windows Driver Model (WDM) plays a vital role in ensuring the compatibility and smooth operation of hardware devices on Windows computers. Its standardized interface, support for Plug and Play, and differentiation between kernel mode and user mode drivers make it a crucial component of the Windows operating system.

Conclusion:

Now that you have a better understanding of what the Windows Driver Model (WDM) is, you can appreciate its significance in enabling the seamless connection between your computer’s operating system and hardware devices. The next time you plug in a new device or wonder how your printer magically starts working, remember that it is all thanks to the magic of WDM!

Источник

Windows Driver Model

About the Microsoft Windows Driver Model

The Windows Driver Model (WDM) was introduced to unify driver models across all versions of windows including Windows 98 and Windows 2000 and later.
WDM drivers are IRP (I/O Request Packet) centric, using an in-memory packet structure to represent the I/O request on behalf of the issuing application.
The Windows Driver Model uses a layered driver architecture to allow driver developers the ability to augment functionality of existing device drivers in the system.
The Windows Driver Model exposes power managment and Plug and Play (PnP) interfaces, allowing driver developers to selectively control how their devices consume power, and interact with the rest of the system.
The Kernel Mode Driver Framework encapsulates much of WDM, often making it easier to write WDM drivers. However, a solid understanding of how WDM works is extreamly useful when implementing and especially debugging non-trival windows device drivers.

An excellent book on the Windows Driver Model is Walter Oney’s
Programming the Microsoft Windows Driver Model
book. Though a few years old, much of it is still applicable to todays windows driver developer.

Источник

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Download windows apps torrent
  • C windows mssecsvc exe
  • Windows home server 2009
  • Как перезапустить ноутбук с помощью клавиатуры на windows 10
  • Драйвер обнаружил ошибку контроллера device ide ideport0 windows 10