DRV203 - Developing Windows Driver Foundation (KMDF and UMDF 2.0) Drivers

This seminar teaches you how to write, package, install, and debug drivers using the Windows Driver Foundation models: Kernel Mode Driver Frameworks (KMDF) and User Mode Driver Frameworks (UMDF 2.0). These are the driver models recommended by Microsoft for all devices for which a more specialized driver model is not available. 

Level: Intermediate

Developers of drivers for devices using KMDF or UMDF 2.0. 


In this seminar you will learn the common principles and interfaces used by all WDF device drivers, and the details of Windows Driver Foundation (WDF). WDF includes both Kernel Mode Driver Frameworks (KMDF) and User Mode Driver Frameworks (UMDF); as of UMDF 2.0 (supported on Windows 8.1 and later), the UMDF and KMDF interfaces are almost identical.

Microsoft now recommends UMDF for all drivers as a first effort, going to KMDF only if performance is not sufficient, or if access to a DMA device on a backplane bus (PCIe) is required. 

We will cover the most common types of drivers: Function drivers for devices on “protocol” buses such as USB; function drivers for devices on “backplane” buses such as PCI-E; and filter drivers for both types of devices. We include complete coverage of driver coding; writing and debugging .INF files; interfacing to the bus driver; I/O request management; driver installation; and debugging.

Although we very clearly distinguish supported interfaces from undocumented information, we do show you a great many "how it really works inside" details of the operating system–details that are not available in the standard documentation. In addition, we cover the relationships between WDF and the Windows Driver Model (WDM) interfaces on which WDF is based. These details help you to learn WDF in terms of an internally consistent set of principles and mechanisms rather than as a set of seemingly arbitrary rules. Where you have choices of design methods for your driver, you will learn the advantages and disadvantages of each. 

  • Key operating system and Windows I/O subsystem principles
  • WDF concepts
  • Introduction to WDF data structures (objects) and interfaces
  • A "starter" UMDF driver
  • Device driver development environment
  • Plug and play basics; .INF files; driver installation; kernel debugging setup
  • Debugging with WDF source
  • Device configuration
  • Handling simple I/O requests
  • Buffer handling (buffered vs. direct I/O)
  • Implementing I/O requests on USB devices
  • Advanced plug-and-play and power management
  • Serialization and synchronization
  • Advanced I/O request queueing; I/O request cancellation
  • Implementing timers and timeouts
  • Backplane buses
  • Interrupts and Deferred Procedure Calls
  • Small system interconnects: GPIO, I2C, and SPI
  • KMDF differences
  • DMA operations with KMDF
  • Debugging a KMDF driver

DRV150, Windows Internals for Driver Developers, or equivalent knowledge and experience: Attendees should understand the basic principles of demand-paged, virtual memory, multitasking operating systems. Attendees must have at least a reading knowledge of the C programming language. Familiarity with device driver development on other platforms will be helpful, but is not essential.

Operating systems supported:

Windows 2000 through Windows 10/Windows Server 2012 R2

Durations and formats: 5 days with labs

This seminar is only offered with hands-on labs.

We will begin with developing a "pseudodevice driver" (sometimes called a "software driver"), then address hardware device access as the progression of the driver permits. Either a simple USB or PCI-E device (depending on customer request) is used as the "target" device for most of the example code and lab problems, but the principles presented here apply to nearly all WDF device drivers. 

Our lab sessions will include:

  1. INF files and "device add" functions: Develop and test an .INF file that will permit loading of a supplied "skeleton" driver against the sample hardware, and then implement the code for the "device add" portion of plug-and-play processing. (At the end of this lab, the sample device should appear in Device Manager with no error indications.)
  2. Simple I/O requests: Add code to support simple I/O requests (DeviceIoControl) that do not touch the I/O hardware and are completed in the first call to the driver. 
  3. Hardware access: Add code to read or write small amounts of data from a device's USB pipe or PCI device register. 
  4. I/O request processing: Add code to initiate an I/O operation on the device, receive either notification of completion (USB) or an interrupt (PCI) when the device signals it, and notify the requesting applicatino of I/O completion.
  5. Advanced I/O request processing: For USB device, access one or more additional pipes. For PCI, implement and test the code to initiate and complete a DMA transfer (sample hardware permitting). 

This sequence follows the usual stages of development for actual driver projects. By the completion of the seminar, students will have developed, installed, and tested a complete (though somewhat simplistic) driver for the sample device.  

At the beginning of each lab period we will supply a complete, commented solution for the previous session; students may use this as a "starter" for the next lab or work progressively on their own code. Solutions will of course be provided for the final problems. 

Note: Public seminars will use only USB devices for labs. For private seminars, please inquire as to arrangements for labs using a PCIe device. 

Additional information:

One of the most exciting developments in Windows driver development is that Microsoft is releasing the source code for WDF! And private symbols to let your debugger match up those source files with the binaries on your system will be in the Microsoft public symbol server. So when you're debugging your driver, you'll be able to see inside the WDF routines. This gives you far better visibility of  reasons for error returns and so on. (For example, instead of  just looking at an "invalid parameter" status return, you'll be able to see each parameter being checked in turn, so you'll know which parameter was the problem.) We have included a short module on accessing and understanding the WDF sources, and we'll use them in the labs throughout the seminar.