1. Windows Driver Foundation: Introduction Murtuza Naguthanawala Program Manager Networking And Devices Murtuzan @ microsoft.com Microsoft Corporation

2. Session Goals Attendees should leave this session with the following: A better understanding of Windows Driver Foundation (WDF) Know how to use WDF

3. Session Outline Overview Limitations of the current driver models Windows Driver Foundation Model Kernel mode framework User mode framework Static verification tools

4. Windows Driver Model (WDM): Overview Generic Model – WDM Specific driver models – Miniports for popular device classes WDM Features Asynchronous and packet-based IO Layering of drivers Dynamic loading and unloading of drivers Plug and Play Power management Large device coverage Flexible Low-level high-performance interfaces

5. Current Windows Driver Models Device/Driver ClassesCurrent Model Display AdaptersVideo port Storage Adapters (SCSI & ATA)Scsiport, Storport, ATAport, Network AdaptersNDIS Video CaptureAvStream Audio AdaptersAVStream, PortCls File System filtersFS Mini filter PrintersUniDrv Scanners,CamerasWIA PCI, PC Card, generic filter driversWDM Modems, Cable ModemWDM & NDIS WDM Biometric DevicesWDM Smart Card DevicesWDM Keyboard/Mouse FiltersWDM Legacy Devices (Serial, Parallel)WDM Portable Media PlayersWMDM UPnP & Network Connected Devices, Cell Phones No support USB, 1394, Bluetooth, SD devicesWDM (kernel), no support (user) OthersWDM

6. Limitations With Current Driver Models Generic driver model is too complex Poor DDI design Inconsistent miniport models The current approach requires many drivers to use kernel mode User Mode could be an option Does not allow extension and future growth

7. Limitations: Generic Driver Model Lots of hard-to-understand boiler plate code Plug and Play and Power Management (PnP/PM) have complicated state machines Never coherently described and cannot be well expressed in documentation Not easily testable Asynchronous I/O & Cancellation Synchronization Documentation is not adequate End user experience Drivers are the #1 cause of blue screens in the system

8. Limitations: DDI Design DDIs directly exposed by kernel Key OS data structures exposed to drivers Hard to version Even the OS Version Query DDI is OS version dependent! Subtle changes in kernel break drivers e.g., Changing the default pool size Cannot make improvements to the kernel easily Only C is supported

9. Limitations: Inconsistent Driver Models Inconsistent interfaces Hard to transfer expertise from one device class to another Not flexible enough to keep up with HW innovation Device classes appear on multiple buses Duplication of testing and documentation efforts Tools/technologies cannot be leveraged across all models e.g., Driver Verifier, PREfast

10. Limitations: Kernel mode required Not every device needs interrupts, DMA, register access, has strict timing requirements etc. Many USB device drivers could be written in user mode Lower reliability Kernel-mode drivers can crash the system

11. Driver Model Design Goals Consistent set of DDIs DDIs not tied to core OS components Language agnostic Supports verification by static analysis tools Diagnosability Supports driver isolation Bugs in a driver do not bring down system or other driversDDIs classified into two categories Base model: Supports base functionality across all device classes, including PnP, PM, Async I/O, Queues, DMA, hardware access Synchronization, Communication with drivers Device class extension Derives from base model; only adds device specific functionality e.g., Device I/O Control processing

12. Driver Model for Device Class Support Base Model (PnP/PM/IO/Synch) Device Specific Extension (Packet, Device I/O Control, CDB processing) Driver

13. How To Get to Driver Model? Our plan is to get to the driver model goals incrementally Keep supporting existing driver models WDM will continue to be supported Existing mini-port models will continue to be supported Define the basic model Define a consistent way to extend the basic model Ensure that newer device classes use the new approach

14. Windows Driver Foundation

15. Driver Model and Windows Drivers Foundation WDF(PnP/PM/IO/Synch) Device Specific Extension (Packet, Device I/O Control, CDB processing) Driver WDF becomes the base model

