PCI Bus Filter driver to read config space?

Hi All!

I'm trying to port an app which dumps PCI config space info on Win2K3.

I understand you can no more use HALGetBusData in Win2K and beyond. To
use "interface" methods suggested in MS KB articles,you need the PDO.
If you are going to dump config space of arbitary devices, how do you
obtain PDO to read config space?

Will writing a PCI bus filter driver solve this?

--
Thanks,
Elam

"Experience is an expensive school" - Twain.

You can still use the Hal functions, they just don't work correctly in all
cases. That is they still work correctly probably 99.9% of the time.

A bus filter will accomplish what you want, and I have done this with PCI.
But, you have to understand the difference between a normal WDM filter
driver and a bus filter driver. A bus filter is fairly complicated to
implement.

--
Bill McKenzie
Software Engineer - Prism 802.11 Wireless Solutions
Conexant Systems, Inc.


"HyperWalker" <> wrote in message
news: m...
> Hi All!
>
> I'm trying to port an app which dumps PCI config space info on Win2K3.
>
> I understand you can no more use HALGetBusData in Win2K and beyond. To
> use "interface" methods suggested in MS KB articles,you need the PDO.
> If you are going to dump config space of arbitary devices, how do you
> obtain PDO to read config space?
>
> Will writing a PCI bus filter driver solve this?
>
> --
> Thanks,
> Elam
>
> "Experience is an expensive school" - Twain.

> But, you have to understand the difference between a normal WDM filter
> driver and a bus filter driver. A bus filter is fairly complicated to
> implement.

Several lines of code in MN_QUERY_DEVICE_RELATIONS path, which will attach the
filter DOs to all PDOs in the relations list.

Proper destruction of these DOs is also a must.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation

http://www.storagecraft.com

"Maxim S. Shatskih" <> wrote in message
news:...

> > But, you have to understand the difference between a normal WDM filter
> > driver and a bus filter driver. A bus filter is fairly complicated to
> > implement.
>
> Several lines of code in MN_QUERY_DEVICE_RELATIONS path, which will attach
the
> filter DOs to all PDOs in the relations list.
This is very simple.

> Proper destruction of these DOs is also a must.
The tricky part is removing these DOs, (when to remove/not to remove/delay
remove until something happen)

Auto loading filter for any PCI-PCI or AGP bridges FDOs is another trouble.
(just imagine someone hot plug in a PCI-PCI or AGP bridge and there're
devices behind that bridge)

Sometime ago, I did such a filter and it works great for PCI and usb stacks.

To the OP, instead of a bus filter, there may be an easier way to accomplish
this but that may required some undoc methods.

To send IRP_MN_READ/WRITE_CONFIG to the stack, all you need is the targeted
PDOs created by pci.sys. You basically need the DRIVER_OBJECT for pci.sys.
(do a google on ObReferenceObjectByName), then you will need
IoEnumerateDeviceObjectList (see IFS doc if you have). For each enumerated
DO, send a IRP_MN_QUERY_BUS_RELATIONS (target relation), you then can tell
PDO from FDO. Don't forget to deref objects in most of those steps.

I know this may be evil and I'm opening a can of worms, but it works
reasonably well for me, and it's solely for in-house test/prove-of-concept
purpose. You don't need to implement it as a PNP filter, just a legacy
driver will be fine, easy to load/unload.

Good luck,
Calvin
-
Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com

Appreciate all your insights..

The utility will be used for diagnostic support of large production
systems.
While undocumented ways may not be prohibited, they probably wont
tolerate bugchecks(or such instability) or inaccurate info.

Is there some sample PCI bus filter which I can use as a base and
figure out things..

(as an aside, has anyone used WMI/sdixx device install APIs for the
same purpose successfully? )
--
Elam

"Experience is an expensive school" - Ben Franklin (not Twain)


