Skip to content

Issue #32 startup-log diagnosis — 2026-09-08

Historical record. This preserves the source, tests and limitations recorded at the time; it is not current setup guidance. See the documentation index.

Read-only review of DS4Windows #32, its comments, and all six attached text logs against current source 50c45e0f18e46ad275b63dd7fe4d989e0d9a8f19. The text attachments were read in memory; no raw logs or controller identifiers are committed. The separately linked approximately 500 MB process dump was not acquired or analyzed. No application, controller, service, task, or driver state was changed.

What each log establishes

Times below are the logs' own local timestamps, with one-second resolution. They are stage boundaries, not end-to-end latency measurements.

Attachment Observed sequence Supported conclusion
June 22 stuck Version 4.0.2.3; permanent X360 slot configured; ViGEmBus connected and Shared Mode logged at 18:24:00; attachment ends there. No precise blocked call is identified. This is the old ViGEm path, not VIIPER.
June 22 working Same version/permanent slot; Shared Mode and virtual X360 attachment both logged at 18:30:18; attachment ends immediately afterward. The extra output line is a real divergence, but the excerpt does not establish completed physical-controller admission. Permanent outputs can initialize before discovery.
July 14 stuck and broken Version 4.0.2.3; Shared Mode 07:58:46; physical DS4 v1 Bluetooth found 08:01:03 (137 seconds later); output association fails 08:01:07 with ViGEm plugin error -2147467259; shutdown follows. This run contains both a long pre-admission interval and an explicit old-backend output failure. The log does not identify the native call causing the first interval or prove ownership of the reported ghost controller.
July 14 worked, XInput slot 2 Shared Mode, physical discovery, virtual attachment, and association all logged at 08:01:16. The output message explicitly names XInput slot #2 and output slot #1. Those are different numbering domains, not a contradictory log. The reporter's observed second XInput slot agrees with the attachment.
July 14 worked after waiting Shared Mode 08:06:25; controller found 08:08:52; virtual output/association 08:08:53. The 147-second pre-discovery interval includes the reporter's deliberate delay before connecting the controller; it must not be counted as a demonstrated program stall. Discovery-to-association is about one logged second.
August 17 slow Version VIIPERRC4.3; backend ready/Exclusive Mode 08:11:35; DS4 v1 Bluetooth found 08:11:54; virtual Xbox 360 attached/associated 08:11:56. Physical output write fails with LastErrorCode=5 at 08:11:56; Steam Input reclaim times out 08:12:11; disabled/not-submitted speaker-control messages repeat afterward. Of the 21 seconds from Exclusive Mode to association, 19 seconds precede the Found Controller line, while about 2 seconds follow it. This does not demonstrate 20 seconds spent constructing the virtual pad. Later output/reclaim/audio errors are separate observations, not an explanation proved for the earlier delay.

The reporter also explicitly says the VIIPER version solved most earlier problems. The old ViGEm failure and the later VIIPER-era delay must not be collapsed into one asserted root cause.

Source interpretation and existing coverage

  • In both historical v4.0.2.3 and current ControlService, permanent output initialization precedes physical discovery. Therefore the first two minimal logs do not alone pinpoint a HID or virtual-output API. Current startup can also perform other setup before discovery; the 19-second boundary is not proof that one specific HID call consumed the whole interval.
  • DS4Devices.findControllers logs Found Controller only after enumeration, candidate filtering/opening, serial lookup, PrepareDS4Init, PostInit, and PostDS4Init. For an ordinary DS4, DS4Device.PostInit includes calibration and initial effect output. Current HidDevice.ReadSerial uses a synchronous native serial/feature query; Bluetooth RefreshCalibration can make up to five synchronous feature reads. Exclusive opening also has a device re-enable fallback. These are candidates within the uninstrumented boundary, not established causes in the attached logs.
  • Current OutContTypeCompatibility.Normalize maps old X360/DS4 settings to VIIPER. The July ViGEm plugin error is not a current-runtime error to repair by reintroducing or resetting ViGEm.
  • The already-implemented #83 correction prevents active USB/Bluetooth Steam Input reclaim restarts. It removes the Bluetooth restart mechanism implicated by the later reclaim-timeout line, but does not prove the earlier pre-admission delay fixed.
  • The already-implemented #84 correction restores the control pipe for ordinary Bluetooth DS4 effect reports while preserving the separate audio writer. It addresses a source-backed mechanism compatible with physical write failures; LastErrorCode=5 alone does not establish that it caused this reporter's failure, and does not prove a faulty controller or Bluetooth adapter.
  • Repeated speaker-control failures show unsuccessful audio activation. Their occurrence after association cannot explain the preceding 19 seconds. Current audio/transport ownership has changed substantially since RC4.3; no new audio rewrite is justified by that old sequence alone.

Decision and useful next evidence

No speculative production fix is proposed for #32. Existing fixes address narrower, demonstrable mechanisms, not every symptom in this multi-version report.

If the delay remains on a build containing the current fixes, collect a fresh full log with Verbose Startup Logging enabled. Existing AssignInitialDevices begin/end, DS4Devices.findControllers dispatch begin/end, and per-controller/output markers distinguish permanent-output setup from discovery and later association. Also record whether the controller was already awake/connected when startup began, the selected output mode, and whether this was logon startup or a manual launch. The posted attachments contain no [StartupDiag] markers, despite the earlier request to enable them.

If a new trace brackets the delay inside discovery, the next bounded development step is opt-in cold-start phase timing around enumeration, open/re-enable, serial lookup, calibration, and initial output—not a guessed timeout, retry loop, or forced disconnect. A hang dump captured while the delay is actually present can identify the blocked managed/native stack; review its private contents before sharing it. Current logs do not prove a hardware fault, the exact blocking API, or that more threading would solve the problem.