Skip to content

Reclaim Steam Input loops Bluetooth DS4 restarts and leaks VIIPER virtual controllers #83

Description

@anagnorisis2peripeteia

Describe the bug

ReclaimSteamInput=True causes connected Bluetooth DS4 controllers to enter a restart loop with HidHide enabled.

Each loop disconnects the physical controller with error 1167. VIIPER then creates another virtual controller before the next restart.

In one live reproduction, the system accumulated seven present VIIPER virtual controllers before DS4Windows was stopped.

To Reproduce

  1. Install VIIPERRC4.4 and HidHide 1.5.230.
  2. Add DS4Windows.exe to the HidHide application list.
  3. Enable HidHide cloaking.
  4. Start Steam.
  5. Set ReclaimSteamInput=True.
  6. Connect a DS4 controller through Bluetooth.
  7. Observe the repeated disconnect, reclaim, and reconnect cycle.

The issue reproduced with two Bluetooth controllers at the same time.

Expected behavior

Automatic reclaim must run at most once for the applicable controller generation.

The expected PnP restart must not clear the reclaim guard and start another reclaim.

Screenshots and Logs

The following sequence repeated every few seconds for each controller:

Found Controller: <redacted> (BT) (DS4 v.1).
HidHide persistent hiding enabled for DS4 v.1 (...)
Plugging in virtual Xbox 360 Controller in output slot #N
Associated input controller #N ...
Reclaimed DS4 v.1 from Steam Input; reconnecting its hidden HID collection.
<redacted> disconnected due to read failure: 1167
Gamepad data write connection is lost. Disconnecting the gamepad. LastErrorCode=1167
Disassociated virtual Xbox 360 Controller ...
Unplugging virtual Xbox 360 Controller ...
Found Controller: <redacted> (BT) (DS4 v.1).

The source explains the repeated reclaim:

  • QueueSteamInputReclaim stores a cooldown entry in steamInputReclaimAttempts.
  • A successful pnputil /restart-device causes the normal disconnect path.
  • ReleaseHidHideManagedDevice removes the same entry for every bound instance ID.
  • The reconnect therefore queues another successful restart before the intended ten-second guard can apply.

Desktop:

  • Controller: two Bluetooth DS4-compatible controllers; Windows reports Sony VID 054C
  • Connection: Bluetooth through a TP-Link USB adapter
  • OS: Windows NT 10.0.26200.0
  • DS4Windows: VIIPERRC4.4, tag 4d41a61
  • HidHide: 1.5.230
  • Steam: running during reproduction

Additional context

Setting ReclaimSteamInput=False stopped the loop immediately.

HidHide remained enabled. DS4Windows.exe remained whitelisted. Both physical controllers remained hidden.

After the change, an eight-second stability check reported zero new error 1167 events and exactly two virtual controllers.

A live Dolphin check then found zero physical DS4 handles and two virtual Xbox controller handles.

Possible fixes include skipping active Bluetooth devices, as the code now does for wired devices. Another option is to preserve a successful reclaim marker across the expected disconnect.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions