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

What the player sees

While moving or turning, the view freezes for a split second and then jumps forward, as if a frame was dropped and then "rendered ahead". It repeats on a steady rhythm. The interval was about 5.4 seconds in this capture and between 2.5 and 5.4 seconds in earlier sessions. Frame-rate counters and frame-time tools show nothing wrong, because frames keep arriving on time. They just show the same view.

The step-through of the in-game recording during the measured stalls shows 8–10 identical captured frames (60 fps capture), followed by frames that move faster than normal to catch up.

Mechanism

1. On a timer of about 5.37 s, a VRageWorker thread (0, 1, 2, 6 or 9 in this capture) runs a job that enumerates input and HID devices and resolves their names.
2. Resolving device names makes Windows open and parse driver INF files: C:\Windows\INF\input.inf / input.PNF, …\DriverStore\en-US\input.inf_loc, hidserv.inf / .PNF / _loc, keyboard.inf_loc, and oem49.inf (Intel HID Event Filter). That's about 750 opens per run, and Windows Defender's file filter scans each one. The job costs about 130 ms of CPU.
3. The game's input thread waits for this job, so this code path blocks it. It's an unnamed thread that normally wakes about 4,200 times per second and spends its time in win32k and the USB stack. It leaves the CPU with wait reason WrAlertByThreadId (a user-mode wait for another thread) and stays off for 196–200 ms.
4. The worker readies the input thread the moment its job finishes. In 7 out of 7 stalls the thread that woke the input thread was the worker that had just run the enumeration.
5. While the input thread is blocked, the client keeps rendering (about 125 fps here) and the server keeps ticking, but no new input is applied. The camera holds still for about 200 ms and then the buffered input arrives in one step.

Timeline of the measured window

Every stall, measured

File events are counted for the game process from 50 ms before the wait to 50 ms after. Worker CPU comes from 1 kHz CPU sampling. Frame data is from PresentMon. "Video" is the matching freeze found by frame-differencing the in-game recording, which has about 1 s timing uncertainty and matched within 0.1 s.

What is not the cause

• Rendering: PresentMon shows a median of 8.0 ms between frames and 99th percentile 10.7 ms, with Independent Flip and V-Sync/G-Sync active. There are 24–25 presents inside every stall window.
• Simulation: SimulationFrameCounter advanced 3,600–3,601 per minute in clean minutes. Worst ServerSessionTime was 2.5–3.6 ms. The In-Process Server Thread never left the CPU for more than 15.8 ms.
• Main and render threads: they never left the CPU for more than 13 ms and 8 ms during the capture.
• .NET runtime: there were no garbage collections during the capture window and no lock contention events. GCStalls was 0 in every minute.
• Other software: a periodicity scan of every thread on the system found nothing outside the game on the 5.37 s rhythm. Windows, NVIDIA and Discord timers run on exact 5.00 s intervals and the audio engine runs at 5.12 s, which doesn't match. During each stall the only extra outside activity was Windows Defender, about 18 ms, scanning the INF opens.
• Settings: the stall was present with the 60 fps in-game limiter, with a driver 141 fps cap plus V-Sync and G-Sync, on the Balanced and High performance power plans, and with all third-party background utilities closed.

How to reproduce and confirm

1. Use a PC with several HID devices connected: a gaming keyboard and mouse with vendor software, a USB headset or DAC, a controller or receiver. More devices make the stall longer.
2. Load any world and keep moving or turning the camera continuously. A short hitch follows on a steady rhythm of a few seconds.
3. To confirm in a trace, run this from an elevated prompt while playing:

   wpr -start CPU -start FileIO -filemode
   (play for ~30 s)
   wpr -stop se2.etl

   In WPA, filter File I/O to SpaceEngineers2.exe and look for bursts of C:\Windows\INF\input.* / hidserv.* opens from VRageWorker threads. In CPU Usage (Precise), find the unnamed high-frequency input thread and sort by "Waits". Each long WrAlertByThreadId wait has the enumerating worker as its readying thread.
4. For comparison, unplug most HID devices. The stall should shrink.

Suggested fixes

• Don't block the input thread on device enumeration. Run it fully in the background and hand the result over without holding the lock the input path needs.
• Don't poll. Re-enumerate only when Windows reports a device change (WM_DEVICECHANGE / RegisterDeviceNotification, or the GameInput device callback), not on a fixed timer.
• Cache device names. Look up friendly names (the INF parsing) once per device instance, not on every enumeration.
• Consider instrumenting the input thread's wait time, so this kind of stall shows up in your own stats. Right now every frame-based metric looks clean while the player sees a freeze.

Related observation: spike capture files are not written

With the launch option -captureSpikes:25,30,1,0,0,1 the log shows [SpikeCapture] Spike Profiling enabled and 66 requested save lines (spike, render spike and periodic baseline). No .opt files appear in %APPDATA%\SpaceEngineers2\Temp\Spikes or anywhere else, and the log shows no error. If the release build is meant to support player-side spike captures, the save step seems to fail silently.

Environment

Plain-text version for the bug tracker

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).