Describe the Bug
I am experiencing a reproducible Windows sleep/resume issue with libvirtualhid. After a clean Windows boot, libvirtualhid works normally and its own virtualhid_control.exe diagnostic reports:
Backend: windows-umdf | gamepad available | mouse available | output reports available
Controller forwarding through Sunshine/Moonlight also works normally in this state.
After putting the PC into normal Windows Sleep and waking it, virtualhid_control.exe changes to:
Backend: windows-umdf | gamepad unavailable | mouse available | output reports unavailable
The libvirtualhid Broker service remains Running.
Sunshine then fails to create its virtual controller and logs:
Warning: create libvirtualhid gamepad: create Windows virtual HID device: The handle is invalid
followed by:
Fatal: libvirtualhid gamepad support is unavailable and ViGEmBus fallback is not installed or running
I have also observed:
Warning: submit libvirtualhid mouse movement: submit Windows input report: The handle is invalid
Importantly, the failure can be reproduced in virtualhid_control.exe without Moonlight being involved, so this does not appear to be a physical controller or Moonlight issue.
Steps to reproduce:
Clean boot Windows.
Open virtualhid_control.exe and confirm gamepad, mouse, and output reports are available.
Controller forwarding through Sunshine/Moonlight works normally.
Put Windows into Sleep.
Wake the PC.
Reopen virtualhid_control.exe.
Gamepad becomes unavailable and output reports become unavailable, while mouse remains available.
Sunshine can no longer create its libvirtualhid Xbox controller.
Recovery attempts:
Restarting libvirtualhid Broker does not restore the backend.
Restarting Sunshine does not restore it when virtualhid_control.exe itself reports gamepad unavailable.
Running:
pnputil /restart-device "ROOT\LIBVIRTUALHID\0000"
results in:
System reboot is needed to complete configuration operations!
and does not restore the backend without rebooting.
A full Windows reboot consistently restores:
gamepad available | mouse available | output reports available
and controller forwarding works again.
Expected Behavior
After Windows resumes from Sleep, I would expect the libvirtualhid Windows backend/control device to remain available or automatically reinitialize so that virtualhid_control.exe continues to report:
gamepad available | mouse available | output reports available
Sunshine should then be able to create its virtual Xbox controller without requiring a full Windows reboot.
Ideally, normal Sleep → Wake should restore libvirtualhid to the same functional state as a clean Windows boot.
Additional Context
System information:
Windows 11 — build previously observed as 10.0.26200.9445 (I can provide exact winver information if needed)
CPU: AMD Ryzen 7 9850X3D
GPU: AMD Radeon RX 9070 XT
Architecture: AMD64
libvirtualhid Virtual HID Driver: 2026.905.2300.20
Sunshine: 2026.906.222525
libvirtualhid lifetime license active
libvirtualhid Broker: Automatic / Running / Local System
Device instance: ROOT\LIBVIRTUALHID\0000
After resume, Device Manager still shows libvirtualhid Virtual HID Control Device. In one reproducible failure state there was no yellow warning icon, but the General tab displayed:
No drivers are installed for this device.
The Driver tab simultaneously continued to show:
Provider: LizardByte
Driver date: 9/5/2026
Driver version: 2026.905.2300.20
Digital signer: David Lane
I previously encountered a Code 43 state on this device as well. Disabling/re-enabling the device recovered that particular occurrence once, but this has not been a reliable recovery method for the current sleep/resume failure.
I also identified a separate Sunshine startup timing condition during troubleshooting. On some clean boots, virtualhid_control.exe was already healthy while Sunshine had initialized libvirtualhid as unavailable. Restarting only Sunshine immediately corrected that condition. I currently restart Sunshine approximately 30 seconds after Windows startup, which reliably handles that separate startup race.
I mention this to distinguish the two conditions: after Sleep/Resume, virtualhid_control.exe itself reports the libvirtualhid gamepad/output backend unavailable, so restarting Sunshine cannot resolve it.
My temporary workaround is a Windows Task Scheduler task triggered by Power-Troubleshooter Event ID 1 after resume. It reboots Windows, after which libvirtualhid consistently works again.
I have the complete %WINDIR%\Temp\libvirtualhid-umdf-driver.log and rotated logs available and am happy to provide them. I can also collect Windows DriverFrameworks-UserMode / Kernel-PnP events around a sleep/resume cycle if useful.
I would be happy to test a fix or provide any additional diagnostics. My main question is whether this is a known Windows UMDF/VHF sleep/resume issue or whether there is a supported way to reinitialize libvirtualhid after resume without rebooting Windows.
Describe the Bug
I am experiencing a reproducible Windows sleep/resume issue with libvirtualhid. After a clean Windows boot, libvirtualhid works normally and its own virtualhid_control.exe diagnostic reports:
Backend: windows-umdf | gamepad available | mouse available | output reports available
Controller forwarding through Sunshine/Moonlight also works normally in this state.
After putting the PC into normal Windows Sleep and waking it, virtualhid_control.exe changes to:
Backend: windows-umdf | gamepad unavailable | mouse available | output reports unavailable
The libvirtualhid Broker service remains Running.
Sunshine then fails to create its virtual controller and logs:
Warning: create libvirtualhid gamepad: create Windows virtual HID device: The handle is invalid
followed by:
Fatal: libvirtualhid gamepad support is unavailable and ViGEmBus fallback is not installed or running
I have also observed:
Warning: submit libvirtualhid mouse movement: submit Windows input report: The handle is invalid
Importantly, the failure can be reproduced in virtualhid_control.exe without Moonlight being involved, so this does not appear to be a physical controller or Moonlight issue.
Steps to reproduce:
Clean boot Windows.
Open virtualhid_control.exe and confirm gamepad, mouse, and output reports are available.
Controller forwarding through Sunshine/Moonlight works normally.
Put Windows into Sleep.
Wake the PC.
Reopen virtualhid_control.exe.
Gamepad becomes unavailable and output reports become unavailable, while mouse remains available.
Sunshine can no longer create its libvirtualhid Xbox controller.
Recovery attempts:
Restarting libvirtualhid Broker does not restore the backend.
Restarting Sunshine does not restore it when virtualhid_control.exe itself reports gamepad unavailable.
Running:
pnputil /restart-device "ROOT\LIBVIRTUALHID\0000"
results in:
System reboot is needed to complete configuration operations!
and does not restore the backend without rebooting.
A full Windows reboot consistently restores:
gamepad available | mouse available | output reports available
and controller forwarding works again.
Expected Behavior
After Windows resumes from Sleep, I would expect the libvirtualhid Windows backend/control device to remain available or automatically reinitialize so that virtualhid_control.exe continues to report:
gamepad available | mouse available | output reports available
Sunshine should then be able to create its virtual Xbox controller without requiring a full Windows reboot.
Ideally, normal Sleep → Wake should restore libvirtualhid to the same functional state as a clean Windows boot.
Additional Context
System information:
Windows 11 — build previously observed as 10.0.26200.9445 (I can provide exact winver information if needed)
CPU: AMD Ryzen 7 9850X3D
GPU: AMD Radeon RX 9070 XT
Architecture: AMD64
libvirtualhid Virtual HID Driver: 2026.905.2300.20
Sunshine: 2026.906.222525
libvirtualhid lifetime license active
libvirtualhid Broker: Automatic / Running / Local System
Device instance: ROOT\LIBVIRTUALHID\0000
After resume, Device Manager still shows libvirtualhid Virtual HID Control Device. In one reproducible failure state there was no yellow warning icon, but the General tab displayed:
No drivers are installed for this device.
The Driver tab simultaneously continued to show:
Provider: LizardByte
Driver date: 9/5/2026
Driver version: 2026.905.2300.20
Digital signer: David Lane
I previously encountered a Code 43 state on this device as well. Disabling/re-enabling the device recovered that particular occurrence once, but this has not been a reliable recovery method for the current sleep/resume failure.
I also identified a separate Sunshine startup timing condition during troubleshooting. On some clean boots, virtualhid_control.exe was already healthy while Sunshine had initialized libvirtualhid as unavailable. Restarting only Sunshine immediately corrected that condition. I currently restart Sunshine approximately 30 seconds after Windows startup, which reliably handles that separate startup race.
I mention this to distinguish the two conditions: after Sleep/Resume, virtualhid_control.exe itself reports the libvirtualhid gamepad/output backend unavailable, so restarting Sunshine cannot resolve it.
My temporary workaround is a Windows Task Scheduler task triggered by Power-Troubleshooter Event ID 1 after resume. It reboots Windows, after which libvirtualhid consistently works again.
I have the complete %WINDIR%\Temp\libvirtualhid-umdf-driver.log and rotated logs available and am happy to provide them. I can also collect Windows DriverFrameworks-UserMode / Kernel-PnP events around a sleep/resume cycle if useful.
I would be happy to test a fix or provide any additional diagnostics. My main question is whether this is a known Windows UMDF/VHF sleep/resume issue or whether there is a supported way to reinitialize libvirtualhid after resume without rebooting Windows.