Some players report sudden stutter and FPS drops linked to Windows’ GameInput services. We’re investigating why — and sharing what we learn along the way.
A clean Windows 10 test reproduced the buildup: one extra internal tracking entry for every request for controller state.
We reconnected the controller and verified that the list started empty. Our test program made 483 requests. All 483 initially had to wait, all later completed successfully, and the driver ended with 483 entries. None carried the test program’s ID in the field used to find and reuse them.
We saw no identical replies back to back after excluding their update number. This run reproduced the tracking problem without reproducing the suspected stream of unchanged replies.
In a separate run, 355 requests added 355 entries. Those entries were still there after the test program exited.
What comes next
Repeat the clean test with the missing ID initialized correctly. That new comparison is prepared but hasn’t run. Earlier debugger experiments showed reuse after the correction; an in-game FPS benefit remains unproven.
What we learned
Untouched doesn’t always mean unchanged.
Our debugger kept seeing controller activity even when nobody touched it. We now have a concrete clue: small variations in the stick readings before they reach Windows.
In one recording, the resting stick sat near the edge of its configured dead zone. Small changes took it across that edge, and Windows reported the corresponding jump. The sampled readings matched the expected conversion whenever the raw snapshots stayed stable across a check.
That helps explain activity from an untouched controller in this setup. The separate Windows tracking bug still matters: legitimate input changes can keep adding entries when they should be reused.
Lab finding
A small missing detail. A growing pile of extra work.
We can now reproduce a specific controller-driver problem in a Windows 10 test machine — and show that correcting one missing value changes its behavior.
Behind the scenes, Windows creates places for controller updates to wait. In the driver we tested, a missing detail means it keeps creating new ones for the same program instead of reusing the one it already has. That growing pile can make controller checks more expensive.
In earlier lab comparisons, correcting the missing value stopped that buildup and made some controller checks much quicker. Basic held-button, stick and vibration checks also worked with the correction.
The important bit
This is a temporary debugger experiment, not a fix you can download. It was tested with a PS3 controller through DsHidMini on one Windows 10 setup. We still need to show a benefit inside a real game and check controller behavior more thoroughly.
Our test machine also has an older GameInput revision than the reporting player’s machine. The matching driver gives us a useful lead, but it doesn’t make every part of the setup identical.
What we learned
Leaving the controller alone didn’t tell the whole story.
A fresh comparison with the controller left untouched showed little timing difference. That matters: the problem doesn’t mean every controller check is automatically slow.
After a 30-second moving-stick test, the uncorrected setup had accumulated thousands of internal entries. Checks for controller slots with nothing connected became roughly four to ten times more expensive than in the earlier idle test. That is a controller-call measurement, not an FPS multiplier.
Stopping GameInput Service afterward stopped the programs producing those entries, but left the accumulated entries and the extra cost behind. Restarting the service didn’t clear them either.
We haven’t run that exact continuous-movement test on a fresh corrected setup yet. It’s another useful clue, not a complete comparison or a reason to start changing services on your own PC.
From the community
A Left 4 Dead 2 report gave us a better trail to follow.
A player reported a large FPS drop and heavy stutter with GameInput Service enabled and a controller connected. Follow-up recordings compared the service off and on during the same Windows session, with the game still running.
When the player reported the stutter, the game was spending much more of its sampled time checking controllers and cleaning up after those checks. With the service disabled, that expensive path was much less prominent.
Those recordings helped us focus the investigation. They did not independently measure the reported FPS numbers, prove the driver caused that player’s entire problem, or establish a universal fix.
Starting the investigation
First, check whether the obvious explanation holds up.
One early idea was that GameInput might keep asking for the same controller state as fast as possible. Our Xbox-controller tests over USB and Bluetooth didn’t reproduce that suspected behavior. The tested requests waited for input updates.
That didn’t make the player reports go away. It told us to keep looking instead of treating an early theory as a confirmed cause. Repeated “rumble off” traffic was also an assumption, not something the original recording established.
We made the diagnostic tools easier to use and asked for reports captured while the problem was actually happening. The Windows 10 queue problem described above is a later, more specific finding.
Your report could help
Seeing the stutter? Come tell us about it.
Bring your controller model, how it connects, the game, and what happens. You don’t need to know whether GameInput is responsible.
If we ask for a recording, the default is a short five-second capture while the problem happens. Review it before sharing: recordings can include device details, user paths and other running apps. Nothing is uploaded automatically.
