Let me clarify the problem I am facing with now.
We have a PCIe controller which includes a PCI bridge device and another
PCI device. Our driver only controls the PCI device while the PCI bridge
device is handled by Windows PCI driver. Now due to a hardware problem,
I need to access PCI configuration space of the bridge device. Well, by
following the rules of WDM, I wrote a PCI bus filter driver to filter
pci.sys. This filter driver sends IRP_MJ_PNP/IRP_MN_QUERY_INTERFACE with
InterfaceType GUID_PCI_BUS_INTERFACE_STANDARD to the PCI driver to get
the PCI_BUS_INTERFACE_STANDARD. And then our original driver
communicates with this filter driver and uses
PCI_BUS_INTERFACE_STANDARD.ReadConfig/WriteConfig to enumerate and
access any PCI devices on the system.
This works fine. However, I am looking for a simpler solution (two
driver solution is not convinient for user and I don’t know if a PCI bus
filter driver is elligible for WHQL or not).
First of all, I thought I could use IoGetDeviceObjectPointer to get the
DO of PCI driver if it is created with a name, unfortunately it looks
like the DO is created without a name.
Now I thought if I could get the DriverObject of the PCI driver, then I
should be able find the PCI DO by walking through the
DriverObject->DeviceObject list. I know this list holds the PCI FDO and
PDOs for all enumerated PCI devices, however I can tell which is the FDO
I needed by checking DeviceObject->Flags.
Well, then now I am looking for a documented (or at least stable among
different Windows versions) solution to find the DriverObject of PCI. By
playing with WinDbg, it looks like I can find the PCI driver by walking
through DeviceObject->DeviceObjectExtension->AttachedTo starts with my
own DeviceObject. Unfortunately DeviceObjectExtension->AttachedTo is not
a documented field.
WinDbg command !drvobj pci to get the DriverObject of PCI driver. So
does WinDbg command !object \driver\pci. I don’t know how WinDbg
implements these commands. Maybe it checks \driver in the object
directory and matches with the name, However, it looks like Windows
doesn’t publish the DDIs needed to query objects under \driver
directory. And also I don’t know how to interprete the queried data.
The OSR tool DeviceTree now is shipped with Windows DDK. I believe it
uses undocument fields or APIs. If MS can accept that as its public
tool, Could MS make it published to simplify our developers’ life?
As you see, I am running out of solution now. Maybe I missed something,
maybe I am wrong on something, Could anybody here help me to step out of
it?
Thanks a lot!