"Developing Drivers with Windows Driver Foundation" 简介
Updated: April 7, 2008
前言
Nar Ganapathy，架构师，Windows Division：
拥有 Microsoft® Windows® 的核心内核组件的一个特权（和烦恼）就是要分析在组件中出现的大量操作系统故障。作为 I/O 管理器的拥有者，我有机会调试许多与驱动程序有关的问题。我从这些故障中学到了不少东西。当我调试故障转储时，模式就开始形成了。
为了全面理解问题，我认为我需要更好地理解各种设备堆栈（例如存储、音频和显示）和互连（例如 USB 和 1394）。所以我与 Windows Division 的设备团队的开发主管们一起启动了驱动程序堆栈审核（Driver Stack Reviews）计划。经过大量审核，我们得出的结论是，我们的底层驱动程序模型太复杂了。我们没有正确的抽象，而且给驱动程序开发人员的负担太重。
Windows Driver Model (WDM) 经历了 14 年的发展，现在已显得落伍。尽管 WDM 非常灵活，并且可以支持很多不同设备，但是它的抽象相当低级。它是为少数对 Windows 内核有着深刻理解的开发人员或能够接触内核开发人员的人构建的。它不是为广大的驱动程序开发人员构建的，这样的开发人员现在已经有成千上万。
太多的规则难以理解，而且很难描述清楚。基本的操作系统更改（如即插即用和电源管理）没有与 Windows I/O 子系统很好地集成，这主要是因为我们想要并行地运行即插即用和非即插即用驱动程序。这意味着操作系统设计将即插即用和电源事件与 I/O 请求同步的重担推给了驱动程序。同步规则非常复杂、难以理解，而且没有很好地归档。此外，大多数驱动程序不能正确处理异步 I/O 和 I/O 取消，尽管异步 I/O 和可取消的 I/O 从一开始就被设计到操作系统中。
虽然这些结论似乎是很显然的，我们需要针对外部数据对它们进行验证。Microsoft Windows XP 包含一个名为 Windows 错误报告 (WER) 的重要功能，它允许在线故障分析 (OCA)。当 Windows 意外停止并在蓝屏上显示错误信息时，系统创建一个微型故障转储文件，当用户选择将故障数据发送到 Microsoft 时，我们就会收到这个文件。当我们看到大量故障时，我们知道我们必须对驱动程序的开发方法进行一些基本更改。
我们还进行了一项调查并与第三方驱动程序开发人员进行了面对面的对话，以验证我们的发现并提出简化驱动程序模型的建议。这些讨论令人大开眼界。大多数驱动程序开发人员都发现我们的驱动程序模型（尤其是与即插即用、电源管理和取消异步请求相关的组件）非常复杂且难以使用。开发人员非常赞成开发一个更简单的驱动程序模型。此外，他们添加了一些我们未曾考虑到的要求。
首先，更简单的驱动程序模型必须解决在大量操作系统平台上发布的问题。硬件开发商希望编写并维护一个适合于大量操作系统版本的驱动程序。只在最新的 Windows 版本上运行的新的驱动程序模型是不能够接受的。
其次，驱动程序开发人员不能仅限于使用一小部分 API - 我们曾在一些设备类特定的驱动程序模型中采用过这种方法。他们必须能够脱离驱动程序模型进入底层平台。
基于这个出发点，我们开始了 Windows Driver Foundation (WDF) 的开发工作。我们的目标是构建一个满足所有设备类的需求的新一代驱动程序模型。
对于 WDF，我们使用不同的开发方法：从进行设计审核开始，我们就邀请了外部驱动程序开发人员参与设计。刚刚制定了规范，我们就邀请一些开发人员进行讨论 - 第一次是在 2002 年 11 月，所以我们在开始写代码之前就获得了有价值的意见。我们建立了一个电子邮件地址和讨论组，并在其中针对设计进行辩论。一些内部和外部的早期采用者使用我们的框架编写了驱动程序并为我们提供了重要反馈。我们还在 WinHEC 上和通过驱动程序开发人员新闻组寻求和接收反馈。
WDF 经过多次反复研究才发展成现在的样子。根据我们在开发过程中获得的反馈，我们重新开发了即插即用和电源管理实现，以及我们的同步逻辑。具体来讲，我们将即插即用和电源管理重新设计为使用状态机。这有助于使操作明确化，从而很容易理解 I/O 与即插即用之间的关系。随着更多 WDF 驱动程序的开发，我们发现了更多与即插即用和电源管理有关的规则并把它们合并到了状态机中。使用 WDF 的重要好处之一就是，每个驱动程序能够自动获得经过严格测试、设计精良的即插即用和电源管理实现的一个副本。
OCA 数据还表明，我们应该使用另一种更基本的方式来解决故障问题。OCA 数据显示 85% 的意外系统停止是由驱动程序引起的，而不是由 Windows 核心组件引起的。分析显示许多设备类（比如 USB、蓝牙和 1394 互连）的驱动程序不需要进入内核模式。将驱动程序移到用户模式有许多优点。例如，用户模式驱动程序故障可以完全隔离，系统无需重新启动就能恢复。用户模式下的编程环境比内核模式下的编程环境要简单得多。开发人员可以使用许多工具和丰富的语言来编写代码。调试也更加简单。WDF 的一个重大进步在于，我们在用户模式和内核模式下提供了相同的驱动程序模型。
尽管驱动程序模型简化解决了引起系统故障的许多问题，但是不能解决缓冲区溢出、不恰当地使用系统例程等编程人员错误，例如多次完成一个请求、未初始化变量等等。 Microsoft Research (MSR) 在静态分析工具方面的工作解决了这一难题。MSR 已经开发除了能理解驱动程序模型规则并能真正分析源代码的工具原型。我们决定把两种构思转换为工具，并加入到 WDF 中：静态驱动程序验证工具 (Static Driver Verifier，SDV) 和 PREfast for Drivers (PFD)。
随着 Windows Vista™ 的发布，驱动程序开发人员可以在 Windows 驱动程序工具包 (WDK) 中使用 WDF 第一版和我们的静态工具。WDF 和静态工具为我们的驱动程序开发平台奠定了良好的基础。Windows Vista 的初始版本包括 17 个 KMDF 驱动程序，涵盖了多种设备类。在用户模式中，Microsoft Windows Sideshow™ 和 Windows Portable Media 技术都支持 UMDF 驱动程序。Microsoft 将继续在此基础上满足当前和未来的设备类需求。
本书汇总了 WDF 框架和静态工具的基本要点，第一次将有关 WDF 的所有信息集合到一起。本书将帮助任何驱动程序开发人员（甚至初学者）快速掌握 WDF。您将会发现 WDF 能够开发出更高质量的驱动程序，而所用的时间比早期的驱动程序模型要少得多。
大纲："Developing Drivers with Windows Driver Foundation"
第 1 部分：WDF 入门
1 WDF 简介
2 Windows Driver Foundation
3 WDF 基础
第 2 部分：探索框架
4 驱动程序框架概述
5 WDF 对象模型
6 驱动程序结构和初始化
第 3 部分：应用 WDF 基础
7 即插即用和电源管理
8 I/O 流和调度
9 I/O 目标
10 同步
11 驱动程序跟踪和诊断
12 WDF 支持对象
13 UMDF 驱动程序模板
第 4 部分：深入研究：关于 WDF 驱动程序的更多主题
14 框架之外
15 调度、线程上下文和 IRQL
16 硬件资源和中断
17 直接内存访问
18 COM 简介
第 5 部分：构建、安装和测试 WDF 驱动程序
19 如何构建 WDF 驱动程序
20 如何安装 WDF 驱动程序
21 WDF 驱动程序测试工具
22 如何调试 WDF 驱动程序
23 PREfast for Drivers
24 静态驱动程序验证工具
术语表