16. Windows Driver Foundation- Experience

17. Windows Driver Foundation WDF is the stepping- stone to the ideal driver model WDF Contains A Model Multiple frameworks Kernel Mode Framework User Mode Framework Verification Tools Static Driver Verifier PREfast for Drivers WDF Model Static Driver Verifier User Mode Framework Kernel Mode Framework PREfast

18. Windows Driver Foundation - Goals Simplicity: No harder than it needs to be to accomplish a task Fast time to market for drivers Reduce crashes and blue screens generated by drivers in the system Provide complete driver development experience Driver model UMDF, KMDF Develop,test and qualify Built-in diagnosibility, tracing, verification tools Logo programs for drivers Deployment, Install and Maintain Support versioning

19. Windows Driver Foundation: Model One conceptual model to learn for all (both kernel and user-mode) drivers Model implies Object model, object hierarchies, state machines Does not refer to DDIs, data structures etc. Note that a framework may only implement a subset of the model e.g., User mode framework will not implement support for Interrupts Supports rich and deep functionality (unlike WDM) Intelligent defaulting Allows implementation in many languages (C, C++) Allows verification by static tools Enables driver isolation using user mode driver framework

20. WDF Value Proposition A quicker, cheaper and easier way of developing and deploying your driver to market Reduced chances that device driver is a cause of system crash Reduced support costs Better diagnosability and debugging and logging support Improved system stability and reliability Higher quality drivers Automated discovery of driver bugs via static tools System robustness Better system security User mode tools like Visual Studio can be used for development Better power management Consistent experience across pluggable devices

21. Device Class / Driver ModelKMDFUMDFSDVPFD Modem, CD ROM devices, Keyboard, Mouse YesNoYes SCSI – StorPortNo Yes Display cardsNo Yes Ethernet devicesNo Yes DSL/Cable ModemsYesNo Yes Video Capture devices (Webcams)No Yes Anti-virus filtersNo Yes Digital cameras/portable media players/cell phones/PDAs etc NoYesNoYes PrintersNo Yes ScannersNo Yes WDF Device Support Scope: Longhorn

22. Kernel Mode Driver Framework

23. Previously referred to as “Windows Driver Framework” Implements the model in kernel mode Built as a library on top of WDM Supported from Windows 2000 and forward Beta/Pre-release bits are available today Object based ‘C’ only Supports PNP and Power WMI DMA Requests and Queue IO targets

24. Kernel Mode Driver Framework Status Feature complete e.g. Object Model, PnP/PM, I/O queues etc. Beta bits are available through beta program 22 samples in the kit Installs with Windows Server SP1 DDK Current Windows codenamed “Longhorn” drivers using KMDF Universal audio bus driver WinUSB Monitor function driver Internal MSFT test drivers DDIs are open to refinement based on feedback from the WDF beta program

25. Kernel Mode Driver Framework Proof Points

26. Case Study: PCIDRV Sample MetricWDMWDFComments Line Count131477271Explicit registration of granular event callbacks add to the line count LOC devoted to PnP/PM 79911795Almost 6000 lines of code is eliminated Locks83This is the most important stat. This explains the complexity State variables devoted to PnP/PM 300This explains that there are fewer paths in the driver and thus less testing and complexity This sample is written for the Intel E100B NIC Card. This is a WDM version of a network driver. Both samples are in the DDK and are functionally equivalent.

27. Case Study: Serial Sample MetricWDMWDFComments Line Count2400017000Explicit registration of granular event callbacks add to the line count LOC devoted to PnP/PM50002500 Locks & Synchronization Primitives100This is the most important stat. This explains the complexity State variables devoted to PnP/PM530There are fewer paths in the driver and hence less complexity WDF sample does not support multi-port serial (WDM sample supports it). WDM stats exclude multi-port support serial code

