USB conflict between local dongle (GrandMA3 vizkey) and VirtualHere driver

Submitted by jean-baptiste on #1

Hello,

I am running VirtualHere on a Dell Precision 5680 (Windows 11), and I am experiencing a conflict between the VirtualHere kernel driver (vhusb3hc) and a locally connected USB dongle.

MY SETUP:

  • VirtualHere Server 4.6.6-1466 running on a Synology NAS
  • VirtualHere client running on the Dell Precision 5680
  • A USB dongle for Depence R4 (3D rendering software) connected via VirtualHere through the NAS
  • A GrandMA3 vizkey dongle connected locally and directly to a USB port of the Dell

MY REQUIREMENT:
I need both dongles to work simultaneously on the same computer:

  • The Depence R4 dongle must be accessible via VirtualHere (through the NAS)
  • The GrandMA3 vizkey must be fully recognized locally (all 3 LEDs active)

VirtualHere should not interfere with or take control of USB dongles that are physically connected to the local machine.

Could you please advise how to configure VirtualHere or its driver to avoid this conflict?

Thank you very much for your help.

Best regards,
Jean-Baptiste

Submitted by Michael on Sun, 2026/03/22 - 07:50

#2

Virtualhere client shouldnt touch locally installed USB devices. Since there is no way for it to do so except under one circumstance.

You might need to edit the registry and reboot. (See here for the background https://www.virtualhere.com/node/2686 )

1. open regedt32 and add the entry under Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vhusb3hc\Parameters
New REG_DWORD name HCD value 6
2. Reboot the client pc then try using the device via virtualhere

Submitted by jean-baptiste on Sun, 2026/03/22 - 09:39

#3

Thank you for your reply and for the suggested registry modification.

Unfortunately, setting the HCD value to 6 did not resolve the issue. I also tested several other values (3, 4, 5, etc.) with a full reboot of the client PC each time, but the problem persists.

My BIOS, chipset drivers, and system are fully up to date

Do you have any further suggestions or advanced configuration options I could try (e.g. preventing the virtual controller from rebinding or affecting specific local USB devices)?

 

 

Submitted by Michael on Sun, 2026/03/22 - 12:08

#4

Whats the actual error in Device Manager? If something is not binding a driver correctly there will be an exclamation mark next to it. Can you see if anything has an exclamation mark.

Submitted by jean-baptiste on Sun, 2026/03/22 - 17:48

#5

I would like to clarify that there are NO errors in Device Manager:

  • No exclamation marks
  • No driver errors
  • All USB controllers and devices appear as working correctly

However, the issue is not a driver failure but a behavior problem:

  • When the "VirtualHere USB 3 eXtensible Host Controller" is DISABLED:
    - My local grandMA3 vizkey works perfectly
    - All LEDs are active
    - My software (Depence) correctly detects the dongle
  • When the "VirtualHere USB 3 eXtensible Host Controller" is ENABLED:
    - The vizkey is still visible in Device Manager (no errors)
    - But my software no longer detects it properly
    -The device seems partially initialized (only 2 LEDs active)

So from Windows’ point of view everything looks fine, but from the application side the dongle is no longer usable.

This suggests that the VirtualHere virtual host controller is affecting the USB initialization or communication of locally connected devices, even though no driver error is reported.

Submitted by Michael on Sun, 2026/03/22 - 18:56

#6

Ok I don't think it's virtualhere, I think it's their software, perhaps they don't want virtualhere used with it

Submitted by jean-baptiste on Mon, 2026/03/23 - 20:31

#7

I performed an additional test that may help clarify the issue.

On another workstation, we tested the same setup with VirtualHere enabled:

  • When the grandMA3 vizkey is plugged directly into the PC:
    - The device appears in Device Manager (no errors)
    - However, it is not properly recognized by the software (same behavior as on my system)
  • When the same vizkey is plugged into a USB hub integrated in a Samsung Odyssey G9 monitor:
    - The vizkey works perfectly
    - All LEDs are active
    - The software detects it correctly

So the only difference is the USB connection path (direct vs through a hub).

This strongly suggests that the issue is related to USB enumeration, timing, or how the device is exposed to the host controller when VirtualHere is active.

It seems that when connected through a hub, the device is initialized correctly, while a direct connection to the host controller leads to partial initialization.

Do you think this could be related to how the VirtualHere virtual host controller interacts with the physical USB controller (xHCI), especially regarding USB resets or re-enumeration?

Thank you very much for your support.

Submitted by jean-baptiste on Tue, 2026/03/24 - 00:32

#8

I performed deeper analysis using "USB Device Tree Viewe"r and would like to share additional findings.

On my system, when VirtualHere is started, it creates:

  • A virtual USB host controller (vhusb3hc.sys)
  • A virtual USB 3 root hub (USBHUB3.sys)

From Windows' perspective, this behaves like a full additional USB controller with its own root hub and ports.

Observed behavior:

  • My local grandMA3 vizkey remains visible in Device Manager with no errors
  • However, when the VirtualHere controller is active, the device is not fully initialized (LED state changes, and Depence does not detect it correctly)

Important observation:

  • When the vizkey is connected through an intermediate USB hub (e.g. Samsung G9 monitor), it works perfectly even with VirtualHere running
  • When connected directly to the system USB ports, it fails under the same conditions

This strongly suggests that:

  • VirtualHere triggers a USB bus re-enumeration or timing change when its virtual host controller is created
  • Some USB devices (like the vizkey) are sensitive to this and fail to fully initialize when directly attached to the root controller
  • Using an intermediate hub stabilizes the communication and avoids the issue

So there is no driver error, but rather a low-level USB behavior change caused by the presence of the VirtualHere virtual controller.

Do you have any option to:

  • prevent USB re-enumeration on VirtualHere startup?
  • or isolate local USB devices from the VirtualHere virtual host controller?

Submitted by Michael on Tue, 2026/03/24 - 07:11

#9

The VirtualHere client driver vhusb3hc doesnt interact at all with any built-in xhci controllers or any other Windows USB subsystem. 

Its entirely separate other than the name part which i suggested in number #2 above.

There is nothing in the USB path when the virtualhere client driver is installed that watches or interacts with any other USB device or host controller There are no filters or any other drivers installed that could possible affect this.

Anyway just use the usb hub workaround if that fixes it.