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

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:

How to access the PCI Config Space from a different device?

_Lost_bit__Lost_bit_ Member Posts: 13


Is there any way to access the PCI Config Space from a different Bus? The situation is that the device is connected through a PCI Express Upstream Switch Port and I need to access that device (the switch port) to query some info. Is there any way to do it without the need of a filter driver?

On Linux is as easy as just jumping two levels in the file system, but not sure how to get this info on Windows Kernel.

Thank you


  • MBond2MBond2 Member Posts: 145

    I am confused as to why you would want to do this. what bus other than PCIe would you be in? perhaps you want to do this from just a general KM context?

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,350
    via Email
    The intent was to access the parent pci bus config space. That actually
    could be a legitimate thing to do for some devices on some platforms.

    Mark Roddy
  • _Lost_bit__Lost_bit_ Member Posts: 13
    edited July 29

    Sorry for the late response.

    We actually ended up using the obscure function HalGetBusDataByOffset, and it's working, seems to be read only which is fine and it's limited only to the 256 bytes of the common PCI Header, doesn't cover the vendor specific stuff, but that's fine, it works.

    Thanks all.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,913

    HalGetBusDataByOffset isn’t obscure... it’s obsolete. It is not likely to work in certain situations, and it’s use is a common reason for blue screens.

    Peter Viscarola

  • _Lost_bit__Lost_bit_ Member Posts: 13

    @Peter_Viscarola_(OSR) said:
    HalGetBusDataByOffset isn’t obscure... it’s obsolete. It is not likely to work in certain situations, and it’s use is a common reason for blue screens.

    Do you mean like undefined behavior? I am warrantying its access for only PASSIVE_LEVEL, I was testing this, trying to access different buses and devices, the worst it happened was that the function failed. Do you have concrete examples on which scenarios it could lead to bug checks?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,498

    The issue is that PCI configuration space is owned by the PCI bus driver, pci.sys. HalGetBusDataByOffset bypasses the PCI bus driver. Some of the configuration space access methods are stateful; you put an address in one register, and read the results from another. If you sneak in the middle, pci.sys's access gets screwed up.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,913

    Do you mean like undefined behavior?

    I mean like “unsupported to the point where the docs have been removed, does not work in some cases, and may disappear from the binaries” (though I frankly doubt it’ll ever disappear).

    HalGetBusDataByOffset was rendered obsolete 20 years ago when PnP was introduced. After about 20 years, even Windows can sometimes retire an API.

    Before PnP, drivers walked up the PCI bus enumerating the VID and DID of the device in each slot, until they found the device(s) they supported. This was done with HalGetBusData. PnP rendered that activity obsolete, as we now have a very different model for resource ownership (as Mr. Roberts alluded to). It is not uncommon for drivers to crash the system attempting to walk the bus with HalGetBusData. When the API was officially broken in Windows 8, we got lots of calls from folks with old drivers that their code was suddenly blue screening systems. So, in many cases, we had the pleasure of rewriting those drivers for them.

    You use an API that’s obsolete, no longer documented, and known to cause blue screens at your own risk.


    Peter Viscarola

  • MBond2MBond2 Member Posts: 145

    IIRC this DDI was dangerous to use when it wasn't obsolete and was the only way to perform certain tasks. That was NT 4 days and my memory might not be right

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

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 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA