解讀Windows 2000/XP分層驅動模型
           
   可擴展性是Windows NT/2000/XP設計的目標之一，其分層驅動模型是可擴展性的最好體現。實現分層依賴于IO管理器的兩個重要的設計：1、Windows中的任何一個驅動程序都被設計成Client/Server模式。對于客戶端驅動，通過IoGetDeviceObjectPointer之類的獲取服務端驅動導出的Device對象，通過IO管理器的IoCallDriver請求服務端的服務。IoCallDriver實際上根據客戶端的調用參數(通過IRP)調用服務端的派遣入口(回調函數)接受客戶端的請求。2、IO管理器實現一個分層的數據結構，在DEVICE_OBJECT對象中保存某種關系，自動將請求IRP發給設備棧中的最高的一個設備，由其決定如何處理，或是自身處理，或是向下傳遞，達到分層的目的。鑒于這種能力，分層驅動模型可以實現很多應用，如文件監控，加密，防病毒等等，由于PNP的引入，這種應用將更加廣泛。實際上這種分層模型在Windows NT/2000/XP中無處不在，不信的話，請執行如下命令看看：

   findstr /M IoAttachDevice %SYSTEMROOT%\system32\drivers\*.sys

   所有列出的Driver幾乎都可以看作分層驅動的例子。對于分層驅動的介紹幾乎充斥著所有介紹Windows驅動的任何一本書中。本文不想過多于重復這些內容，旨在從底層數據結構的實現上說明這種分層的實現。我們首先從DEVICE_OBJECT開始說明。下面是這個結構的部分定義：

   typedef struct DECLSPEC_ALIGN(MEMORY_ALLOCATION_ALIGNMENT) _DEVICE_OBJECT {
          .
          .
          .
       struct _DRIVER_OBJECT *DriverObject;
       struct _DEVICE_OBJECT *NextDevice;
       struct _DEVICE_OBJECT *AttachedDevice;
          .
          .
          .
       PVOID DeviceExtension;
          .
          .
          .
       CCHAR StackSize;
          .
          .
          .
       struct _DEVOBJ_EXTENSION  *DeviceObjectExtension;
          .
          .
          .
   } DEVICE_OBJECT;

   成員DriverObject是DeviceObject對應的DRIVER_OBJECT，通過這個對象，IO管理器可以知道如何為這個設備提供服務(通過調用DriverObject提供的Dispatch入口)。通常一個DRIVER_OBJECT可以為一至多個DEVICE_OBJECT提供服務，各個DEVICE服務不同的同一類型的物理或邏輯設備。她們也有可能扮演不同的角色，如對于PNP引入的PDO與FDO，下面我會詳細介紹。正因為這樣NextDevice成員即用于鏈接這些DEVICE_OBJECT。所以可以得到這樣的結論，像前一句所描述的，對于同一個Driver導出的PDO與FDO則通過NextDevice成員邏輯上建立關系。而對于AttachedDevice成員對于Legacy的Driver(Windows NT 4.0之前，在之后的版本中也可以正常使用)，主要通過這一字段來實現本文開頭提到的IO管理器提供的第二項功能。如下示意圖所示，AttacheDevice1附加至Device1之上， 這種情況下AttachDevice1與Device1通常不是由同一個Driver服務的，即他們沒有通過NextDevice成員鏈接在一起的，這樣我們可以通過書寫另一個Driver，通過附加一個Device至一個已存在的設備上改變或監視這個設備的行為。當然這時候Device1的AttachedDevice成員即指向AttachDevice1。而AttachedDevice1并沒有被任何設備附接過，所以其AttachedDevice成員指向NULL。通過調用IoCallDriver請求Device1服務時，IO管理器內部會調用IoGetAttachedDevice之類的，獲得附接在Device1之上的最高層設備。這里是AttachedDevice1，而對于Device2，即是AttachedDevice3，如果沒有附接任何設備，當然就是Device1了。這樣我們附接的設備就有機會執行相應的操作了。另外對于下圖Device1與Device2的情況，很明顯，Device1位于Device2之上，而這時就是我們開頭介紹的第一種情況，Device1通過IoCallDriver請求Device2，邏輯上建立一種關系(我們不能通過任何數據結構標識這種關系，通常這是驅動開發人員設計成的邏輯關系，對于Windows 2000/XP上如何知道這種關系，當然最好的出入就是DDK文檔了)。


   |-------------|____AttachDevice1
   |   Device1   |
   |-------------|


                                      ------AttachDevice3
   |-------------|____AttachDevice2---|
   |   Device2   |
   |-------------|


   DeviceExtension成員通常是驅動開發人員自已定義的結構，其存儲設備相關的內容，例如用于區別PDO與FDO等等。在調用IoCreateDevice時指定其大小，IO管理器分配sizeof(DEVICE_OBJECT)+DeviceExtensionSize的非分頁內存用于設備對象，這樣這兩個結構在物理上是連續的，所以我們在一些文件系統驅動程序中經常看過VOLUME_DEVICE_OBJECT這樣的定義(緊隨標準的DEVICE_OBJECT后即是專用的用于VOLUME的定義，避免在Dispatch入口每次都要引用這個成員)。

   StackSize指當前設備棧的設備個數(AttachedDevice個數加上設備本身)，用于IO管理器分配IRP時指定STACK_LOCATION個數。

   上面的所有敘述即構成了Windows NT 4.0之前的Windows分層驅動模型。這也是遺留的(Legacy)的分層驅動程序的主要工作思路。AttachedDevice指出了Attached了的設備，Microsoft在Windows 2000中的DeviceObjectExtension結構成員中引入了一個AttachedTo指出被當前設備Attached的低層設備，這在Windows NT是沒有實現的。DeviceObjectExtension是一個很重要的結構，下面要介紹的支持pnp的WDM驅動的AddDevice入口也在這兒。她是由系統定義的結構(區別于DeviceExtension)。對于DRIVER_OBJECT也有個類似的稱為DriverExtenion的結構，后者有一個ClientDriverExtension結構，由IoAllocateDriverObjectExtension分配，IoGetDriverObjectExtension獲得。classpnp.sys即是通過這一方法，實現對disk.sys、tape.sys與cdrom.sys的管理；NDIS.SYS也通過這一方法實現各個Miniport/IM/Protocol Driver的管理。

    Windows 2000及其以后的NT系列引入了WDM，支持PNP、Power管理及WMI，為了讓操作系統本身就對此支持，ntoskrnl.exe中導出了幾個置有DRVO_BUILTIN_DRIVER(ntddk.h中定義)標志的Driver，分別為pnpmanager、WMIxWDM及ACPI_HAL，后者是支持ACPI的HAL(這是在我Windows XP Professional臺式機上的情況，不知道不支持ACPI的機子啥模樣，我的機子上ntoskrnl.exe還導出\FileSystem\Raw驅動用于文件系統的支持，我想這幾個設備名可能會隨機器配置及Windows版本不同而不同，實際上我在我Windows 2000 Server SP0筆記本上ntoskrnl.exe生成如下四個設備:Pnpmanager，PCI_HAL，WDM與RAW，我底下的敘述都是基本我臺式機上的，至于出現的一些不同我可能會另外指出，也有可能沒有)，前兩個driver都是為了支持WDM而引入的。WMIxWDM導出WMIDataDevice用作WMI的支持，這與本文討論分層驅動沒有關系，以下我重點介紹Pnpmanager。

    在介紹之前，我們來看一下devmgmt.msc“依連接排序設備”視圖：

    TSU00(機器名，由pnpmanager實現的虛擬Root總線枚舉)
        |
        |+ Advanced Configuration and Power Interface(ACPI) PC(ntoskrnl中的ACPI_HAL驅動實現)
             |
             |+Micrsoft ACPI-Compliant System(由acpi.sys枚舉)
                   |
                   |+PCI bus(由pci.sys實現)
                        |
                        |+(連接的設備)

   這是我機子上的情況，pnpmanager是一個總線驅動程序(在ntoskrnl.exe內部實現，如果你有checked build的ntoskrnl.exe，你可以很容易的發現其由base\ntos\io\pnpmgr\pnpdd.c實現，看過Sysinternals導出的Windows XP Source Tree了嗎？)，她實現一個稱為Root的虛擬總線。所有Legacy設備，都是連接至這個虛擬的總線上的，不信的話，你在devmgmt.msc的上面列出的草圖上繼續選“顯示隱藏的設備看看”。從這種意義上看她要為每一個連接到她上面的設備建立一個PDO。對于這些PDO通常是以00000001開始的十六進制命名，如在我機子我實驗某一時刻設備名一直至00000050，共80個PDO(在我的Windows 2000 Server的機子上并不是這樣命名的，雖然也是基于十六進制的，但卻是從挺大的一個數值開始的)。我非常喜歡隨Windows XP DDK一些發行的OSR的DeviceTree，但為了更好的理解，還是以windbg作個實驗吧：

   找出上面草圖ACPI_HAL附接的由pnpmanager實現的PDO，通常這是pnpmanager實現的第一個PDO，即命名為00000001(如果你的Pnpmanager生成的設備不是這樣命名的，請使用!drvobj pnpmanager找出生成的對應的PDO，我的Windows 2000 Server SP0的筆記本上，pnpmanager的第一個PDO用于服務ESS聲卡，而并不是我原以為的PCI_HAL，你可能另需要使用!devstack或是下面要介紹的!devnoe命令，方法不詳述)：

   kd> !object \Device\00000001