We're offering this seminar in Issaquah, Washington May 8 through 12! Click here for more information.
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 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.
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:
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.
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.