Periodic input stall: device enumeration blocks the input thread every ~5.4 seconds

TITLE: Periodic camera/input freeze (~200 ms every ~5.4 s): input-device enumeration on a VRageWorker blocks the input thread

GAME: Space Engineers 2, app 4.0.0.3169, offline single-player

OS: Windows 11 build 26200 · CPU: Intel 12th-gen i7 · GPU: NVIDIA RTX 50-series, driver 621.14 · 1440p/144 Hz, G-Sync

SYMPTOM

While moving, the view freezes for a split second and then jumps ahead, on a steady rhythm (about 5.4 s in this capture, 2.5–5.4 s in other sessions). FPS counters and frame-time tools show nothing, because frames are presented on time with identical content.

ROOT CAUSE (measured with Windows Performance Recorder, 36 s capture)

1. About every 5.37 s, a VRageWorker thread (0/1/2/6/9) runs a job that enumerates input/HID devices and resolves their names. Each run opens about 750 Windows driver INF files (C:\Windows\INF\input.inf/.PNF, DriverStore\en-US\input.inf_loc, hidserv.inf/.PNF/_loc, keyboard.inf_loc, oem49.inf = Intel HID Event Filter) and costs about 130 ms of CPU. Defender scans each open.

2. The game's input thread blocks on that job. It's an unnamed thread that normally wakes about 4,200 times/s in win32k and the USB stack. It leaves the CPU with wait reason WrAlertByThreadId for 196–200 ms.

3. In 7 of 7 stalls, the readying thread that releases the input thread is the worker that just finished the enumeration.

4. While it's blocked, rendering (about 125 fps) and the server tick continue, but no input is applied: about 200 ms of identical view, then a catch-up jump.

PER-STALL DATA (input thread blocked / duration / waker / INF opens / frames presented in window / longest frame gap)

23:01:05.544 199.1 ms VRageWorker 1 746 25 8.7 ms

23:01:10.910 200.5 ms VRageWorker 2 762 25 9.6 ms

23:01:16.277 196.7 ms VRageWorker 6 762 24 10.9 ms

23:01:21.644 196.6 ms VRageWorker 0 761 24 9.0 ms

23:01:27.010 200.0 ms VRageWorker 0 753 25 9.3 ms

23:01:32.377 197.3 ms VRageWorker 9 745 24 9.4 ms

23:01:37.743 196.0 ms VRageWorker 1 762 24 9.7 ms

Control windows between stalls: 0 INF opens, input thread not blocked.

Every stall matched a freeze in the frame-by-frame video analysis.

NOT THE CAUSE

- Rendering: median 8.0 ms between presents, p99 10.7 ms (Independent Flip, V-Sync + G-Sync).

- Simulation: 3,600/min, worst ServerSessionTime under 3.6 ms, In-Process Server Thread never off-CPU for more than 15.8 ms.

- .NET: no GCs in the window, no contention events, GCStalls = 0.

- Other processes: a system-wide periodicity scan found nothing else on the 5.37 s rhythm.

- Same with the in-game 60 fps cap, the driver 141 fps cap, V-Sync on/off, Balanced/High performance power plans, and all background utilities closed.

WHY IT VARIES BY PC

Enumeration time grows with HID device count: about 750 INF opens per scan for 85 present entries, roughly 9 per device. This system has 69 HIDClass, 10 Keyboard and 6 Mouse entries (gaming keyboard and mouse, 2 wireless receivers, flight stick/throttle/pedals, USB mic, and the Intel HID Event Filter with 23 child entries), so players with gaming peripherals are hit hardest.

SUGGESTED FIX

- Don't hold the input path's lock (or wait on the result) during device enumeration. Run it fully asynchronously.

- Re-enumerate on device-change notifications (WM_DEVICECHANGE / GameInput callbacks) instead of on a timer.

- Cache device friendly names per instance instead of re-resolving them through INF parsing every time.

HOW TO CONFIRM

Elevated: wpr -start CPU -start FileIO -filemode, play about 30 s, wpr -stop se2.etl. In WPA, look for bursts of C:\Windows\INF\input.* / hidserv.* opens from VRageWorker threads, and long WrAlertByThreadId waits on the high-frequency input thread whose readying thread is that worker.

RELATED

With -captureSpikes:25,30,1,0,0,1 the log shows "Spike Profiling enabled" and 66 "requested save" lines, but no .opt files are ever written (Temp\Spikes stays empty, no error logged).