28. Case Study: OSRUSBFX2 Sample MetricWDMWDFComments Line Count163502300Explicit registration of granular event callbacks add to the line count LOC devoted to PnP/PM6700742742 includes code to initialize the USB Locks (6 Events, 3 SpinLocks)90This is the most important stat. This explains the complexity State variables devoted to PnP/PM210There are fewer paths in the driver and hence less complexity The WDM version of OSRUSBFx2 sample available on osronline.com and the WDF version provided in the DDK are functionally equivalent.

29. User Mode Driver Framework

30. Implements the model in user mode Support for: PnP/PM, Asynchronous I/O, layering No support for: Interrupts, DMA, access to hardware registers, client address space etc. Languages C++ Fits within the Windows I/O model Naming, security, discovery APIs remain the same Applications write to Win32 APIs Supports recovery from driver crashes increase system robustness Kernel mode drivers CANNOT be stacked on top of user mode drivers Supported in Longhorn only Down level support to Windows XP being evaluated

31. Kernel Mode/User Mode Feature Comparison FeatureKMDFUMDF PnP/PMYes Async I/OYes Filter supportYes Recovery from failureNoYes LanguagesCC++ Interrupts, DMA etcYesNo Driver InstallationYes When KMDF DMA, Interrupt, requires use of non paged pool, strict timing requirements Access to hardware When UMDF Software drivers, drivers that just need PNP and IO support Devices on protocol bus (USB-based “Hello Kitty device”)

32. User Mode Driver Framework Status WinHEC Development platform is Windows Driver Kit (WDK) Current Windows Team Clients ActiveSync (Windows Mobile devices) MTP (media players, cameras) Aux display Potential device classes Cellular phones Portable media players, Scanners, Cameras Network connected devices Any protocol bus (USB) based devices not related to input, display, storage or networking Devices that need PNP and IO support

33. Verification Tools Verify that drivers follow interface specifications Dynamic Driver Verifier already built in to Windows Static PREfast Verifies rules within the scope of a function Many WDM specific rules (IRQL checking) have been added Static Driver Verifier Uses formal checking technology Examines the entire code path in the driver Currently focused on verifying WDM rules WDF interfaces designed to be easily verified by these tools Works on both Kernel and User mode driver frameworks

34. Summary WDF is the new driver model for driver development It addresses key IHV/OEM concerns Fast time to market, technical support costs, learning curve etc KMDF backward compatible up to Windows 2000 It intends to reduce customer pain points WDF intends to provides a complete driver development experience Aims to reduce OS crashes due to poorly- written drivers WDF targets production of high quality of drivers for Windows

35. Call to Action Work together with us to make WDF successful Consider WDF for any Windows driver development project Join WDF beta program Use the guest account (Guest ID: Guest4WDF) on http://beta.microsoft.com to sign up for beta http://beta.microsoft.com Contact info Email Kmdffdbk @ microsoft.com - Kernel Mode Driver Framework Umdffdbk @ microsoft.com - User Mode Driver Framework Pfdfdbk @ microsoft.com - PREfast for Drivers Sdvfdbk @ microsoft.com - Static Driver Verifier Newsgroups microsoft.beta.windows.driverfoundation microsoft.beta.windows.driverfoundation.announcements Web Resources http://www.microsoft.com/whdc/driver/wdf/default.mspx http://www.microsoft.com/whdc/DevTools/ddk/default.mspx

36. Community Resources Windows Hardware & Driver Central (WHDC) www.microsoft.com/whdc/default.mspx Technical Communities www.microsoft.com/communities/products/default.mspx Non-Microsoft Community Sites www.microsoft.com/communities/related/default.mspx Microsoft Public Newsgroups www.microsoft.com/communities/newsgroups Technical Chats and Webcasts www.microsoft.com/communities/chats/default.mspx www.microsoft.com/webcasts Microsoft Blogs www.microsoft.com/communities/blogs

38. © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.