I’d like to clarify what Windows and View’s Virtual Hub do when generating Device IDs....
Device ID are either derived from the device’s serial number, or assigned by Windows.
In the case where the device has a serial (that is it contains a query-able string serial number resource) Windows will use that string in the device (or Device Instance Path), e.g. USB\VID_xxxx&PID_xxxx\[serial no]. This can also be seen in the hardware key created for a device, e.g.
HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_xxxx&PID_xxxx\[serial no]
If the device does not have a serial number then Windows generates this last part of the ID using the hub/port path, e.g. USB\VID_xxxx&PID_xxxx\x&xxxxxxx&x&x.
View’s Virtual Hub emulates this behaviour. The big difference is that the virtual hub does not have child hubs. It has 32 virtual ports. Your observation that the port number assigned is dependent upon the sequence the devices are redirected is right. View’s Hub tries to give devices that it has seen before the same port assignment. The hub stores a previously assigned port against a devices VID_PID_[serial number]. On the guest see HKLM\System\CurrentControlSet\services\vmwvhub\Parameters.
The problem here is that if devices with same VID/PID (that do not have a serial number) are redirected, View’s Hub will not be able to distinguish one from another.
Maybe this helps you check out what is happening in your environment with your device...
(thanks for moving to discussions - helps have a better to-and-fro discussion)
