Experiencing Complete Control Loss After Close/DC of Moonlight And Reconnect with DualSense

Start with playstation_feature_reports.hpp and the Virtual HID device create/destroy path implicated by the VhfDelete traces. Reproduce the DualSense feature-report sequence using the attached logs, then trace ownership and cleanup around the reported buffer corruption. The issue is complete when reconnecting after Moonlight closes restores controller input without invalid-handle errors, driver crashes, or heap corruption.

Describe the Bug

Setup:

I have Moonlight configured on a SteamDeck that speaks to Sunshine on my Windows 11 PC. It works fine under most conditions and I've recently updated both Sunshine and Moonlight to the latest versions and also upgraded to libvirtualhid for conducting these tests.

When I connect my PS5 controller while having Steam Input disabled on the Steam Deck for Moonlight, the connection works as intended. If I disconnect and close Moonlight on the Steam Deck and then attempt to reconnect, the libvirtualHID driver fails its connections repeatedly and no inputs arrive to Sunshine. This requires a system reboot to resolve when it occurs.

I've attempted this with both the PS5 controller, Steam Controller, and a mix of both -- this occurs every time the second session is started. The only exception is if SteamInput is enabled on Moonlight, in which case the issues don't crop up, but then the PS5 controller is treated as an Xbox Series X controller instead.

If I set the Gamepad Drivers in Sunshine to "All Available Drivers" it does successfully but silently switch to VigEmBus when this occurs causing the pads to be treated as Xbox 360 controllers.

This occurs regardless of which controller is used on the second session, but always requires the first connection to have been from a PS5 controller to yield issues on the second connection.

Once this issue occurs, the following logs repeat 1000s of times a minute in the Sunshine log file.

Any ideas?

[2026-10-17 12:45:09.706]: Warning: create libvirtualhid gamepad: create Windows virtual HID device: The handle is invalid.
[2026-10-17 12:45:09.706]: Warning: libvirtualhid could not create the requested gamepad profile, and ViGEm fallback cannot emulate auto
[2026-10-17 12:45:09.709]: Info: Gamepad will be Xbox Series controller (default)
[2026-10-17 12:45:09.709]: Info: Gamepad 0 will be Sunshine (libvirtualhid) X-Box Series Controller
[2026-10-17 12:45:09.709]: Warning: create libvirtualhid gamepad: create Windows virtual HID device: The handle is invalid.
[2026-10-17 12:45:09.709]: Warning: libvirtualhid could not create the requested gamepad profile, and ViGEm fallback cannot emulate auto

I've confirmed that the issue is reproducible, occurs even on the latest beta branch libvirtualhid pre-release 2026.1016.55.45 as well as the stable release.

In additional testing I've also found it sometimes occurs even on a fresh load with a PS5 controller not using Steam Input following a fresh reboot even without the disconnect.

Expected Behavior

Controller works when moonlight connects - whether that is a first connection or on a subsequent reconnection.

Additional Context

Crash log evidence:
sunshine.log:

[2026-10-17 13:56:30.511]: Info: Gamepad 0 will be Sunshine (libvirtualhid) PS5 Controller
[2026-10-17 13:57:07.625]: Info: CLIENT DISCONNECTED
[2026-10-17 13:57:29.256]: Warning: submit libvirtualhid mouse movement: submit Windows input report: The handle is invalid.
[2026-10-17 13:57:29.660]: Warning: create libvirtualhid gamepad: create Windows virtual HID device: The handle is invalid.

[2026-10-17 11:00:44.917]: Warning: Gamepad auto is disabled due to gamepads.virtualhid-not-available
[2026-10-17 11:01:54.770]: Warning: Virtual HID Driver is selected but is unavailable or unlicensed; ViGEmBus fallback is disabled by configuration

Crash that occurred without any previous controller connect/disconnect (only occurred in one test):

[2026-10-17 15:15:08.964]: Info: Gamepad 0 will be Sunshine (libvirtualhid) PS5 Controller [2026-10-17 15:15:10.855]: Warning: submit libvirtualhid gamepad gyroscope: submit Windows input report: The handle is invalid.

Windows Event Logs:

Faulting application name: WUDFHost.exe, version: 10.0.22621.5624, time stamp: 0x324ae8d4 Exception code: 0xc0000374 Fault offset: 0x000000000010d5f9

A problem has occurred with one or more user-mode drivers and the hosting process has been terminated. The device libvirtualhid Virtual HID Control Device (location (unknown)) is offline due to a user-mode driver crash. Windows will attempt to restart the device 5 more times.

Driver trace: C:\Windows\Temp\libvirtualhid-umdf-driver.log

every time a DualSense is destroyed, the trace ends at VhfDelete. By contrast, Xbox Series devices get through it almost instantaneously.

Xbox Series:

2026-10-17T18:06:42.030Z [39] delete_vhf_device begin status=0x00000000
2026-10-17T18:06:42.030Z [40] delete_vhf_device VhfDelete status=0x00000000
2026-10-17T18:06:42.030Z [41] delete_vhf_device WdfObjectDelete target status=0x00000000

DualSense at crash:

2026-10-17T18:06:49.534Z [50] create_device success status=0x00000000 2026-10-17T18:07:30.146Z [52] destroy_device found status=0x00000000 2026-10-17T18:07:30.146Z [53] delete_vhf_device begin status=0x00000000 2026-10-17T18:07:30.146Z [54] delete_vhf_device VhfDelete status=0x00000000

Every subsequent request after repeats:

broker service identity: open requestor process failed status=0x00000000

Memory dump shows the block is damaged/zeroed out after the Dualsense firmware feature report is issued.

Error type:    HEAP_FAILURE_FREELISTS_CORRUPTION
HEAP 000001bb8cb30000 (Seg 000001bb8cb30000) At 000001bb8cb36940 Error: invalid block size

07 000000527d27f0e0 00007ffa7393ccf6 msvcrt!calloc_impl+0x85 09 000000527d27f150 00007ffa73ad8bcf msvcrt!__CRTDLL_INIT+0xe7

000001bb8cb36900 20 4a 75 6c 20 20 34 20-32 30 32 35 31 30 3a 31 Jul 4 202510:1
000001bb8cb36910 30 3a 33 32 03 00 04 00-10 13 00 00 2a 00 10 01 0:32........*... 000001bb8cb36920 01 c8 00 00 00 00 00 00-00 00 00 00 30 06 00 00 ............0...
000001bb8cb36930 3c 00 01 00 0a 00 02 00-06 00 00 00 00 00 00 00 <............... 000001bb8cb36940 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................`

The pattern seems to match the expected output of playstation_feature_reports.hpp's byte pattern right before the crash which may point to that triggering heap corruption.

raw memory dump available on request.

I hope this is helpful and appreciate you digging into it!

lvh-crash-share.zip

sunshine-prerelease-failure.log