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.
@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.
@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.
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.
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.
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.
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.
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 
1 Like
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.