WDM（Windows Driver Mode）是微軟公司為Windows的驅動程序設計的一種通用的驅動程序模型。相比以前的KDM和VXD來說，他的性能更高、系統之間移植更加方便。所以，隨著系統的升級，WDM已經成為Windows 2000系統下驅動程序開發的主流。作為WDM模型之中一類特殊的驅動程序，過濾器驅動程序（Filter driver）可以在不更改現有驅動程序的情況下，方便地修改、增加現有驅動程序的功能。特別是對于Windows 2000已經提供了通用驅動程序的硬件設備，通過編寫過濾器驅動程序，可以以較小的代價擴展硬件現有的功能。因此具有很強的實際應用價值。

1 Windows 2000 I／O請求處理結構

如圖1所示，Windows 2000是分態的操作系統。用戶應用程序運行在用戶態，操作系統代碼（如系統服務和設備驅動程序）在核心態下運行。用戶態程序只能調用Win32子系統提供的API來同設備交互，當請求傳遞到I／O管理器時，他進行必要的參數匹配和操作安全性檢查，然后由這個請求構造出合適的IRP（IO Request Package，I／O請求包），并把此IRP傳遞到適當的驅動程序去，并給應用程序一個消息，通知這次I／O操作還沒完成。驅動程序一般通過硬件抽象層來和硬件交互，從而完成I／O請求工作。驅動程序完成I／O操作后，他將調用一個特殊的內核服務例程來完成IRP。這時，I／O管理器把數據和結果返回給Win32和用戶應用程序。

2 WDM驅動程序模型體系結構

Windows驅動程序模型重新定義驅動程序分層使用了如圖2的層次結構。圖中左邊是一個設備對象堆棧。設備對象是系統為幫助軟件管理硬件而創建的數據結構。一個物理硬件可以有多個這樣的數據結構。處于堆棧最底層的設備對象稱為物理設備對象PDO（Physical Device Object），代表了設備和總線之間的連接。在設備對象堆棧的中間的對象稱為功能設備對象FDO（Functional Device Object），代表了設備的功能。在FDO的上面和下面還會有一些過濾器設備對象FIDO（Filter Device Object）。位于FDO上面的過濾器設備對象稱為上層過濾器，位于FDO下面（但仍在PDO之上）的過濾器設備對象稱為下層過濾器。

總線驅動程序負責枚舉他的總線，這意味著發現總線上的全部設備和檢測設備何時被添加或刪除并為每個設備創建一個PDO。功能驅動程序知道如何控制設備的主要功能，他分層在總線驅動程序的上面。功能驅動程序創建一個功能設備對象，放在設備棧中。對總線上的所有設備，總線過濾驅動程序被加在總線驅動程序之上；設備過濾驅動程序僅對特定的設備添加。上層的過濾驅動程序在功能驅動程序之上，而下層過濾驅動程序在功能驅動程序之下。這種層次結構可以使I／O請求過程更加明了。I／O管理器發送的IRP，先被送到設備堆棧的上層過濾器驅動程序（FIDO），他可以根據要求決定IRP的處理方式，是沿著設備棧繼續向下傳，或者是做一些額外的處理。依次，每一層驅動程序都可以決定如何處理IRP。高層的驅動程序可以把請求劃分成更簡單的請求并傳遞給下層驅動程序。中間層次的驅動程序進一步處理請求，將一個IRP中的請求劃分為若干個小的請求并傳給下層驅動程序。最后，最低層的驅動程序與硬件打交道。因此一些IRP在到達總線程序之前，在設備棧傳遞過程中可能就被過濾掉了。

3 過濾器驅動程序

過濾驅動程序是一種中間驅動程序，他位于其他的驅動程序層次之間。過濾驅動程序可以監視、攔截和修改IRP流，在不影響其他驅動程序的前提下提供一些附加的功能。他的功能可分為：

（1）利用過濾器驅動程序修改現有功能驅動程序的行為而不必重新編寫功能驅動程序。

（2）上層過濾器驅動程序在功能驅動程序之前看到IRP，可以很方便地為用戶提供額外的特征。還可以修正功能驅動程序或硬件存在的毛病或缺陷。

（3）下層過濾器驅動程序在功能驅動程序要向總線驅動程序發送IRP時看到IRP。可以監視、攔截、修改功能驅動程序要執行的總線操作流，截獲數據，進行必要的數據處理，再將處理過的數據傳遞下去，實現一定的數據處理功能。

（4）下層過濾器驅動程序可以實現驅動程序的總線無關性，使功能驅動程序完全獨立于總線結構而不直接與設備對話。針對不同的總線編寫不同的下層過濾器，每個下層過濾器對應一個總線類型。當功能驅動程序需要與硬件對話時，他只需向相應的下層過濾器驅動程序發送IRP即可。

4 過濾器驅動程序設計

過濾器驅動程序設計與功能驅動程序相似。這里限于篇幅主要討論一下過濾器驅動程序設計中與功能驅動程序相區別的幾個關鍵的技術要點。

4．1 DriverEntry例程

DriverEntry例程是驅動程序的人口點。當I／O管理器裝入驅動程序時，他調用DriverEntry例程用來初始化驅動程序范圍的數據結構和資源，包括輸出該驅動程序的其他人口點，初始化該驅動程序使用的特定對象，并設置驅動程序系統資源。與功能驅動程序相區別的是：他必須為每種類型的IRP都安裝派遣函數，而不僅僅只是其希望處理的IRP。

