---

     7.6.3 Driver Loading, Initialization, and Installation(2)
     http://book.51cto.com 2009-10-30 08:56 Mark Russinovich/David A.
     Solomon/Alex Ionescu人民郵電出版社我要評論( 0 )
     摘要：近20年來，無論是開發人員還是系統管理員，如果想探究Windows核
     心部件的運作機理或者各種技術細節，都會求助於這部毋庸置疑的權威著作
     。

     《深入解析Windows操作系統(第5版英文版)》書中深入透徹地闡述了Window
     s底層的方方面面，包括系統架構，各種系統機制和管理機制，進程、線程
     和作業，安全，I/O系統，存儲管理、內存管理和緩存管理，文件系統，聯
     網，啟動與停機，崩潰轉儲分析等內容，使Windows的內幕在你面前變得一
     目了然。 本節選自第七章的內容。

     標籤： 《深入解析Windows操作系統(第5版英文版)》 操作系統 Windows
     Driver
     Oracle?????????????????
     EXPERIMENT: Dumping the Device Tree
     
     A more detailed way to view the device tree than using Device
     Manager is to use the !devnode kernel debugger command. Specifying
     0 1 as command options dumps the internal device tree devnode
     structures, indenting entries to show their hierarchical
     relationships, as shown here:
     
       lkd> !devnode 0 1  
       Dumping IopRootDeviceNode (= 0x85161 a 98 )
       DevNode 0x85161 a 98 for PDO 0x84 d 10390
      InstancePath is "HTREE\ROOT\0"
       State = DeviceNodeStarted ( 0x308 )
       Previous State = DeviceNodeEnumerateCompletion ( 0x30 d)
       DevNode 0x8515 bea 8 for PDO 0x8515 b 030
       DevNode 0x8515 c 698 for PDO 0x8515 c 820
       InstancePath is "Root\ACPI_HAL\0000"
       State = DeviceNodeStarted ( 0x308 )
       Previous State = DeviceNodeEnumerateCompletion ( 0x30 d)

      DevNode 0x84 d 1c5 b 0 for PDO 0x84 d 1c738
       InstancePath is "ACPI_HAL\PNP0C08\0"
       ServiceName is "ACPI"
       State = DeviceNodeStarted ( 0x308 )
       Previous State = DeviceNodeEnumerateCompletion ( 0x30 d)
       DevNode 0x85 ebf 1b0 for PDO 0x85 ec 0210
       InstancePath is "ACPI\GenuineIntel_-_x86_Family_6_Model_15\_0"
       ServiceName is “intelppm”
       State = DeviceNodeStarted ( 0x308 )
       Previous State = DeviceNodeEnumerateCompletion ( 0x30 d)

      DevNode 0x85 ed 6970 for PDO 0x8515 e 618
       InstancePath is "ACPI\GenuineIntel_-_x86_Family_6_Model_15\_1"
       ServiceName is "intelppm"
       State = DeviceNodeStarted ( 0x308 )
       Previous State = DeviceNodeEnumerateCompletion ( 0x30 d)
       DevNode 0x85 ed 75c8 for PDO 0x85 ed 79e8
       InstancePath is "ACPI\ThermalZone\THM_"
       State = DeviceNodeStarted ( 0x308 )
       Previous State = DeviceNodeEnumerateCompletion ( 0x30 d)

      DevNode 0x85 ed 6 cd 8 for PDO 0x85 ed 6858
       InstancePath is "ACPI\pnp0c14\0"
       ServiceName is "WmiAcpi"
       State = DeviceNodeStarted ( 0x308 )
       Previous State = DeviceNodeEnumerateCompletion ( 0x30 d)
       DevNode 0x85 ed 7008 for PDO 0x85 ed 6730
       InstancePath is "ACPI\ACPI0003\2&daba3ff&2"
       ServiceName is "CmBatt"
       State = DeviceNodeStarted ( 0x308 )
      Previous State = DeviceNodeEnumerateCompletion ( 0x30 d)

       DevNode 0x85 ed 7e60 for PDO 0x84 d 2e030
       InstancePath is "ACPI\PNP0C0A\1"
       ServiceName is "CmBatt"
       §

     Information shown for each devnode includes the InstancePath,
     which is the name of the device's enumeration registry key stored
     under HKLM\SYSTEM\CurrentControlSet\Enum, and the ServiceName,
     which corresponds to the device's driver registry key under
     HKLM\SYSTEM\CurrentControlSet\Services. To see the resources, such
     as interrupts, ports, and memory, assigned to each devnode,
     specify 0 3 as the command options for the !devnode command.
     
     A record of all the devices detected since the system was
     installed is recorded under the HKLM\SYSTEM\CurrentControlSet\Enum
     registry key. Subkeys are in the form \ \ , where the enumerator
     is a bus driver, the device ID is a unique identifier for a type
     of device, and the instance ID uniquely identifies different
     instances of the same hardware.
     
     Devnodes
     
     Figure 7-39 shows that a devnode is made up of at least two, and
     sometimes more, device objects:
     
     ■ A physical device object (PDO) that the PnP manager instructs a
     bus driver to create when the bus driver reports the presence of a
     device on its bus during enumeration. The PDO represents the
     physical interface to the device.
     
     ■ One or more optional filter device objects (FiDOs) that layer
     between the PDO and the FDO (described next), and that are created
     by bus filter drivers.
     
     ■ One or more optional FiDOs that layer between the PDO and the
     FDO (and that layer above any FiDOs created by bus filter drivers)
     that are created by lower-level filter drivers.
     
     ■ A functional device object (FDO) that is created by the driver,
     which is called a function driver, that the PnP manager loads to
     manage a detected device. An FDO represents the logical interface
     to a device. A function driver can also act as a bus driver if
     devices are attached to the device represented by the FDO. The
     function driver often creates an interface (described earlier) to
     the FDO's corresponding PDO so that applications and other drivers
     can open the device and interact with it. Sometimes function
     drivers are divided into a separate class/port driver and miniport
     driver that work together to manage I/O for the FDO.
     
     ■ One or more optional FiDOs that layer above the FDO and that
     are created by upperlevel filter drivers.
     
     
     
     Devnodes are built from the bottom up and rely on the I/O
     manager's layering functionality, so IRPs flow from the top of a
     devnode toward the bottom. However, any level in the devnode can
     choose to complete an IRP. For example, the function driver can
     handle a read request without passing the IRP to the bus driver.
     Only when the function driver requires the help of a bus driver to
     perform bus-specific processing does the IRP flow all the way to
     the bottom and then into the devnode containing the bus driver.
     
     【責任編輯： 王苑 TEL：（010）68476606】

--
※ 編輯: ott 時間: 2011-05-16 14:19:33