Periodic input stall: the stall length scales with the number of input devices

Before and after

The scan interval is slightly shorter after the change. That fits the timer counting from the end of the previous scan, since each scan now finishes about 120 ms sooner.

What I removed

The 32 entries left are a SteelSeries gaming mouse (11) and keyboard (11), a USB microphone (3), the motherboard RGB controller (3), a USB audio device (2), a Bluetooth DualSense (1) and the Xbox virtual gamepad bus (1). A typical player with a gaming mouse, keyboard and headset will have a similar set or more.

Every stall in the new trace

In each stall the game's unnamed input thread (about 3,000 wakes per second during play) goes off the CPU with wait reason WrAlertByThreadId. It is readied about 77 ms later by the same VRageWorker thread that opened input.pnf, hidserv.pnf, keyboard.pnf, msmouse.pnf and buttonconverter.pnf under C:\Windows\INF. The INF open count is the same, 88, in every scan, which fits an unchanged device list being enumerated from scratch each time.

The INF open counts aren't directly comparable with the ~750 per scan in the first report. That capture used a heavier trace profile that recorded more file events per open. Only the stall durations are compared between the two runs.

What this means for a fix

• Players can't work around this. Removing two thirds of the devices only shortened the stall. The input thread is still blocked on every scan, and the remaining cost comes from a basic mouse, keyboard and headset.
• Players with more peripherals have it worse: HOTAS setups, wheels, button boxes, multiple receivers, and RGB or macro software that creates extra HID collections. At about 2.3 ms per entry, a 150-entry flight-sim setup would stall for around 350 ms every 5 seconds.
• The fix suggested in the first report still applies. Don't re-enumerate devices on a timer: use device-change notifications (WM_DEVICECHANGE / CM_Register_Notification / GameInput device callbacks) instead. If polling has to stay, run it so that the input thread never waits for it to finish, and cache device names and descriptions instead of resolving them from INF files on every pass.

How this was measured

wpr -start CPU.Light -start FileIO.Light -filemode
  (launch the game, load the same save, same position and mouse movement, ~45 s of play)
wpr -stop after.etl

I converted the trace with tracerpt and decoded context switches (CSwitch, ReadyThread) and file creates (FileIo/Create) for the game process. I used the same analysis as in the first report: off-CPU gaps over 60 ms on game threads with more than 100 wakes per second, the readying thread for each gap, and INF file opens around each gap compared with control windows. Windows Defender activity was negligible during the stalls in this run, and other processes showed no activity at the scan interval.

Plain-text version for the bug tracker

FOLLOW-UP: Periodic input stall scales with the number of input devices
Space Engineers 2, App 4.0.0.3169 · Windows 11 build 26200 · same PC, save, location and movement as the original report

WHAT I CHANGED
Removed 53 of 85 present input device entries (HIDClass + Keyboard + Mouse):
- Intel HID Event Filter (ACPI\INTC1070) and its child collections: 23
- Logitech receiver 046D:C52B with extra wireless keyboard/mouse: 11
- Logitech receiver 046D:C534: 8
- Flight stick, throttle, rudder pedals: 11
Remaining 32: SteelSeries mouse (11), SteelSeries keyboard (11), USB mic (3), motherboard RGB (3), USB audio (2), DualSense BT (1), Xbox virtual gamepad bus (1).

RESULT (Windows Performance Recorder, CPU.Light + FileIO.Light)
                              Before (85)    After (32)
Input thread blocked/scan     196-200 ms     76.5-79.3 ms (mean 77.6)
Scan interval                 5.367 s        5.183 s
Scans that stalled input      7 of 7         9 of 9
Released by scanning worker   7 of 7         9 of 9
INF opens between scans       0              0

=> About 2.3 ms of input-thread stall per device entry, with almost no fixed cost.

PER STALL (after)
02:30:18.377  76.9 ms  VRageWorker 2   88 INF opens
02:30:23.560  78.0 ms  VRageWorker 8   88
02:30:28.744  78.4 ms  VRageWorker 2   88
02:30:33.927  77.1 ms  VRageWorker 7   88
02:30:39.110  77.3 ms  VRageWorker 8   88
02:30:44.294  76.5 ms  VRageWorker 3   88
02:30:49.477  77.8 ms  VRageWorker 2   88
02:30:54.660  79.3 ms  VRageWorker 12  88
02:30:59.844  77.3 ms  VRageWorker 10  88
Control windows between scans: 0 INF opens.
Input thread waits with WrAlertByThreadId and is readied by the same VRageWorker that opened input.pnf, hidserv.pnf, keyboard.pnf, msmouse.pnf, buttonconverter.pnf in C:\Windows\INF.

CONCLUSION
The stall can't be removed on the player's side: a basic gaming mouse, keyboard and headset still give ~77 ms (about 5 frames at 60 Hz) with no input every 5 seconds, which is still clearly visible. Players with HOTAS, wheels or multiple receivers will see 200-350 ms+.
Suggested fix (unchanged): don't re-enumerate input devices on a timer. Use device-change notifications (WM_DEVICECHANGE / CM_Register_Notification / GameInput callbacks), never make the input thread wait for enumeration, and cache device names instead of resolving them from INF files on every pass.