Offered as a public seminar in April 2018! Click here.
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.
Developers of function drivers, layered drivers, and pseudodrivers 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.
We will cover the most common types of drivers: Function drivers for devices on “protocol” buses such as USB; and function filter drivers. 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.
(For on-site (private) deliveries, coverage of PCIe devices, or of small-system interconnect buses such as SPI, may be substituted for USB; see the “Additional Information” section below.)
NEW!!! In addition, we have integrated coverage of pseudodrivers, sometimes known as software-only drivers, into this course.
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.
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.
The sequence of lab exercises follows the usual stages of development for actual driver projects: Begin with a “skeleton” driver and an INF file; get the driver to load and complete initialization; and then gradually add functionality. 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.
Windows Source Code
Well, certainly not all of it! But one of the most exciting developments in Windows driver development is that Microsoft released the source code for WDF, along with private symbols to let your debugger match up those source files with the binaries on your system. 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. We have included a short module on accessing and understanding the WDF sources, and we’ll use them in the labs throughout the seminar.
Other Types of Devices
For a private (on-site) seminar the customer may request coverage of other types of devices than USB. These include:
Hardware for labs for such devices must be arranged for by the client.