As explicitly stated on ReactOS, the PNP Manager creates a virtual root device for each device to build the device tree, and the newly created root device acts as the bottom of a stack of devices, creating a complete device stack. When debugging with WinDbg, you can see that this virtual device belongs to the/driver/pnpmanager driver.
Yesterday out of curiosity to see the device tree, the results found that only the virtual device attach on/driver/pnpmanger created devices, and similar to the PCI/USB device stack bottom is not/driver/pnpmanager device, which makes me very skeptical, m$ How to form the root node of the device tree.
If Mssmbios.sys is located under the Device Manager System device class, the registry path is: hkey_local_machine\system\currentcontrolset\enum\root\system\0002
Using WinDbg to view the device stack, you can see that the device attach on the/driver/pnpmanger root node:
Kd>!drvobj Mssmbiosdriver Object (81F81DA0) is for: \driver\mssmbiosdriver Extension List: (ID, addr) Device object Li st:81c8e408 kd>!devstack 81c8e408 ! Devobj ! Drvobj ! Devext objectname> 81c8e408 \driver\mssmbios 81c8e4c0 821e73d0 \driver\pnpmanager 821e7488 00000034! Devnode 821e7288: deviceinst is "root\system\0002" ServiceName is "Mssmbios"
Another example of the DDK sample Toaster virtual bus device Busenum is also located under the system device class, the registry path is: Hkey_local_machine\system\currentcontrolset\enum\root\system \0003
The device stack is:, can also see the bottom pnpmanager equipment
Kd>!drvobj Busenumdriver Object (81f81030) is for: \driver\busenumdriver Extension list: (ID, addr) Device object List : 81ff3030 kd>!devstack 81ff3030 ! Devobj ! Drvobj ! Devext objectname> 81ff3030 \driver\busenum 81ff30e8 821e7190 \driver\pnpmanager 821e7248 00000035! Devnode 821a0008: deviceinst is "root\system\0003" ServiceName "Busenum"
However, for some bus devices, Pnpmanager are not found at all, such as the PCI bus and USB bus:
Kd>!drvobj Pcidriver Object (82189218) is for: \driver\pcidriver Extension List: (ID, addr) Device object List:82127c7 0 82127e50 82127030 821e03a0 ... 8219cb98 821e5370 821ba160 kd>!devstack 82127c70 ! Devobj ! Drvobj ! Devext ObjectName 81d34028 \driver\usbehci 81d340e0 USBFDO-1 82127790 \ DRIVER\ACPI 82187810 00000064> 82127c70 \driver\pci 82127d28 ntpnp_pci0043! Devnode 821272e8: deviceinst is "pci\ven_15ad&dev_0770&subsys_077015ad&rev_00\4&47b7341& 0&1888 " ServiceName is" USBEHCI "
Kd>!drvobj Usbhubdriver Object (820DE2C0) is for: \driver\usbhubdriver Extension List: (ID, addr) Device object List:8 1c74c98 81d542f0 820f1b70 81fcac9881c7ac98 kd>!devstack 81c74c98 ! Devobj ! Drvobj ! Devext objectname> 81c74c98 \driver\usbhub 81c74d50 00000079 81d542f0 \driver\ Usbhub 81d543a8 usbpdo-3! Devnode 81c82c48: deviceinst is "usb\vid_0e0f&pid_0002\6&2edefd9b&0&2" ServiceName " Usbhub
I can't think of that, Pnpmanager. After Zhou am pointing, understand one thing: Using!drvobj PCI list PCI device, except the last one is FDO, the other is PDO (here the FDO device means the device created by the PCI bus driver AddDevice function, attached to the underlying ACPI bus, The PDO device is a PCI bus that detects a new device on the bus, creating a PDO for the new device to form the device stack. The FDO itself is created by the PCI bus, so it is not attach on Pnpmanager, and by looking up the device stack of the FDO device to find the bottom of the stack pnpmanager.
Along with Zhou AM's idea, I re-debugged again, did find the PCI bus is located in the Pnpmanager, with the above environment as an example,
Kd>!drvobj Pcidriver Object (82189218) is for: \driver\pcidriver Extension List: (ID, addr) Device object List:82127c7 0 82127e50 82127030 821e03a0 ... 8219cb98 821e5370
PCI bus driver created device 0x821ba160 is FDO (why is FDO in the end? Because this is pci!. AddDevice the first device object that was created, and then the device object that was created is inserted through insertlisttail into the device queue header, so when traversing the device queue, the FDO is the last traversed) to view its device stack:
kd>!devstack 821ba160 ! Devobj ! Drvobj ! Devext objectname> 821ba160 \driver\pci 821ba218 821731a8 \driver\acpi 821e2940 00000038! Devnode 821de178: deviceinst is "acpi\pnp0a03\2&daba3ff&0" ServiceName "PCI"
The PCI device is stacked on the ACPI PDO, no wonder the Pnpmanager cannot be found in the PCI device stack. Continue searching for the ancestor, find the FDO created by the ACPI driver:
Kd>!drvobj Acpidriver Object (8219CA10) is for: \driver\acpidriver Extension List: (ID, addr) Device object list:8212c 628 8212c740 8212c858 82126538...821731a8 8219c8f8 kd> !devstack 8219c8f8! Devobj ! Drvobj ! Devext objectname> 8219c8f8 \driver\acpi 821e2ea0 821a0aa8 \driver\acpi_hal 821a0b60 00000037! Devnode 8219CD50: deviceinst is "acpi_hal\pnp0c08\0" ServiceName "ACPI"
The same ACPI FDO stacked on the Acpi_hal-driven PDO, continues to search for the ancestors, this time to find Acpi_hal stacking situation:
Kd>!drvobj Acpi_haldriver Object (821a0f38) is for: \driver\acpi_haldriver Extension List: (ID, addr) Device object Li St:821a0aa8 821a0bc8 kd>!devstack 821a0bc8 ! Devobj ! Drvobj ! Devext objectname> 821a0bc8 \driver\acpi_hal 821a0c80 821a4c68 \driver\pnpmanager 821A4D20 00000001! Devnode 821A4B20: deviceinst is "root\acpi_hal\0000"
Finally, Pnpmanager was found in the Acpi_hal-driven FDO device stack. This is completely similar to the structure of the Windows kernel and the device tree provided in the implementation book.
If you look at the device object created by the Pnpmanager driver at this point, you will find that there is really only one root device node in the system, while the other Pnpmanager device objects are grown in order to extend the device tree 1.1 points:
Kd>!drvobj Pnpmanagerdriver Object (821eb2e8) is for: \driver\pnpmanagerdriver Extension List: (ID, addr) Device objec T list:821e7190 821e73d0 821e7610 821e7850 ... 821a4c68 821a4020 kd>!devstack 821a4020 ! Devobj ! Drvobj ! Devext objectname> 821a4020 \driver\pnpmanager 821a40d8 ! Devnode 821a4ee8: deviceinst is "htree\root\0" <----from the name can feel this is the root device node kd>!devstack 821a4c68 ! Devobj ! Drvobj ! Devext ObjectName 821a0bc8 \driver\acpi_hal 821a0c80 > 821a4c68 \driver\ Pnpmanager 821a4d20 00000001 <----<span style= "font-family:arial, Helvetica, Sans-serif;" > name looks so no personality, certainly not the root device node </span>! Devnode 821A4B20:
Searching for device tree root nodes with WinDbg