Searching for device tree root nodes with WinDbg

Source: Internet
Author: User

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

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.