libwdi VS uhubctl

They probably use WCID, which is a mechanism for devices to tell Windows that they are compatible with the generic WinUSB driver. Zadig is useful for older versions of windows, non-WCID devices, and when you want to override that auto-specified driver.

Here's more information from the author of Zadig: https://github.com/pbatard/libwdi/wiki/WCID-Devices

If you do that'll bring you here where you'll find everything you ever wanted to know about WCID.

Using this config files from zadig's github page, it (in my case) got all the correct settings from the start and all I need to do is click replace driver. Place the zadig.ini files in the same directory as your zadig.exe. You might have to choose the correct device.

USB descriptors are supported only up to 8.1 according to your link. And libwdi/zadig is useful links for me, thank you very much! I'll be used ones in my other projects. But I don't need to new USB driver in Windows due to I'll get much more problems with put all together in LabView. I want to use standard WIndows USB-Serial that always present and directly supported via VISA. The NI-VISA isn't using specific protocols for USB. The VISA is just an intermediate level for most of the serial protocols in the NI ecosystem. I'm operating low-level USB packets, commands, responses in the same manner as in C for example but from LabView. But I have to generate the specific INF file which needs for recognition of VISA for each one of the specific instances with a unique USB PID/UID. The problem is mandatory signing such INF files in Windows10 and I'm looking for any way to avoid this.

In my experience this support was rare. I had an issue a few years ago with multiple USB 3 cameras (Intel Realsense) on a mobile robot that would periodically freeze up and need to be hard-reset, and a power-controllable hub seemed like the least-bad way to hack around it. I found my way to this tool, with its convenient list of compatible hardware:

https://github.com/mvp/uhubctl

Of the USB 3 options on the list, several were EOL or impossible to find, and when I ordered one each of the remainder, there was only one I could get working, and it wasn't reliable about being able to reset a device that had frozen to the point where Linux no longer had sysfs entries for it.

We ended up instead using a hub with an internal jumper to disable bus power, and then putting the self power line through a separately-controllable relay.

Best you can tweak is to disable the WiFi / Bluetooth and possibly the USB ports (edit - USB look no go https://github.com/mvp/uhubctl)

There's an extremely useful feature called USB Per-Port Power Switching, that's somewhat rare because nobody knows about it. If you use a Unix-family operating system, then here's a C driver. Windows doesn't currently have this feature, but could add it in the future -- let's hope they do!

https://github.com/codazoda/hub-ctrl.c or https://github.com/mvp/uhubctl can be used if the hubs have "Per-port power switching". The second link also has a long description.

If you were using a USB-powered drive and Linux/Mac/Unix, you could use uhubctl with one of the (uncommon) hubs that support Per-Port Power Switching (PPPS).

Actually some of the Pi boards USB ports can be controlled by Uhubctl but you have to note the restrictions on the board you are using - mainly how many you effect and the "minor" fact of the USB also controls the Ethernet and WiFi power on some boards!

Agreed this is not the right sub for this, but you got me curious. Without diving too deep, check out https://github.com/mvp/uhubctl

I've also used Qlab on both ends to trigger USB led flashes via OSC using uhubctl. You'll need a usb hub for that.