System-Wide Fix for Gaming Mouse Fluidity in Windows 8.1

You have upgraded to Windows 8.1 from Windows 8, and noticed bad performance from your gaming mouse? More input lag and worse fluidity, even when dragging windows around on the desktop, not just in video games?

You’re not alone.

There is now a system-wide solution. Follow KB 2908279 Instructions, install the hotfix (skip that step if already installed), and then add c:\windows\explorer.exe to your registry in Step #4. Although Explorer is not a game executable, this solution enables the high report rate (e.g. 1000Hz) system-wide from your gaming mouse in all your applications. This fixes all fluidity including window dragging, scrollbar dragging, etc.

UPDATE: Microsoft has modified the page.
You may have the Microsft update already installed. A better step by step:
Instead of C:\Program Files (x86)\Game\Engine.exe, enter C:\Windows\Explorer.exe

With this fix, your mouse will perform as well as it did under Windows 7 and Windows 8.
NOTE: If anyone from Microsoft is reading this, see Comments for scientific explanations why 1000Hz is better for window-dragging/scrolling, even on a 60Hz or 120Hz monitor.
Also, see the new Blur Busters Mouse Guide.

About Chief Blur Buster

Head of Blur Busters.

21 comments on “System-Wide Fix for Gaming Mouse Fluidity in Windows 8.1

  1. Chief Blur Buster says:

    Earlier this week, I upgraded from Windows 8 to Windows 8.1.
    I immediately noticed fluidity problems, even when dragging windows or dragging scrollbars.

    Even with the Microsoft’s gaming mouse fix (KB 2908279 and KB 2908279), dragging windows and dragging scroll bars is NOT as smooth as before. Just doing these fixes alone, DID NOT solve the problem alone. Something more had to be done. Knowledgeable in math, also a hobbyist vision researcher, and as a display tester — Microsoft made a miscalculation here thinking 1000Hz mice was useless at the desktop.

    With a 1000Hz mouse, everything ran very smoothly and window movements was really smooth. Now the report rate seems to be limited to 100Hz or 200Hz, and that creates some nasty framerate-aliasing effects with 120hz and 144Hz. Microsoft should have kept Window dragging at full mouse report rate (500Hz or 1000Hz), because of less framerate-aliasing (stutter) with the monitor’s refresh rate.

    One could easily keep the mouse report rate at 1000Hz and take:
    – At 120Hz, every 8 or 9 out of the 1000Hz mouse (1/120sec= 8.3ms)
    – At 144Hz, every 7 or so out of 1000Hz mouse (1/144sec = 6.9ms)
    – At 60Hz, every 16 or 17 out of 1000Hz mouse (1/60sec = 16.7ms)
    In these situations, the mathematic error is only 1 millisecond worth of mouse movement. e.g. At a mouse movement of 2000 pixels/second, 1000Hz means about 2 pixels per mouse movement. So the mouse mis-positioning error (if a mouse position “rounds-off” to the wrong refresh) is as little as only 2 pixels.

    However, I feel that Microsoft messed up and chose a report rate of 100Hz or 200Hz during Windows manipulation (dragging windows, dragging scroll bar, etc) which is noticeably less clear than before. At 200Hz, you’ve a math error of 5 millisecond worth of mouse movement. e.g. At a mouse movement of 2000 pixels/second, 200Hz means about 10 pixels per mouse movement. So the mouse mis-positioning error (if a mouse position “rounds-off” to the wrong refresh) is as huge as 10 pixels (relative to where the human eye is tracking, when smoothly dragging a window, while tracking your eyes on it). Mis-positioning errors show up as continuous stutters.

    There appears to be dozens of stutters occuring per second, as it looks “jittery” (or “blurrier” — because the jitteriness is at a high frequency). When dragging at 1200 pixels/second at 120Hz, if you had a good mouse on a good surface, it should drag the window in fairly even 10 pixel increments (1200 / 120 = 10). Smooth would be 10 pixel, 10 pixel, 10 pixel, 10 pixel, in each subsequent monitor refresh (maybe with +/- 1 or 2 pixels, due to hand movement erraticness, mouse sensor limitations, and mouse pad issues). However, the way Microsoft has done it, it drags forward 15 pixels, then 5 pixels, then 10 pixels, then 12 pixels, then 6 pixels, and so on. That’s what is happening in Windows 8.1.

    Big stutter (error of +/- 10 pixels) is much worse than small stutter (error of +/- 2 pixels). The use of 1000Hz reduces stutters caused by aliasing between the mouse-rate and the refresh-rate. That’s why a 1000Hz mouse is much smoother than 200Hz mouse, even at Windows desktop. I don’t think the Windows programmers were smart enough to realize this before motion-fluidity-sensitive users like us.

    Especially as us 120Hz users and gaming mouse users, are sensitive to stutters and are complaining about this — even at the Windows desktop!

    This stutter problem is especially apparent when using monitors with ultra-clear CRT-like motion — such as gaming monitors with strobe backlight LCD’s. (e.g. LightBoost blur reduction, EIZO Turbo240 strobing in FG2421, or BENQ XL2720Z Blur Reduction strobing), gaming monitors that eliminate motion blur.

    I still detect these Windows 8.1 mouse stutters even at 60Hz. It’s just that mouse fluidity is far more massively degraded for 120Hz and 144Hz users (on a relative basis), since there’s some nasty aliasing between the refresh rate and mouse rate (which create microstutters when dragging windows or dragging scrollbars)

    Often on many of these ultraclear-motion computer monitors, text remain readable while scrolling (e.g. Internet Explorer up/down arrow key smooth scrolling). Just like on a CRT in the old CRT days. Dragging windows, text stayed this clear too (text remained readable while dragging window, with a 1000Hz mouse on a strobe-backlight gaming LCD)

    Note: The microstutters occur so rapidly at 120Hz and 144Hz, they kind of blend into a motion blur. Which is enough to make text unreadable when dragging window. The 200Hz mouse is 5x more stuttery than the 1000Hz mouse. So because of this, someone at Microsoft may say “it looks fine”. So here’s a more specific scenario that shows a startling dramatic difference:

    Extreme reproduction Scenario, Two separate computers, Test side by side:

    1. Obtain two 120Hz or 144Hz monitor, such as one from
    2. Obtain two good 1000Hz mouse, configure them to run 1000Hz
    3. Enable the clearest motion mode on that monitor (e.g. LightBoost, Turbo240, etc)
    4. On computer #1 in Windows 8, drag browser window around briskly, while trying to read web page text in window. Text remains fully readable (just like when dragging window on a CRT).
    5. On computer #2, in Windows 8.1, drag browser window around briskly, while trying to read web page text in window. Text is no longer readable because it looks so stuttery. Microstutter (mouse positioning error) in window movement is about 5x worse (e.g. window position inconsistency caused by aliasing effect between mouserate and refreshrate)
    6. The difference is startlingly dramatic when tested this way, especially with two people dragging a window at the same time on these two separate systems.

    Yes, the above is just an extreme scenario, designed to show dramatic differences in a simulataneous side-by-side test that makes it dramatically easy to see the difference. Others can still see the problem even at just 60Hz, and in less demanding use cases. One ought to realize that different people are more sensitive, so even in less dramatic use cases than the above, are still greatly bothered by the degradation of Windows 8.1 mouse fluidity.

    It’s possible Microsoft may think this is unimportant, but I would hope they realize gamers a valuable target audience for Microsoft, and they also speak pretty loudly, as well. Especially when computers get higher end equipment (better monitors, better mice, etc).

    Just in case someone at Microsoft think 200Hz is enough — There are vision researchers that have found that humans can also tell imperfections that gradually disappear when going higher frame rates 250fps vs 500fps vs 1000fps indirectly via motion blur effects and stroboscopic effects. Vendors such as sells scientific displays with a 500Hz refresh rate. Even when one thinks that humans can’t tell apart high frame rates, side effects are constantly discovered. A good educational site is and the 15+ selectable motion tests at the upper-right corner.

    Without the fix I described, window dragging and scrollbar dragging, the moving text is never as clear as TestUFO text scrolling animation. With a gaming mouse AND the fix, the text now becomes as clear as the left half of the text scrolling animation, since the high report rate ensures fewest harmonics (worst-case stutter amplitude) between mouse rate and refresh rate.

  2. sleetish says:

    Just wanted to note a correction, it’s KB 2908279 instead of 290879

    Thanks for all your work on this and other things to help everyone get the best experience possible.

    • Chief Blur Buster says:

      There’s plenty of room to go faster, there’s no technological reason why we can’t go to 10KHz someday theoretically, but points of diminishing returns are already here today at 1000Hz.

      1000Hz is really good for fewer temporal-aliasing effects between the timing of the frames, and the timing of mouse positions. That’s why a 1000Hz mouse is really good for variable frame rates (VSYNC OFF), GSYNC, high refresh rates, strobe backlights.

      When turning at 2000 pixels/second on-screen panning motion in a first-person shooter game:
      — For a 125Hz mouse, two consecutive mouse coordinates would be 16 pixels apart (2000 / 125 = 16).
      — For a 1000Hz mouse, two consecutive mouse coordinates would be ideally 2 pixels apart (2000 / 1000 = 2).

      That means during math rounding errors, a frame may be stuttery by +/- 16 pixels with a 125Hz mouse during turning one-screen-width-per-second (on a typical 1920×1080 monitor). Meaning, if the mouse position rounded-off to the wrong frame, the positioning of objects in that specific frames may be “off by 16 pixels”. That creates potentially stuttery motion. However, at 1000Hz, the error becomes only 2 pixels.

      That’s why you get super-silky smooth 180 degree flicks (preferably if the mouse has an accurate sensor, you use low in-game sensitivity, and high hardware mouse sensitivity), where you flick the mouse and turn 180 degrees in a first person shooter game.

      We’re already really at the point-of-diminishing returns for mice at the moment. However, if we go to high-refresh-rate 4K, I think a doubling to 2000Hz would be a good idea, since the difference between a 500Hz mouse and a 1000Hz mouse will be more amplified for a 4K 120Hz display, since you’ve doubled the mouse-position math roundoff inaccuracies. (e.g. a 180 degree flick can go faster than 4000 pixels per second on-screen panning motion. That leads to mouse positioning errors of +/- 4 pixels for a ‘perfect 1000Hz sensor’ that rounds off to the wrong refresh. And sensors are actually far less perfect than that. In this case, the most sensitive competitive players may begin to notice the limitations of 1000Hz.

      As it stands now, most people can’t tell apart a 500Hz mouse and a 1000Hz mouse (I can; but just barely). But the difference will be easier to tell when people are playing at 120fps on a 4K 120Hz display (within 10 years), and we’ll have more room for humans to be able to tell apart a 1000Hz mouse and a theoretical future 2000Hz mouse. I don’t think the world is ready yet for a 2000Hz mouse, however. But it will be useful in the high-framerate 4K era. Especially when 180 degree flicks (in 1/2 second) can go 10,000 on-screen pixels per second. At this screen panning speed, a 1000Hz math rounding error is now as massive as 10 pixels. So, truly, this shows possible human-perceptible limits of a 1000Hz mouse.

      A 125Hz mouse actually often works better with Quake Live, because it’s in sync with its internal locked framerate, and some players prefer configuring a 125Hz rate, in fact! However, when you play variable frame rates, odd frame rates, fluctuating frame rates, VSYNC OFF, GSYNC, or anything that produces math aliasing (round-off errors) between the mouse polling and the frame rate, it’s known a very good 1000Hz mouse with an accurate sensor, performs far better in these situations. Motion at all random frame rates have less stutters caused by this issue.

      And a pro competitive gamer (who tried dozens of mice) have wisely told me, a good 500Hz mouse (poor sensor) blows away a bad 1000Hz mouse (good sensor). So sensor accuracy is a big factor.

      Scientifically, I’m interested in seeing scientific tests of multi-KHz mouse polling (e.g. 1000Hz versus an experimental 5000Hz mice), to see if they actually work better for any realistic worst-case situations of today’s limited equipment (no 4K 120Hz).

    • Chief Blur Buster says:

      It’s apparent in this test for me:
      — Close all games and other apps. Drag a window back and forth, with lots of text in the window. Microstuttering in the window dragging.
      — Open a game or a 1000Hz-fixed app (including the mouse tester). Now drag the same text window around. Microstuttering stops.

      The 1000Hz measurement utilities doesn’t predict lack of Windows 8.1 mouse microstutters with a 1000Hz mouses, as those apps may be whitelisted. The mouse microstutters are very noticeable in LightBoost mode (which allows me to read text CRT-style, while dragging a window); I can’t read text while dragging a window in unpatched Windows 8.1.

  3. dreamss says:

    ok.. made a working .reg that adds a context right click menu to exe files that adds them to the mouse fix list

    download and copy exes to c:\windows\
    save this as mousefixcontext.reg and run it
    right click on .exe and click on apply mouse fix

    Windows Registry Editor Version 5.00

    @=”Apply Mouse Lag Fix”

    @=”\”C:\\Windows\\nircmd.exe\” elevate cmd /c REG ADD \”HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\” /v \”%1\” /d NoDTToDITMouseBatch /f && Rundll32 apphelp.dll,ShimFlushCache “

  4. Pingback: [Sammelthread] Battlefield 4 - Seite 1423

  5. PanzerIV says:

    Hi guys! I’m wondering something, when I try to install this (KB 2908279) update, it says it doesn’t apply for my system even though I’m not stupid and know that I currently use 8.1 64bit so what’s wrong??? I’ve looked in the Control Panel and I don’t see the update listed as those already installed so I don’t know where else to look around.

    I always do all Windows Updates including the optionnal ones so does it mean I already have it?

      • Chief Blur Buster says:

        You are all good and set for the KB installation!
        However, you still want to install the registry tweak if you want to ensure system-wide 1000Hz performance, including dragging windows which looks noticeably smoother at 1000Hz especially when combined with a motion blur eliminating strobe backlight (e.g. LightBoost, EIZO Turbo240, NVIDIA ULMB, or BENQ Blur Reduction).

        • PanzerIV says:

          You were right Chief! Even though the update was still installed, I don’t know what was the point of it as it didn’t fixed anything on it’s own. I still did the registry trick for “Explorer.exe” and then I suddently noticed a big difference even on my (BenQ GW2450) 60Hz monitor that I’ve overclocked to 71Hz. I then wanted a proof that it wasn’t just a placebo effect so I re-openned my 2 main mouse tools which you can see from the link below and the results were different than before. Something weird is that before I make the registry fix, the upper-left corner program “DirectInput Mouse Rate” would show me 1000Hz as if it was all okay but the other program from 2009 would peak out at 125-200Hz then just after the fix it went back up to 1000Hz!

          I really don’t know wtf Microsoft thought when doing this and it’s sad as 99% of the people won’t know about it. I can understand for a laptop but it shouldn’t do this on a PC and even less when you selected “High Performance” power mode in the control panel.

          Just to make sure, any games that have (Raw Input On) won’t need the shortcut in the registry to work at 1000Hz right? Thanks again, you’re a very valuable genious to the geek community and because of you I’ve finaly been able after so long, to take a decision on which gaming monitor would be the best for me “BenQ 2411Z with firmware v2” and which overclockable 2560×1440 IPS monitor would be the best for my photography buddy 🙂

  6. MarkC says:

    My testing of the recent Windows 8.1 Update (8-April-2014, KB2919355) shows that Windows 8.1 no longer has the mouse lag reported here : It no longer coalesces and merges mouse input, and tools like MouseRate.exe ( shows the full mouse polling rate, at least for Windows 8.1 running on a desktop PC.

    In other words, it is back to the Windows 7/8 behaviour.

    Possibly it now works differently on laptops or tablets than it does for desktops?

    Does anybody (with a laptop or tablet or otherwise) care to test it?
    (After removing the system-wide “Explorer.exe” given here in this post of course.)

  7. Pingback: Polling rates capped in Win8 - Hardware Canucks

  8. ChrisDiGi says:

    Alright so I added the C:\Windows\Explorer.exe at step 4 like you said but do I stop there and restart my computer or do I continue with the rest of the steps he had up there?

  9. ronaldjeremy says:

    I just started having bad mouse cursor lag after updating to Windows 10. That led me here — unfortunately though it wont let me install KB 2908279 on Windows 10. Any idea how to get around that?

Add Comment