Windows Driver Foundation: Introduction

Murtuza NaguthanawalaProgram ManagerNetworking And DevicesMurtuzan @ microsoft.comMicrosoft Corporation

Session GoalsSession Goals

Attendees should leave this session with the following:

A better understanding of Windows Driver Foundation (WDF)

Know how to use WDF

Session OutlineSession Outline

Overview

Limitations of the current driver models

Windows Driver FoundationModel

Kernel mode framework

User mode framework

Static verification tools

Windows Driver Model (WDM): OverviewWindows Driver Model (WDM): Overview

Generic Model – WDM

Specific driver models – Miniports for popular device classes

WDM FeaturesAsynchronous 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

Current Windows Driver ModelsCurrent Windows Driver Models

Device/Driver Classes Current ModelDisplay Adapters Video port

Storage Adapters (SCSI & ATA) Scsiport, Storport, ATAport,

Network Adapters NDIS

Video Capture AvStream

Audio Adapters AVStream, PortCls

File System filters FS Mini filter

Printers UniDrv

Scanners,Cameras WIA

PCI, PC Card, generic filter drivers WDM

Modems, Cable Modem WDM & NDIS WDM

Biometric Devices WDM

Smart Card Devices WDM

Keyboard/Mouse Filters WDM

Legacy Devices (Serial, Parallel) WDM

Portable Media Players WMDM

UPnP & Network Connected Devices, Cell Phones

No support

USB, 1394, Bluetooth, SD devices WDM (kernel), no support (user)

Others WDM

Limitations With Current Driver ModelsLimitations 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

Limitations: Generic Driver ModelLimitations: 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 experienceDrivers are the #1 cause of blue screens in the system

Limitations: DDI DesignLimitations: DDI Design

DDIs directly exposed by kernelKey OS data structures exposed to drivers

Hard to versionEven the OS Version Query DDI is OSversion dependent!

Subtle changes in kernel break driverse.g., Changing the default pool size

Cannot make improvements to the kernel easily

Only C is supported

Limitations: Inconsistent Driver ModelsLimitations: 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

Limitations: Kernel mode requiredLimitations: 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 reliabilityKernel-mode drivers can crash the system

Driver Model Design GoalsDriver 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

Driver Model for Device Class SupportDriver Model for Device Class Support

Base ModelBase Model(PnP/PM/IO/Synch)(PnP/PM/IO/Synch)

Device Specific Device Specific Extension (Packet, Extension (Packet, Device I/O Control, Device I/O Control,

CDB processing)CDB processing)

DriverDriver

How To Get to Driver Model?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

Windows Driver Foundation

Driver Model and Windows Drivers Driver Model and Windows Drivers FoundationFoundation

WDFWDF(PnP/PM/IO/Synch)(PnP/PM/IO/Synch)

Device Specific Device Specific Extension (Packet, Extension (Packet, Device I/O Control, Device I/O Control,

CDB processing)CDB processing)

DriverDriver

WDF becomes the base model

Windows Driver Foundation- ExperienceWindows Driver Foundation- Experience

Windows Driver FoundationWindows Driver Foundation

WDF is the stepping-stone to the ideal driver model

WDF ContainsA Model

Multiple frameworksKernel Mode Framework

User Mode Framework

Verification ToolsStatic Driver Verifier

PREfast for Drivers

PREfast

KernelMode

Framework

User ModeFramework

Static Driver

Verifier

WDFModel

Windows Driver Foundation - Goals 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 experienceDriver model

UMDF, KMDF

Develop,test and qualifyBuilt-in diagnosibility, tracing, verification tools

Logo programs for drivers

Deployment, Install and MaintainSupport versioning

Windows Driver Foundation: ModelWindows Driver Foundation: Model

One conceptual model to learn for all (both kernel and user-mode) drivers

Model impliesObject 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

WDF Value PropositionWDF 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 costsBetter 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

Device Class / Driver Model KMDF UMDF SDV PFD

Modem, CD ROM devices, Keyboard, Mouse Yes No Yes Yes

SCSI – StorPort No No No Yes

Display cards No No No Yes

Ethernet devices No No No Yes

DSL/Cable Modems Yes No No Yes

Video Capture devices (Webcams) No No No Yes

Anti-virus filters No No Yes Yes

Digital cameras/portable media players/cell phones/PDAs etc No Yes No Yes

Printers No No No Yes

Scanners No No No Yes

WDF Device Support Scope: LonghornWDF Device Support Scope: Longhorn

