Writing WDF Drivers I: Core Concepts for Microsoft Students

Writing WDF Drivers I: Core Concepts for Microsoft Students

This seminar is designed for Microsoft engineers who need to understand how to design, develop, and/or test Windows drivers using the Windows Driver Foundation’s (WDF) Kernel Mode Driver Framework (KMDF). While the seminar provides the groundwork and concepts for writing any supported type of WDF driver, its focus is on providing a strong understanding of both the Windows I/O Subsystem and KMDF fundamentals. Using these fundamentals, the seminar provides practical experience developing KMDF software drivers, filter drivers, and drivers for USB and programmed I/O type devices. The basics of writing KMDF client drivers for SoC-type environments and devices (GPIO, I2C, and SPI) are also discussed (though this topic is not covered in detail).

Once students understand the basic Windows and WDF concepts discussed in this seminar, learning the details of how to develop KMDF drivers for other classes of devices and creating drivers using the User Mode Driver Framework (UMDF) should be relatively easy.

This seminar does not discuss how to develop or maintain standard WDM style drivers. If you have any doubts as to whether this seminar is appropriate for your needs, please email v-destit before registering.

Hardware Included A valuable part of your learning experience in this course will be the lab exercises targeted for use with the OSR USB FX2 Learning Kit (check out the OSR Online Store for more information). Of course, we want your learning experience to extend beyond the classroom, so each student will walk away with their very own OSR USB FX2 Learning Kit.

Details

Length: 4 days

Format: Lecture and Lab

Cost and Date: Please see Learning Central for the latest information.

For More Info

Please email OSR’s Manager of Learning Services v-destit /call 603-595-6500 or
Join OSR’s Seminar Update list DEVTRAIN

Target Audience

Engineers who need to understand how to design, develop, and test Windows drivers using the Windows Driver Foundation’s (WDF) Kernel Mode Driver Framework (KMDF).

Important, Please Read: This seminar deals strictly with the WDF Kernel Mode Driver Framework and does not prepare attendees for writing drivers using the Windows Driver Model. This seminar is designed specifically for developers focused on writing drivers for which WDF is applicable. Developers who seek a thorough understanding of the workings of the Windows I/O subsystem, such as in preparation for writing/maintaining a WDM driver or writing a file system or file system filter driver, are strongly urged to attend OSR’s Writing WDM Kernel Drivers for Windows seminar instead of this seminar.

Prerequisites

Students attending this seminar must have a good working knowledge of O/S concepts in general (user mode versus kernel mode, virtual memory concepts, concurrency issues) and Windows O/S architecture concepts in particular. Due to the hands-on orientation of this seminar, attendees will be assumed to be able to use Windows at a user level, including using Visual Studio (VC++). Working knowledge of the C programming language, and how to read and write to a file using Win32 (CreateFile, ReadFile, WriteFile) are also assumed.

Due to the highly compressed nature of this seminar, we will assume students taking this seminar already know how to compile and link a Windows driver using their team’s internal build environment (which is typically Razzle) or that they can easily learn this after they return from taking this class. In class, we use Visual Studio and the Windows Driver Kit (as described in Note on the Lab Environment, below).

We will also assume that students know the basics of installing, connecting, and using WinDbg. While clever students who have never used WinDbg will be able to learn what they need to know “on the fly” during lab sessions, knowing this info prior to the seminar will ensure that students spend their time during the lab sessions focused on learning KMDF, not on mastering the mechanics of the hooking up the debugger.

Note on the Lab Environment

Starting with Windows 8, the build environment that is used by customers to build drivers for Windows (the Windows Driver Kit) differs greatly from the build environment used internally by most groups.  To avoid syncing an enlistment for each student (and in so doing putting confidential information on lab machines) this class will use Visual Studio and the publically available Windows Driver Kit for labs. But don’t worry: Using the public tools for labs won’t restrict what you learn in the class in any way. Everything you learn in lab will be directly transferable to building and debugging driver code in your team’s internal build environment, whether that environment uses Visual Studio and the WDK, Razzle, or something else.

Hardware Requirement

Each student will need to bring a pre-configured and tested laptop with them to the seminar.  This laptop will be used for doing lab assignments.

The hardware and software requirements for this seminar are described on our OSR Seminar Laptop Setup Requirements page.

You’ll note that the class requires VMware for your laptop.  And you’re probably wondering if you can substitute Hyper-V in place of VMWare in class.  The answer to this is “probably not, we don’t recommend it.”  We want to be able to properly support you during your seminar experience, with answers to your questions and assistance with any problems you may discover.  Because we use VMWare for development internally at OSR, it’s the virtualization platform that we fully understand and that we’re confident we can help you with.  If you *really* want to use Hyper-V, you can… but only if all of the following three conditions are true:

1. You have significant, hands-on, experience configuring and using Hyper-V as a kernel debugging target for driver testing.  This includes configuring the Hyper-V guest system as a debug target for WinDbg running on the host system.

2. You will not require any help using, installing, configuring, or managing Hyper-V from the OSR seminar staff during your seminar.

