pbatard
commented
2 years ago It appears that the default libwdi winusb INF template overwrites DeviceInterafaceGUID and does not restrict itself to any USB VID/PID
The second part is not correct.
If you install a standard driver with libwdi, it will explicitly restrict the driver installation to the VID/PID of the target device that was selected during installation.
Please be mindful that the template you see is filled at runtime by libwdi to insert the VID/PID before it is provided to Windows for driver installation.
For instance, the following is what will be generated in the inf if you select a device with a VID:PID of 045E:0289 in libwdi:
[Strings]
DeviceName = "XBox Controller"
VendorName = "Microsoft Corp."
SourceName = "XBox Controller Install Disk"
DeviceID = "VID_045E&PID_0289"
DeviceGUID = "{28E17191-8803-4532-89A6-222A4581A803}"
(...)
[Manufacturer]
%VendorName% = libusbDevice_WinUSB,NTx86,NTamd64,NTarm
[libusbDevice_WinUSB.NTx86]
%DeviceName% = USB_Install, USB\%DeviceID%
[libusbDevice_WinUSB.NTamd64]
%DeviceName% = USB_Install, USB\%DeviceID%
[libusbDevice_WinUSB.NTarm]
%DeviceName% = USB_Install, USB\%DeviceID%
[USB_Install]
Include = winusb.inf
Needs = WINUSB.NT
[USB_Install.HW]
AddReg = AddDeviceInterfaceGUID
(...)
[NoDeviceInterfaceGUID]
; Avoids adding a DeviceInterfaceGUID for generic driver
[AddDeviceInterfaceGUID]
HKR,,DeviceInterfaceGUIDs,0x10000,%DeviceGUID%
(...)This means that, since the .inf processing logic is libusbDevice_WinUSB → libusbDevice_WinUSB → USB_Install IF USB\%DeviceID% matches → USB_Install.HW → AddDeviceInterfaceGUID, if %DeviceID% doesn't match, which equates to a mismatch for "VID_045E&PID_0289", then the DeviceInterfaceGUID registry changes are not carried out.
In other words, what you request is already what libwdi is doing, which is to restrict the drivers to the specified VID/PID pairs.
Now, the one part that is correct is that we do insert a new DeviceInterfaceGUID when a user installs or overwrites the driver for a specific VID/PID. That's because we consider that, if a user is using libwdi then, it's because they aren't happy with the existing (or non existing) driver, which, if Microsoft OS descriptors are being used, should have already been installed to the user's satisfaction and not required the use of libwdi.
Therefore, I believe that your analysis of the issue is not accurate, because it most likely boils down to your customer, who should already have had a perfectly working WinUSB driver installed through the Microsoft OS descriptors, along with the DeviceInterfaceGUID you needed, deciding that they somehow weren't happy with that driver and choosing to override/overwrite it using libwdi (which, if they are just going to use to re-install WinUSB makes absolutely no logical sense... and, if they are going with another driver such a libusbK, will prevent your WinUSB based application from accessing it anyway, regardless of whether the DeviceInterfaceGUID is the one you want or not).
Well, if someone says: "I want to overwrite the driver settings for this specific device and start with a clean slate", that's is precisely what libwdi gives them, including a brand new DeviceInterfaceGUID, because we see very little reason why a customer would not want a new one then (since, if we preserved it, it'd mean that the end result would be virtually the same as what they already had, whereas getting a new DeviceInterfaceGUID is pretty much the only reason why you'd want to use libdwi to reinstall a WinUSB driver, if you already had WinUSB installed through the OS descriptors).
All in all then, I think your issue boils down to a user error.
Your customer probably thought they needed to manually install the WinUSB driver and didn't realise it had been done automatically for them. So they selected their device in Zadig/libwdi, ignored the field that told them that WinUSB was already installed for that device as well as the fact that the button explicitly says Replace driver (instead of the usual Install driver when no driver is installed), and replaced the generic WinUSB driver with the one generated by libwdi whereas they had absolutely no need of doing so.
Thus, unless I am misunderstanding your issue, I don't think there's much I want to do about users using my application when they had no reason to use it in the first place. Considering that installation of drivers is not a trivial operation, and that libwdi/Zadig were never designed for entry level users, we expect anyone using libwdi/Zadig to have some idea what they are doing and why. Therefore, if a customer starts to use it when they shouldn't, and it happens to overwrite the DeviceInterfaceGUID of their device (which again, is what I very much expect the majority of libwdi users who willingly choose to overwrite a driver do want), then I would say that it probably your job to let your customers know that they don't need oto bother about manually install WinUSB, because it gets installed automatically for them.
In other words, I think the issue simply boils down to an overzealous customer. And, considering that the cost/benefit ratio of trying to cater for such users (especially if it comes at the detriment of other users) is simply way too high for a free application, I really don't see anything that libwdi should to do any differently.
As such, I will close this issue.
mliberty1
Version: unknown Platform: Windows 11 x64
Description
I had a Joulescope customer attempt to use their new device on a Windows 11 machine. They reported that their new instrument showed up in Device Manager, but our application software could not find it. After investigation, the device was claimed by libwdi.
Joulescopes use Microsoft OS Descriptors to automatically instantiate the WinUSB driver and set some registry keys, including
DeviceInterfaceGUID. It appears that the default libwdi winusb INF template overwritesDeviceInterafaceGUIDand does not restrict itself to any USB VID/PID. Since our application software searches for Joulescopes usingDeviceInterfaceGUID(see here and here), it failed to find the connected device on this machine. Joulescopes also use a PID issued by MCS with VID 0x16D0 rather than a dedicated VID issued to our company, which may exacerbate the problem.Whoever uses libwdi should restrict their drivers to the specified VID/PID pairs. For some reason, this seems to not have happened with this computer and whatever software deployed libwdi. Unfortunately, I do not know what software used libwdi that caused this issue.
You can find more details on the Joulescope forum.
Expected Behavior
libwdi should play nicely with other software & devices. Drivers created with libwdi should only affect the target VID/PID pairs. In my opinion, the default libwdi setup should help users create drivers that only claim the specified VID/PID pairs, if it doesn't already. libwdi should not cause erratic or unexpected behavior with other devices.