Snooping config reads during Windows 2012/2016 pci enmumeration

Hi,
I have a pcie device that I need to let Windows think the device type is a value than what is on the hardware. The real change requires silicon respin of a CPU. Not possible now. My idea was the write a bus filter driver, and snoop the config read response. I would then modify the read content and change one byte value. I think I have the filter driver loading as an upper class filter driver under pci bus, using the guid in the registry. So far, I can break into Windbg when the system is loaded and I can see the IRP_MN_NNNN passing through my filter driver.
I tried snooping on IRP_MN_QUERY_INTERFACE to see if BUS_INTERFACE_STSNDARD is used to for the config reads. However, I never see any calls later for the interface->GetBusData that the system queried.
My question is, 1) is my approach able to snoop on the config data? 2) is there a different mechanism that Windows use during enumeration to get the pci devices’ config space read?
3) Is it that there is no way for a bus filter driver to alter the read contents of pci devices while Windows is enumerating?
Thanks for any pointers to help resolve this issue.
-os

Hmmmm… Right solution, sort of… but wrong API.

You can’t get between the PCI Bus Driver and the PCI Bus to change the Device Type. It’s the PCI bus driver that’s going to read the PCI config spaces and build the Hardware ID strings that describe the device. The PCI Bus Driver will then report these Hardware IDs out to PnP, who’ll find “the best driver” for the device.

I think your only chance will be to write a bus filter that changes the enumerated Hardware IDs and Compatible IDs that are returned to PnP as a result of the IRP_MN_QUERY_ID. You can read more about the format of the IDs on PCI here.

I pretty much think that’s going to be your only option. Maybe others here will offer more creative solutions, but I can’t think of one.

Peter

Thanks for the input Peter. I remembered taking your class in Phoenix in 2000 or 2001 on NT4 drivers. such a long time ago:).
I wrote a bus filter driver for this that I installed as a upperFilter above PCI.SYS, using the GUID for this class. I am able to attach when I see PNP0A08.
I was trying to snoop for IRP_MN_READ_CONFIG but it did not came. So I intercepted IRP_MN_QUERY_INTERFACE and try to make sure the PNP manager call my inserted busInterface getBusdata, which I use to then call down to the bus driver, but that did not occur either. So I reach out to the community for suggestions.
From what you replied, I will pursue the other IRP_MN functions you mention. If I have a breakthrough I will surely post my final solution here so I may be of help to others who may have the same issue in the future.
-os

Remember, IRP_MN_READ_CONFIG is the way drivers above PCI.SYS read the config space. PCI.SYS does it by accessing the hardware directly. What you’re saying can be done with USB, because the USB host controller driver doesn’t interpret the descriptor values. That’s done by the USB hub drivers, so it IS possible to intercept and modify the descriptor URBs. You can’t do that with PCI.SYS, because it’s doing the interpretation and create of child drivers directly.