#658
Issues/nonary/Vibepollo/#658

VHF gamepad: sleeping with a VHF controller present bugchecks 0x9F/3 in vhf on 2.0.2-daily.d20261018.1 (fix is in libvirtualgamepad#4)

OpenRandomUserGemopened 16d ago

Bug Symptoms

The host was put to sleep (SetSuspendState, S3) during a stream. A VHF virtual controller existed at that time. The PC never finished entering sleep. About 4 minutes later it bugchecked with DRIVER_POWER_STATE_FAILURE 0x9F, subcode 3. It did not restart by itself (AutoReboot = 1), so Wake-on-LAN could not reach it. It stayed down until someone pressed the power button 16 hours later.

This matches Nonary/libvirtualgamepad#4 ("fix(vhf): delete controllers before VHF powers down, so sleep cannot bugcheck") in every detail. That PR has been open since 2026-10-05. Vibepollo pinned libvirtualgamepad v0.1.0-beta.9 in f6f2c5299d (2026-10-17), and the nightly 2.0.2-daily.d20261018.1 ships it as driver 0.1.0.53, without that fix. #462 (the virtual gamepad fails after sleep) is related, but there was no bugcheck in that report.

Timeline (local time; the old Vibepollo log is one hour behind because the time zone changed after the service started):

timeevent
00:20:26VHF gamepad 1 created as an Xbox Series controller on the XInput path (no removal after this)
01:38:49Kernel-Power 187/42, sleep requested by a third-party sleep tool through SetSuspendState while the stream was running
01:38:50–58No displays were found after reenumeration, Failed to locate an output device, then CLIENT DISCONNECTED
01:39:08Fatal: Hang detected! Session failed to terminate in 10 seconds. Stuck waiting for: audio thread
01:40:29User mode was still running. My watchdog task found HTTPS 47984 hung and restarted ApolloService.
01:41:56LiveKernelReports\ResourceTimeout-20261022-0141.dmp
~01:43Bugcheck (EventLog 6008: last alive 01:42:59). No automatic restart.
17:51Power button pressed: cold boot, Kernel-Power 41 BugcheckCode 159, SleepInProgress 4

The minidump (102226-11546-01.dmp). WinDbg is not installed there, so I decoded the triage data blocks myself.

BugCheck 9F, {3, ffffce0e59adf060, fffff80584c9e590, ffffce0e906f5770}
PDO ffffce0e59adf060 device stack (bottom -> top): \Driver\PnpManager -> \Driver\vhf -> \Driver\WUDFRd
  = ROOT\VIBESHINEVIRTUALGAMEPAD\0000 "Vibeshine Virtual Gamepad", vibeshinevhfgamepad.inf 0.1.0.53 (10/16/2026),
    signer "Nonary Nightly VHF Gamepad Signing"
Blocked IRP ffffce0e906f5770: IRP_MJ_POWER / IRP_MN_SET_POWER, DevicePowerState D3,
  current stack location at \Driver\vhf (already passed down by \Driver\WUDFRd)

vhf.sys is 10.0.26100.8972, the same version as in the PR's analysis.

The "Stuck waiting for: audio thread" teardown hang appeared while the system was half-asleep. It may be a separate issue, or only a side effect of the stuck sleep.

Expected Behavior

The PC sleeps normally, or at least does not bugcheck, when a VHF controller exists. Possible fixes:

  1. Ship libvirtualgamepad#4 (or an equivalent EvtDeviceD0Exit cleanup) and bump the pinned driver.
  2. As a stopgap on the host side, release the VHF controllers (close the driver handle) on PBT_APMSUSPEND. The PR notes that controllers are already deleted on file close.

Steps to reproduce

  1. Host: Vibepollo 2.0.2-daily.d20261018.1+cd17e1f3912a, gamepad = vhf, Vibeshine Virtual Gamepad 0.1.0.53.
  2. Stream from a Moonlight client with a controller attached, so the host logs VHF gamepad N created ....
  3. While the controller exists, put the host to sleep with SetSuspendState (the Start menu or the idle timeout should take the same path, per the PR).
  4. The display goes off and user mode keeps running, but the PC never sleeps. After about 4–5 minutes: 0x9F/3, faulting stack at \Driver\vhf.

This happened once here. I did not try to reproduce it on purpose, because the PC stays down until someone is physically there. Earlier sleeps resumed normally: 16.10 and 17.10 with the previous driver 0.1.0.48, and 19.10 with 0.1.0.53. I did not check whether a VHF controller existed during those.

Windows Version

25H2 (Windows 11 Pro, build 26200.9711; WUDFRd.sys 10.0.26100.9711)

Package

Windows - exe installer

GPU Type

NVIDIA

GPU Model

RTX 3070 Ti

GPU Driver Version

32.0.16.1742

Capture Method

Windows.Graphics.Capture (Windows)

Apps

Desktop

Logs

Host log (Debug), old process (clock one hour behind local time):

[2026-10-21 23:20:26.464]: Info: Gamepad 1 will use the Vibepollo virtual gamepad driver
[2026-10-21 23:20:26.465]: Debug: Connected to the Vibepollo virtual gamepad driver
[2026-10-21 23:20:26.465]: Info: VHF gamepad 1 created as an Xbox Series controller on the XInput path
...
[2026-10-22 00:38:50.187]: Error: No displays were found after reenumeration; retrying with backoff.
[2026-10-22 00:38:50.711]: Error: Failed to locate an output device
[2026-10-22 00:38:58.522]: Info: CLIENT DISCONNECTED
[2026-10-22 00:39:08.665]: Fatal: Hang detected! Session failed to terminate in 10 seconds. Stuck waiting for: audio thread

Windows System log:

01:38:49 Kernel-Power 187  SetSuspendState (SystemAction 2, LightestSystemState 2)
01:38:50 Kernel-Power 42   The system is entering sleep. Sleep Reason: Application API
01:40:29 SCM 7034          The Apollo Service service terminated unexpectedly.
17:51:47 Kernel-Power 41   BugcheckCode 159, BugcheckParameter1 0x3, SleepInProgress 4, PowerButtonTimestamp 0
17:51:52 EventLog 6008     The previous system shutdown at 1:42:59 on 22.10.2026 was unexpected.

I can share the minidump if that helps.

Activity

2
Nonary16d ago

Host-side recovery is now merged in https://github.com/Nonary/vibeshine/pull/333 (merge863469a1daa1e587c66bc3907a506156f1de256d). When an existing VHF connection reports ERROR_DEVICE_REMOVED, the host can recreate its currently owned controllers transactionally and restore held input and battery state. Our final cloud review caught and repaired an additional partial-battery-update edge case; production-adapter tests now exercise actual DS4/DS5 producer semantics.

This does not fix or establish the cause of the kernel 0x9F/3 bugcheck itself. The separate producer power-lifecycle work adapted from libvirtualgamepad#4 is in https://github.com/Nonary/libvirtualgamepad/pull/8; a merged host change is not proof that a corrected signed driver has shipped. I am keeping this issue open without a fixed label and am not asking you to repeat an unattended crash. The host change is entering Vibepollo migration/release validation; I will follow up with precise build and driver inclusion evidence rather than claim the next nightly necessarily fixes the sleep crash.

RandomUserGem5d ago

Tested on Vibepollo 2.0.4 with Vibeshine Virtual Gamepad 0.1.0.92 (libvirtualgamepad v0.1.0-beta.10, which includes #8 and 44996ea): the crash did not reproduce. This is one run, under the conditions that crashed before.

Setup. The same sleep tool (SetSuspendState), with two clients streaming. One client had VHF gamepad 2 created as an Xbox Series controller on the XInput path 1 min 46 s before sleep, and it was never removed. The other client had a DualSense on the USB/audio transport. On driver 0.1.0.53 this PC bugchecked with 0x9F three times (10-22, 10-26, 11-01), each in a sleep during a stream. I decoded the 10-22 and 11-01 dumps as 0x9F/3; for 10-26 I only have bugcheck code 159 from Kernel-Power 41.

Result.

  • Kernel-Power 187 and 42 at the moment of the call, then a real sleep for 6 min 52 s (Power-Troubleshooter Sleep Time / Wake Time). No half-asleep period: ping stopped 8 s after the call and SSH within 25 s.
  • The router saw the port at 10 Mbit (WoL standby) for the whole sleep, including past the 5-minute mark where it used to crash.
  • Wake-on-LAN woke it. Ping answered 17 s later, and the boot time was unchanged.
  • No new minidump, no new LiveKernelReports, no Kernel-Power 41.
  • A new stream afterwards connected, and VHF gamepad 0 created as an Xbox Series controller was logged within a second, with no errors. ROOT\VIBESHINEVIRTUALGAMEPAD\0000 stayed OK, so #462 did not show up either. I checked this from the host log and did not verify button input separately.

One thing I'd like to check with you. VHF keyboard/mouse did not come back after that sleep:

Warning: VHF keyboard/mouse stopped during driver recovery; using Windows SendInput for subsequent events
Warning: VHF device removal recovery is waiting for the driver [00000015]

These were logged at sleep time. About 15 minutes after wake, with a new stream running, VHF\HID_DEVICE_SYSTEM_VHF\...VIBESHINEKEYBOARDMOUSE is still not present (CM_PROB_PHANTOM), and the log has no line saying it recovered. Is it intended to stay on SendInput until the service restarts? I haven't tried a restart. This would matter only for keyboard and mouse in anti-cheat games, which is why VHF is the default for them now.

From my side the bugcheck can be closed. I'll comment again if it comes back.