Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Is PCIe device tree information cached by the OS?

craig_howardcraig_howard Member Posts: 245

I have an interesting case that has popped up ... one of my drivers scans the PCI bus gathering ECAM information using IoEnumerateDeviceObjectList, similar to as discussed here [ https://community.osr.com/discussion/104211/ioenumeratedeviceobjectlist-help ] and I'm aware that Doron wants a bus filter driver written rather than "brute forcing through the device tree" but a bus filter driver is several orders of magnitude more complex than what I'm trying to do and introduces a whole new raft of complexity ... it's the equivalent of using a neutron bomb to get rid of a gopher, it will work but is a bit of an overkill ...

Using IoEnumerateDeviceObjectList has worked very nicely up until recently, when I started using a ThunderBolt3 external PCIe chassis for various reasons. What I've found is that if I have a PCIe card in the external chassis, recognized by the OS and with driver loaded, when the TB3 cable is removed the PCIe card is still "found" by IoEnumerateDeviceObjectList (which makes no sense unless the OS is simply returning a cached value and not doing a true Enumeration of the Device Object List). Refreshing Device Manager (which coincidentally also uses IoEnumerateDeviceObjectList, don't know why Device Manager doesn't just install it's own bus filter driver to get that information rather than use that API) also "shows" the physically removed device ...

More disturbingly, this "phantom" device appears to survive a warm boot (cold boot clears it, thankfully and rationally) so again the evidence seems to point that the OS is building a list on boot and simply returning that cached result in IoEnumerateDeviceObjectList (maybe it should be renamed to IoReturnDeviceObjectListFoundOnInitialBoot) ...

Does anyone have any additional information, or seen something like this? I can do a workaround by treating IoEnumerateDeviceObjectList as IoReturnDeviceObjectListFoundOnInitialBoot and individually interrogating each PCIe device in the list to see if it's really there or not, but that doesn't fix the problem of a PCIe device attached via a TB3 connection during a running session ... that's a question for another topic ...

Thx!

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,835

    Ignoring the snark:
    1) I don't see calls to IoEnumerateDeviceObjectList in the pnp code, but I could have easily missed it.
    2) Ignoring 1, even if the pnp code is using the API call, it also has access to the internal pnp state lock and data structures hanging off the device objects so it can synchronize walking the list with pnp device tree changes.

    d
  • craig_howardcraig_howard Member Posts: 245
    edited November 2021

    Hey Doron! Thanks for the quick response, sorry for the snark (too much angst trying to work through this new TB3 "discovery", probably) ..

    The question remains though, when IoEnumerateDeviceObjectList is called is the OS going to make an actual walk through the PCI devices to build a list of attached devices that are attached (physical and TB3 bridged) and return that, or is the OS going to return a cached list of devices that were attached (physical and TB3 bridged) at the time of boot that it stored away in the registry somewhere?

    Thx!

    Post edited by craig_howard on
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,835

    IoEnumerateDeviceObjectList walks the list of device objects created by the driver (via the driver object, no registry involved). It does not trigger a pnp tree re-query. If/when PCI detects the external device on the other end of the wire is removed, it will invalidate its device relations, report the device as missing and the list of devices returned by IoEnumerateDeviceObjectList will reflect this change. If you want to force re query the tree (or a subset of it), you need to call CM_Reenumerate_DevNode in user mode.

    d
  • craig_howardcraig_howard Member Posts: 245

    Hmm ... OK, so IoEnumerateXX is returning a cached value from the last pnp bus enumeration, so if the TB3 disconnect event is not being properly reported to the OS then it makes sense that pnp will still see no changes ...

    Aside from being usermode and my driver being, well, kernel mode using CM_Reenumerate_DevNode is going to be tricky due to needing privileges that a usermode program won't have [ https://docs.microsoft.com/en-us/windows/win32/api/cfgmgr32/nf-cfgmgr32-cm_reenumerate_devnode?redirectedfrom=MSDN ] and [ https://stackoverflow.com/questions/14937261/equivalent-of-scan-for-hardware-changes-in-device-manager-doesnt-work-after-f ] so that's not really an option either ...

    This is the second time I've need to figure out a way to trigger a pnp re-query programattically ... I sense a trend ... :/

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,761
    via Email
    It is the pci bus driver that is in charge of pci device enumeration state,
    not 'pnp'. Dynamic bus reconfiguration for pci devices was originally not
    supported at all and quite painful to get working on hardware that
    supported it. Then there was limited support for pci dynamic reconfig,
    introduced maybe with Server 2003? I have no idea what has changed since
    then, but I'm guessing, 'not much', but the docs do claim that if the
    platform supports pcie hotplug, the os supports it too.

    Mark Roddy
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,162

    Agreed.

    The changes (some would say hacks) required to support Thurderbolt, where a PCI Root Complex can "just appear" were also considerable. PCI has been through some pretty interesting changes since Windows 8.

    By the way, you can now cause PCI to re-enumerate its bus... This surprised me, because it had been something Windows didn't do for so long. But, indeed, there's a function for that. So, there is SOME dynamic review available.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 9-13 Sept 2024 Live, Online
Developing Minifilters 15-19 July 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online