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/


Driver installation for a usb device having variable vid and pid

VarunVarun Member Posts: 8

I wanted to install a driver on a usb device whose vid and pid is not fixed. I cannot include any vid and pid in INF file.
I have already tried DiInstallDriver, but this is not loading the driver for that device.
Also tried with DiInstallDevice but I am unable to get DriverInfoData..
Please provide suggestions on this..

Thanks

Comments

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,576

    Sorry but that usb device is just wrong. It has to have a fixed vid pid. That is required by the usb spec and has been required since usb was first deployed.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,410

    You need to describe your issue in more detail, because that doesn't make sense. Is this a device that you ship, where customers are allowed to program the descriptors? There is no generic way to handle that. A customer going to that effort is expected to provide their own driver. If that's not it, then tell us more about your device.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • VarunVarun Member Posts: 8

    Yes..This is device I ship but the customers can have their own Vid and Pid. Whatever is the VID and PID I have to load my drivers .

  • VarunVarun Member Posts: 8
    edited May 26

    Sorry, I was not very clear in my previous post. Tim, Your understanding is correct.

    The USB device PID and VID will be fixed only but it is not known in advance. The VID/PID will be decided by the customers when they program the descriptors. There may be different VID/PID for different devices. The driver needs to support all the devices having different VID/PIDs. We will be able to detect the device as our device using the string descriptors.

    The driver needs to be delivered by us.

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,576

    Well you are screwed. Also VIDs are registered, your customers shouldn't just be creating their own. Your customers are going to have to modify the inf file and get that signed.

  • VarunVarun Member Posts: 8
    Consider I have a device with xxxx Vid and xxxx Pid and I have not added this vid and pid in inf file, but I was able to load my driver from device manager manually.

    Is it possible to load the driver for a device through any application or service even though my inf file is not having the vid and pid of the device
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,046

    Also VIDs are registered, your customers shouldn't just be creating their own.

    The operative words here being "shouldn't be" -- I can barely describe how hard it was to FIND any USB flash drives that can be customized (you know, that we could have the OSR logo put on them) that had a legit VID/PID in them? It was like a bad joke. VID ABCD, PID 1234 was very common, it turns out.

    ANYhow... that's neither here nor there. Your advice to the OP is correct.

    Is it possible to load the driver for a device through any application or service even though my inf file is not having the vid and pid of the device

    Not that I know.

    Peter Viscarola
    OSR
    @OSRDrivers

  • Pavel_APavel_A Member Posts: 2,822
    edited May 26

    Well you can add the "Microsoft OS descriptor" to your firmware, this will automatically install the WinUSB driver or other in-box class driver for the device, whatever is its VID/PID. But not your own driver.
    Also, there's something known as "Zadig"...

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,410

    This is not an uncommon situation. Xilinx and Cypress both ship chips where the VID and PID can be reprogrammed. In that case, the functionality of the device has changed, so the original driver isn't appropriate. The EASY answer is what Pavel said -- use the Microsoft OS descriptors, which can automatically register a GUID that a WinUSB application can fetch. No other driver required. Otherwise, your clients will have to go through the certification process themselves.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • VarunVarun Member Posts: 8

    Thank you all for your insights..

    I had one more small question..
    Can we install our drivers using Compatible id?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,046

    Can we install our drivers using Compatible id?

    That’s a very good question. I wonder…

    Anybody actually done this?

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Xiaofan_ChenXiaofan_Chen Member - All Emails Posts: 240

    Can we install our drivers using Compatible id?

    That’s a very good question. I wonder…

    Anybody actually done this?

    Yes that has been done before back in 2011. I can confirmed that it works by using "LIBUSB0\0" and "LIBUSBK\0" as Compatible ID.
    Ref:
    https://github.com/pbatard/libwdi/wiki/WCID-Devices#Microsoft_Compatible_ID_Feature_Descriptor
    https://pete.akeo.ie/2011/10/on-windows-8-and-wcid-devices.html

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,410

    Here's the key question. As a human being, how would YOU decide that a new device was derived from your design? In the information available to you (that is, the descriptors), what makes it unique? If there is nothing unique, then clearly there is no criteria you can use in an INF file to claim them.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Pavel_APavel_A Member Posts: 2,822

    In the information available to you (that is, the descriptors), what makes it unique?

    Indeed the driver can check the descriptors (for a vendor-specific protocol ID? custom strings?) and for presence of the required endpoints.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,410

    Indeed the driver can check the descriptors (for a vendor-specific protocol ID? custom strings?)

    That's too late. The solution has to be at the INF level. If he could get the driver loaded, the problem would be solved.

    And, as it turns out, Microsoft does not officially support third-party drivers claiming a USB class code. That doesn't mean it can't be done, but I believe INFCHECK fails it so it won't pass WHQL.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Xiaofan_ChenXiaofan_Chen Member - All Emails Posts: 240

    If we look at winusb.inf file, it supports three Windows Compatible IDs. So if you have another kernel driver with valid signature, you can do the same thing to create an inf file to use a different driver and different Compatible IDs.

    [Generic.Section.NTamd64]
    %USB\MS_COMP_WINUSB.DeviceDesc%=WINUSB,USB\MS_COMP_WINUSB
    %USB\MS_COMP_BILLBOARD.DeviceDesc%=BILLBOARD,USB\Class_11&SubClass_00&Prot_00
    %USB\MS_COMP_ADB.DeviceDesc%=ADB,USB\Class_ff&SubClass_42&Prot_01

    As Tim mentioned the inf may not be able to pass WHQL (not so sure anyone have tried?), but probably it can pass attestation and then get used by the end customer.

    Last time we use libwdi to create an installer to install such an info for libubs0.sys and libusbk.sys and it worked well. I believe it should still work. Take note the .sys driver should have valid digital signature.

    So I am thinking the following will do.
    1) package the driver with known VID/PID and submit for attestation signing, this is for existing customers and to get the signed .sys file.
    2) after 1) was done, submit another driver package (with the signed .sys and the inf file for custom Windows Compatible ID) for attestation signing
    3) distribute the second package to those customers who do not want to go through WHQL
    4) customer who wants WHQL can go by themselves

  • Xiaofan_ChenXiaofan_Chen Member - All Emails Posts: 240

    @Tim_Roberts said:
    And, as it turns out, Microsoft does not officially support third-party drivers claiming a USB class code. That doesn't mean it can't be done, but I believe INFCHECK fails it so it won't pass WHQL.

    I belive you here.

    We had such discussion in libusb-devel mailing list back in 2012. And in the end, we do not really proceed with the idea of gong with the idea of using MS_COMP_LIBUSBK or MS_COMP_LIBUSB0.

    In the end, WinUSB is the way to go for generic USB devices and libusb0.sys is more for legacy devices and libusbk.sys is only for very niche use cases.

    Reference:
    https://marc.info/?l=libusb-devel&m=134217969228238&w=2
    On 2012.07.13 11:48, Xiaofan Chen wrote:

    But then the
    problem is that I am not 100% sure if you can get WHQL for a
    class of USB device (no specific VID/PID). It seems to be a
    reserved privilege of Microsoft.

  • Xiaofan_ChenXiaofan_Chen Member - All Emails Posts: 240

    @Tim_Roberts said:
    Here's the key question. As a human being, how would YOU decide that a new device was derived from your design? In the information available to you (that is, the descriptors), what makes it unique? If there is nothing unique, then clearly there is no criteria you can use in an INF file to claim them.

    Microsoft WinUSB.inf is probably an exception, since Microsoft has reserved privilege.

    [Generic.Section.NTamd64]
    %USB\MS_COMP_WINUSB.DeviceDesc%=WINUSB,USB\MS_COMP_WINUSB
    %USB\MS_COMP_BILLBOARD.DeviceDesc%=BILLBOARD,USB\Class_11&SubClass_00&Prot_00
    %USB\MS_COMP_ADB.DeviceDesc%=ADB,USB\Class_ff&SubClass_42&Prot_01

  • Xiaofan_ChenXiaofan_Chen Member - All Emails Posts: 240

    BTW, libwdi/Zadig was actually one of the primary examples of driver installer for unknow USB VID/PIDs. And it is actually widely used, including Raspberry Pi Foundation. For unknown reasons they actually recommended using libusb0.sys and not WinUSB.
    Ref: https://github.com/raspberrypi/picoprobe/issues/15

    There is a pull request to use WinUSB Compatible ID to get rid of this extra driver installation process.
    https://github.com/raspberrypi/picoprobe/pull/17

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,720

    Any INF can match against a compatible ID. By policy no third party INF matching a compat ID will be signed by WHQL. If WHQL does sign such an INF in any workflow, that is a failure to apply the correct policy and not by design.

    d
  • Xiaofan_ChenXiaofan_Chen Member - All Emails Posts: 240

    @Doron_Holan said:
    Any INF can match against a compatible ID. By policy no third party INF matching a compat ID will be signed by WHQL. If WHQL does sign such an INF in any workflow, that is a failure to apply the correct policy and not by design.

    Thanks for the confirmation. This is in line with my understanding. Matching an inf with a compatible ID can be done, with attestation signing, but not possible to get WHQL.

  • Xiaofan_ChenXiaofan_Chen Member - All Emails Posts: 240

    @Varun Going back to the original topic, just wondering why you need a custom driver, can you use WinUSB instead? Many companies (eg: ST, Microchip, etc) have moved from custom generic USB driver (in-house or things like Jungo or libusb0.sys) to WinUSB. The only main exception is probably Cypress which still has their custom cyusb3.sys driver.

  • Michal_VodickaMichal_Vodicka Member - All Emails Posts: 113
    edited June 2

    Anybody actually done this?

    Yes, I did. Works as a charm and it is great for composite devices because you don't need to have fixed interface numbers (MI_XX values) in your INF file. I used compatible ID for device name and subcompatible ID for interface name. The result is something as MS_COMP_DEVNAME&MS_SUBCOMP_IFCNAME. For us it is better because our device can be configured several ways enabling different interfaces which changes their numbers.

    Actually, I was going here to ask the question about this and found this discussion :) My question was already answered by Doron and unfortunately not the way I like:

    By policy no third party INF matching a compat ID will be signed by WHQL.

    This is not clear from current docs here: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/compatible-ids and it actually suggests the opposite meaning. It is not stated explicitly there but it mentions vendor-defined identification string and suggests naming for 3rd party devices.

    So Doron, are you really sure about it? This is serious limitation which makes it almost useless for anybody but MS. Which is a pity as it looks as a great solution for composite devices and also for OP's problem.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,720
    The first sentence in the doc page is not very clear. Yes, the vendor defines the compatible ID but as the vendor you are pretty constrained if you want an in box driver to match. I am 100% positive you can’t distribute a compat ID match package through WHQL. It has been this way since at least Windows 2000. The reason is that as a third party WHQL should only be offering your driver for your device, not all devices. A compat ID match has the potential to match against all vendors devices.
    d
  • Michal_VodickaMichal_Vodicka Member - All Emails Posts: 113
    edited June 2

    I was aware about this limitation in the past but this docs led me to impression things changed. It'd make sense as now you have much more options for USB devices development than at 2000. Our devices have embedded Linux inside which allows much richer USB configurations.

    You're right it is possibly dangerous feature and naming should be carefully considered (as docs suggests). Which I really did :)

    Well, what if we give it to our customers signed just by company certificate and not WHQL? Is it a problem?

    BTW, I haven't found any specification about compatible/subcompatible IDs maximal length. Linux has hardcoded size 8 for both (and there is some really crappy coding related to it...) but your docs doesn't speak about it.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,720
    Compat and hardware IDs have the same limits, they are just differentiated on rank.

    At the driver package layer you can create what ever you want. Match on a compat id if you need. Self sign it. It’s the WHQL policy layer that doesn’t let you match or distribute on a compat ID.
    d
  • Michal_VodickaMichal_Vodicka Member - All Emails Posts: 113

    Thanks. The only limit I found for HW ID is MAX_DEVICE_ID_LEN which seems to be 200 for the whole string. No restrictions for single fields? So this Linux 8 chars per field is purely arbitrary?

    Yep, this is what I did. Will need to ask if no WHQL is a problem for this product.

    Just to explain why I went this way. Normal vendor specific USB device is identified by VID + PID (+ bcdDevice) and vendor provides a driver package for it. It can be seen as an whole device interface/functionality. Composite device has more interfaces and driver packages for every one need to distinguish among them. It is done using interface number (MI) which isn't great because it doesn't specify functionality but something as topology. Which can change for many reasons and if you have several driver packages for this device it'd lead to a big mess (been there). Compatible IDs used with MS OS descriptors allow to specify functionality for every interface and you can create driver package which matches specific interface/functionality and current topology doesn't play role.

    I agree there is a danger as INF using compatible IDs can't be limited just for the composite device from some vendor. Maybe support for composite devices could be improved? Allow to specify VID+PID and some kind of ID for interfaces which can be reported using MS OS descriptors. Also, some MS drivers should be improved to work better with composite devices. We use RNDIS as one of interfaces and it is real PITA. It has some "special" reqirements (probably hardcoded values) so it only works at the first interface :/

  • VarunVarun Member Posts: 8

    Hi all,

    Sorry I was away from work for few days..
    Thanks for all the inputs.
    With Compatible id if the WHQL tests fail, then it is better to go with WinUsb driver.
    The reason why I wanted my custom driver was I had some extra features in my driver which Winusb may not be having.
    I need to check how I can work with WinUsb to include the features I have in my driver.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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 January 2023 Live, Online
Developing Minifilters 20 March 2023 Live, Online
Writing WDF Drivers TBD 2023 Live, Online
Internals & Software Drivers 17 April 2023 Live, Online