WDFDEVICE: find out PCI vendor and device IDs

I maintain a PCI driver which operates two different hardware designs,
and need to make decisions in the driver code based on the type of the
hardware.

Is there a straightforward (or less so) way, given a WDFDEVICE, to find
out its PCI vendor and device ID?

Thank you,
Jörg

Hi Jörg,

Usually the information about successfully enumerated devices is stored by
OS in the registry.

In order to get access to this info you can use WdfFdoInitQueryProperty
function.

Of course, you have to know in advance what you’re looking for.
I mean the string that describes the device. It’s usually written in the
inf-file of the driver.

Analyzing this string you can make a conclusion what kind of device is
active in the given moment.

Best Regards,
Dmitry

On Thu, Feb 2, 2017 at 3:12 PM, Jörg Faschingbauer
wrote:

> I maintain a PCI driver which operates two different hardware designs,
> and need to make decisions in the driver code based on the type of the
> hardware.
>
> Is there a straightforward (or less so) way, given a WDFDEVICE, to find
> out its PCI vendor and device ID?
>
> Thank you,
> Jörg
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

Dive into WDM and use IoGetDeviceProperty with DevicePropertyHardwareID to collect the type.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jörg Faschingbauer
Sent: Thursday, February 02, 2017 9:13 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WDFDEVICE: find out PCI vendor and device IDs

I maintain a PCI driver which operates two different hardware designs, and need to make decisions in the driver code based on the type of the hardware.

Is there a straightforward (or less so) way, given a WDFDEVICE, to find out its PCI vendor and device ID?

Thank you,
Jörg


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

Instead of parsing strings, have different matching inf DDINSTALL sections for the different hardware ids. In each unique section you write out to the devnode a specific reg value (could be diff values with the same value name or not) and the driver reads these values, not the ids. This way you have cleaner separation between the knob logic and the implementation and allows you to change the driver behavior without updating the driver in the future

Bent from my phone


From: xxxxx@lists.osr.com on behalf of J?rg Faschingbauer
Sent: Thursday, February 2, 2017 6:12:41 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WDFDEVICE: find out PCI vendor and device IDs

I maintain a PCI driver which operates two different hardware designs,
and need to make decisions in the driver code based on the type of the
hardware.

Is there a straightforward (or less so) way, given a WDFDEVICE, to find
out its PCI vendor and device ID?

Thank you,
J?rg


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

On the rare occasion this has been necessary, I’ve previously done it the way Mr. Altukhou describes using WdfFdoInitQueryProperty.

Mr. Holan’s suggest is a good one, but requires more documentation in both your driver code and your INF file. It’s pure pain to get a driver that reads a “Version” or “HackFlags” or “Options” value on startup from the Registry and then does stuff in the code, when you have to then figure out (a) who sets the value, (b) what the value means, (c) what the value is typically set to, (d) if the value can be changed after it’s been initially set, and (e) if the test is still necessary.

OTOH, if I see in my driver code that the drivers looking for “VID_28FA&PID_8036” then – even if the commenting is bad – it’s pretty clear what’s going on in the code.

Mr. Holan’s architectural guidance is to steer you toward putting policy in user mode and mechanics in your driver is both sound and wise. My point is that from a practical point of view, having “inherited” code that does such Registry-based checks, it can be a real PITA to figure out what’s going on when the author is comment-averse.

Peter
OSR
@OSRDrivers