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

Home NTDEV
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: https://www.osr.com/osr-learning-library/


WDFDEVICE: find out PCI vendor and device IDs

OSR_Community_UserOSR_Community_User Member Posts: 110,217
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

Comments

  • Dzmitry_AltukhouDzmitry_Altukhou Member - All Emails Posts: 16
    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: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer&gt;
    >
  • Don_BurnDon_Burn Member - All Emails Posts: 1,692
    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: [email protected] [mailto:[email protected]] On Behalf Of Jörg Faschingbauer
    Sent: Thursday, February 02, 2017 9:13 AM
    To: Windows System Software Devs Interest List <[email protected]>
    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://www.osronline.com/showlists.cfm?list=ntdev&gt;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <http://www.osr.com/seminars&gt;

    To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer&gt;
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,499
    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: [email protected] 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:

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

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,851
    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

    Peter Viscarola
    OSR
    @OSRDrivers

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