Kernel Mode Driver Framework

Kernel Mode Driver FrameworkKernel Mode Driver Framework

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

SupportsPNP and Power

WMI

DMA

Requests and Queue

IO targets

Kernel Mode Driver Framework StatusKernel Mode Driver Framework Status

Feature completee.g. Object Model, PnP/PM, I/O queues etc.

Beta bits are available through beta program22 samples in the kitInstalls with Windows Server SP1 DDK

Current Windows codenamed “Longhorn” drivers using KMDF

Universal audio bus driverWinUSBMonitor function driverInternal MSFT test drivers

DDIs are open to refinement based on feedback from the WDF beta program

Kernel Mode Driver Framework Proof Points

Case Study: PCIDRV SampleCase Study: PCIDRV Sample

Metric WDM WDF Comments

Line Count 13147 7271 Explicit registration of granular event callbacks add to the line count

LOC devoted to PnP/PM

7991 1795 Almost 6000 lines of code is eliminated

Locks 8 3 This is the most important stat. This explains the complexity

State variables devoted to PnP/PM

30 0 This 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.

Case Study: Serial SampleCase Study: Serial Sample

Metric WDM WDF Comments

Line Count 24000 17000 Explicit registration of granular event callbacks add to the line count

LOC devoted to PnP/PM 5000 2500

Locks & Synchronization Primitives 10 0 This is the most important stat. This explains the complexity

State variables devoted to PnP/PM 53 0 There 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

Case Study: OSRUSBFX2 SampleCase Study: OSRUSBFX2 Sample

Metric WDM WDF Comments

Line Count 16350 2300 Explicit registration of granular event callbacks add to the line count

LOC devoted to PnP/PM 6700 742 742 includes code to initialize the USB

Locks (6 Events, 3 SpinLocks) 9 0 This is the most important stat. This explains the complexity

State variables devoted to PnP/PM 21 0 There 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.

User Mode Driver Framework

User Mode Driver FrameworkUser Mode Driver Framework

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 modelNaming, 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 onlyDown level support to Windows XP being evaluated

Kernel Mode/User Mode Feature Kernel Mode/User Mode Feature ComparisonComparison

Feature KMDF UMDF

PnP/PM Yes Yes

Async I/O Yes Yes

Filter support Yes Yes

Recovery from failure No Yes

Languages C C++

Interrupts, DMA etc Yes No

Driver Installation Yes Yes

When KMDFDMA, Interrupt, requires use of non paged pool, strict timing requirements

Access to hardware

When UMDFSoftware drivers, drivers that just need PNP and IO support

Devices on protocol bus (USB-based “Hello Kitty device”)

User Mode Driver Framework StatusUser Mode Driver Framework Status

WinHECDevelopment platform is Windows Driver Kit (WDK)

Current Windows Team ClientsActiveSync (Windows Mobile devices)

MTP (media players, cameras)

Aux display

Potential device classesCellular 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

Verification ToolsVerification Tools

Verify that drivers follow interface specifications

DynamicDriver 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 VerifierUses 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

SummarySummary

WDF is the new driver model for driver development

It addresses key IHV/OEM concernsFast 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

Call to ActionCall to Action

Work together with us to make WDF successfulConsider WDF for any Windows driver development projectJoin WDF beta program

Use the guest account (Guest ID: Guest4WDF) on http://beta.microsoft.com to sign up for beta

Contact infoEmail

Kmdffdbk @ microsoft.com - Kernel Mode Driver FrameworkUmdffdbk @ microsoft.com - User Mode Driver FrameworkPfdfdbk @ microsoft.com - PREfast for DriversSdvfdbk @ microsoft.com - Static Driver Verifier

Newsgroupsmicrosoft.beta.windows.driverfoundationmicrosoft.beta.windows.driverfoundation.announcements

Web Resourceshttp://www.microsoft.com/whdc/driver/wdf/default.mspx

http://www.microsoft.com/whdc/DevTools/ddk/default.mspx 

Community ResourcesCommunity Resources

Windows Hardware & Driver Central (WHDC)www.microsoft.com/whdc/default.mspx

Technical Communitieswww.microsoft.com/communities/products/default.mspx

Non-Microsoft Community Siteswww.microsoft.com/communities/related/default.mspx

Microsoft Public Newsgroupswww.microsoft.com/communities/newsgroups

Technical Chats and Webcastswww.microsoft.com/communities/chats/default.mspx

www.microsoft.com/webcasts

Microsoft Blogswww.microsoft.com/communities/blogs

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