"Calvin Guan" <> wrote in message news:<>...
> "Maxim S. Shatskih" <> wrote in message
> news:...
>
> > > But, you have to understand the difference between a normal WDM filter
> > > driver and a bus filter driver. A bus filter is fairly complicated to
> > > implement.
> >
> > Several lines of code in MN_QUERY_DEVICE_RELATIONS path, which will attach
> the
> > filter DOs to all PDOs in the relations list.
> This is very simple.
>
> > Proper destruction of these DOs is also a must.
> The tricky part is removing these DOs, (when to remove/not to remove/delay
> remove until something happen)
>
> Auto loading filter for any PCI-PCI or AGP bridges FDOs is another trouble.
> (just imagine someone hot plug in a PCI-PCI or AGP bridge and there're
> devices behind that bridge)
>
> Sometime ago, I did such a filter and it works great for PCI and usb stacks.
>
> To the OP, instead of a bus filter, there may be an easier way to accomplish
> this but that may required some undoc methods.
>
> To send IRP_MN_READ/WRITE_CONFIG to the stack, all you need is the targeted
> PDOs created by pci.sys. You basically need the DRIVER_OBJECT for pci.sys.
> (do a google on ObReferenceObjectByName), then you will need
> IoEnumerateDeviceObjectList (see IFS doc if you have). For each enumerated
> DO, send a IRP_MN_QUERY_BUS_RELATIONS (target relation), you then can tell
> PDO from FDO. Don't forget to deref objects in most of those steps.
>
> I know this may be evil and I'm opening a can of worms, but it works
> reasonably well for me, and it's solely for in-house test/prove-of-concept
> purpose. You don't need to implement it as a PNP filter, just a legacy
> driver will be fine, easy to load/unload.
>
> Good luck,
> Calvin
> -
> Calvin Guan Software Engineer
> ATI Technologies Inc. www.ati.com

There are no such samples. You can probably purchase such a sample from any
of the consultants on this list.

--

=====================
Mark Roddy
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com



"HyperWalker" <> wrote in message
news: om...
> Appreciate all your insights..
>
> The utility will be used for diagnostic support of large production
> systems.
> While undocumented ways may not be prohibited, they probably wont
> tolerate bugchecks(or such instability) or inaccurate info.
>
> Is there some sample PCI bus filter which I can use as a base and
> figure out things..
>
> (as an aside, has anyone used WMI/sdixx device install APIs for the
> same purpose successfully? )
> --
> Elam
>
> "Experience is an expensive school" - Ben Franklin (not Twain)
>
>
> "Calvin Guan" <> wrote in message
news:<>...
> > "Maxim S. Shatskih" <> wrote in message
> > news:...
> >
> > > > But, you have to understand the difference between a normal WDM
filter
> > > > driver and a bus filter driver. A bus filter is fairly complicated
to
> > > > implement.
> > >
> > > Several lines of code in MN_QUERY_DEVICE_RELATIONS path, which will
attach
> > the
> > > filter DOs to all PDOs in the relations list.
> > This is very simple.
> >
> > > Proper destruction of these DOs is also a must.
> > The tricky part is removing these DOs, (when to remove/not to
remove/delay
> > remove until something happen)
> >
> > Auto loading filter for any PCI-PCI or AGP bridges FDOs is another
trouble.
> > (just imagine someone hot plug in a PCI-PCI or AGP bridge and there're
> > devices behind that bridge)
> >
> > Sometime ago, I did such a filter and it works great for PCI and usb
stacks.
> >
> > To the OP, instead of a bus filter, there may be an easier way to
accomplish
> > this but that may required some undoc methods.
> >
> > To send IRP_MN_READ/WRITE_CONFIG to the stack, all you need is the
targeted
> > PDOs created by pci.sys. You basically need the DRIVER_OBJECT for
pci.sys.
> > (do a google on ObReferenceObjectByName), then you will need
> > IoEnumerateDeviceObjectList (see IFS doc if you have). For each
enumerated
> > DO, send a IRP_MN_QUERY_BUS_RELATIONS (target relation), you then can
tell
> > PDO from FDO. Don't forget to deref objects in most of those steps.
> >
> > I know this may be evil and I'm opening a can of worms, but it works
> > reasonably well for me, and it's solely for in-house
test/prove-of-concept
> > purpose. You don't need to implement it as a PNP filter, just a legacy
> > driver will be fine, easy to load/unload.
> >
> > Good luck,
> > Calvin
> > -
> > Calvin Guan Software Engineer
> > ATI Technologies Inc. www.ati.com