3. You do not want to do be able to try any of the USB-related labs.  Doing these labs requires “assigning” the OSR USB FX2 device we provide you for exclusive use of the VM Guest.  While VMWare supports this feature, Hyper-V does not (at least as far as we can determine).

We have recently notice that Microsoft ITG has enabled Device Guard / Credential Guard by default on domain joined systems, and that students have had mixed-success (sometimes no success) in disabling Hyper-V on these systems. This makes it impossible to use VMware, and thus makes it impossible to do the USB labs.  As a result, we recommend you bring a laptop that is NOT domain joined (a test system, basically) with you to class.

If you have any questions, don’t hesitate to contact OSR’s Seminar Team.

[space size=”10″]DAY ONE

• Introduction
  Welcome remarks, seminar goals and objectives, and a brief introduction to WDF and KMDF.
• Windows Architecture Overview (in brief)
  A brief review of Windows operating system architecture, focused specifically on the details needed by a KMDF driver writer.
• The Windows Device Tree
  A description of how the Windows PnP subsystem discovers and enumerates drivers, on both dynamically enumerable buses such as PCI and USB) and non-dynamically enumerable Simple Peripheral Buses (such as SPI and GPIO). All about Physical Device Objects (PDOs), Function Device Objects (FDOs), and filter devices. How filter drivers work their magic. How requests are processed, and passed from driver to driver within the Windows I/O Subsystem
• Driver Installation Concepts
  A very brief description of installation, specifically focusing on how a driver for a specific device is identified and located given information in the driver installation control (INF) file.

DAY TWO

• The WDF Object Model
  WDF object characteristics and taxonomy. How objects are instantiated and used in KMDF. An overview of the most common WDF objects.
• Driver Initialization
  How to initialize a KMDF driver and its associated device. Also, handling typical PnP and power management events such as device arrival, power-up, and power-down. Types of hardware resources, and when and how these resources are claimed.
• Interrupt Levels & DPCs
  In this module, we discuss the all-important concept of Interrupt Request Levels (IRQLs), and the specific uses that Windows makes of various IRQLs. We also discuss Deferred Procedure Calls (DPCs) and how they’re used in Windows for Interrupt Service Routine completion (DPCforISR). We also discuss passive-level interrupts and its associated Work Item for ISR, used in SoC systems.
• Brief Overview of Building/Debugging
  Students are assumed to already be familiar with the basics of how to use Razzle and how to setup the kernel debugger. We’ll very briefly review these topics and also discuss the WDF Kernel Debugger Extensions (WDFKD), including retrieving the WDF Log from the “in flight recorder.”[space size=”10”]Lab: Building and Debugging, Driver Initialization processing[space size=”10″]

DAY THREE

• Queues and Requests
  In this section, we discuss WDFQUEUEs and WDFREQUESTS. Topics include how Queues are instantiated, Queue dispatch types, and how Queues can be used to sort Requests. We also discuss Framework Requests and how Requests are processed and completed, including how the user data buffer associated with a Request is retrieved from an arbitrary process/thread context.
• Buffer Methods and Device Controls
  In this section, the different ways that requestor data buffers can be described are discussed. Direct I/O, Buffered I/O and “Neither I/O” are described, compared, and contrasted. Also discussed is how to define custom Device IO Control Codes (IOCTLs), and how the previously described buffering methods apply to IOCTLs.
• Case Study 1: Backplane Bus Hardware Devices
  After having covered the basics of all the important driver entry points, we walk through the code for a complete (but simple) driver to see how the various driver parts interrelate. Examples of interacting with programmed I/O type devices using registers and ports.[space size=”10″]Lab: Request Processing and Completion, Filtering[space size=”10″]
• I/O Targets
  Local, Remote, and Special I/O Targets are discussed. How to forward Requests both synchronously and asynchronously to other devices/drivers in the system for processing. Request completion, and completion routines are also discussed.

DAY FOUR

• Case Study 2: SoC Sensor Devices
  How SoC-type devices (such as those on SPI, I2C, and GPIO buses) are supported in Win8. SPBs and the RESOURCE_HUB. Controller drivers and Client drives. Walk-through of the initialization and I/O processing a Client driver that receives interrupts via a GPIO line and collects data from an I2C or SPI bus. And introduction to the Power Management Framework (PoFx), including review of example configurations and callbacks for single-component devices.
• Serialization
  In this module, we discuss issues relating to synchronizing access to shared data within a driver. The much misunderstood topic of KMDF Synchronization Scope is fully described, as is extending sync scope to other callback routines via the Automatic Serialization parameter. WDFSPINLOCKs and WDFWAITLOCKs are discussed, along with the underlying implementations of each and how they’re used.
• Case Study 3: USB Devices
  We start with a discussion of the basic concepts behind USB devices (e.g. device, configuration, interface, and endpoint descriptors). We then discuss the implementation details of writing KMDF drivers and review key sections of an example USB driver.
• Cleanup, Close and Request Cancellation
  Strategies for handling queued and in-progress requests are discussed, as what processing typically takes place as part of cleanup and close processing.
• Miscellaneous Useful Objects[space size=”10″]Lab: USB, Using the OSR USB-FX2 device