4．2 AddDevice例程

AddDevice函數的基本職責是創建一個設備對象并把他連接到以物理設備對象PDO為底的設備堆棧中，并負責設備對象初始化。與功能驅動程序相區別的是：過濾驅動程序創建的設備對象可能是2種，一種是不命名的過濾設備對象，過濾器工作時把這個無名的設備對象連接到以物理設備對象PDO為底的設備堆棧中。一種是為了和用戶程序通信而創建的命名的設備對象并不連接到以物理設備對象PDO為底的設備堆棧中。命名可以采用2種方法：第一種方法是采用可顯示的“硬編碼”符號鏈接名，用戶態程序必須把設備名硬編碼到源代碼中；另外一種方法是使用設備接口，每個設備接口是由一個全局惟一標志符GUID標志。設備注冊為一個特定的設備接口就創建了一個符號鏈接。

相關步驟如下：

（1）調用IoCreateDevke創建過濾設備對象，并建立一個私有的設備擴展對象。

（2）寄存一個或多個設備接口，以便應用程序能知道設備的存在。另外，還可以給出設備名并創建符號連接。

（3）初始化設備擴展和設備對象的F1ag成員。

（4）調用IOAttachDevkeToDeviceStack函數把新設備對象放到堆棧上。

具體實現程序如下：

NTSTATUS AddDevice （PDRIVER_OBJECT DriverObject， PDEVICE_OBJECT pdo）

{

PDEVICE_OBJECT fido=NULL；

／／創建沒有設備名的過濾設備對象

NTSTATUS status=IoCreateDevice （DriverObjeot，sizeof （DEVICE-EXTENSION），

NULL，FILE_DEVICE_UNKNOWN，0，FALSE，&fido）；

if（！NT_SUCCESS（status）） return status；

／／初始化設備擴展和設備對象的Flag成員

PDEVICE_EXTENSION pdx = （PDEVICE_EXTENSION）fido-＞DeviceExtension；

pdx-＞DeviceObject=fido；

pdx-＞Pdo=pdo；

pdx-＞eDeviceType =FILTER；

／／把沒有設備名的設備對象放到堆棧上

PDEVICE- OBJECT fdo =

IoAttachDeviceToDeviceStack （fido，pdo）；

pdx-＞TopDevObj=fdo；

fido-＞Flags ︱=pdo-＞F1ags&（DO_DIRECT-IO ︱DO-BUFFERED-IO ︱ DO_POWER_PAGABLE ︱DO_POWER_INRUSH）；

………

／／建立一個命名的設備對象創建符號鏈接

CreateSymbOlicLink （DriverObject，pdo）；

return STATUS_SUCCESS；

}

4．3 派遣例程

派遣例程處理來自應用程序的打開、關閉、讀、寫等I／O請求命令。與功能驅動程序的區別是：過濾器驅動程序不能影響其他驅動程序接受IRP。對于未知的IRP或不處理的IRP過濾驅動程序的原則是必須沿設備棧傳遞下去。因此他必須為每種類型的IRP都安裝派遣函數，而不僅僅只是其希望處理的IRP。對于希望處理的IRP必須指定特殊的派遣函數，直接用CompleteIRP來完成接收到的這類IRP，不往下層傳送。

這里由DispatchDeviceControl處理來自應用程序的所有希望處理的I／O操作命令。通常采用給予所有自定義的I／O請求代碼的SWITCH語句，而對于每個命令使用相應的處理函數。下面列出了主要的代碼框架：

NTSTATUS DispatchDeviceControl （PDEVICE_OBJECT fido，PIRP Irp）

{

NTSTATUS status；

PDEVICE_EXTENSION pdx=（PDEVICE_EXTENSION）fido-＞DeviceExtension；

PlO_STACK_LOCATION IrpStack =

IoGetCurrentlrpStackLocation（1rp）；

／／取I／O控制命令代碼

ULONG IoControlCode = IrpStack 》

Parameters．DeviceloContr01．IoControlCode；

switch（IoControlCode）

{

case IOCTL-XXX：

…… ／／處理I／O控制命令代碼

case IOCTL-XXX：

……

default：

……

break；

}

／／完成接收到的IRP

IoCompleteRequest（Irp，IO_NO_INCREMENT）；

……

return status；

}

對于不需要處理的IRP則交由DispatchAny例程處理，將IRP沿著設備棧直接傳遞下去：

NTSTATUS DispatchAny（PDEVICE_OBJECT fido，PIRP Irp）

{

PDEVICE_ EXTENSION pdx=（PDEVICE-EXTENSION）

fido-＞DeviceExtension

／／使堆棧指針少前進一步。

IoSkipCurrentlrpStackLocation（hp）；

Status=IoCallDriver（pdx-＞LowerDeviceObject，Irp）；

……

return status；

4．4 Unload例程功能

在Unload例程中，驅動程序必須釋放所有創建的對象和所有分配給驅動程序的資源。

5 結 語

筆者就采用在Windows提供的USB聲卡驅動程序下方插入自己編寫的下層過濾器驅動程序實現了對USB聲卡輸出的數據流的截獲并進行語音信號處理，取得了不錯的效果，現已投入實際應用。可見過濾器驅動程序作為一類特殊的驅動程序，它可以以較小的代價實現對驅動數據流的截獲，修改、增加現有驅動常需的功能，具有很強的實用性。

責任編輯：gt