You have been through the list. Nothing is running, temperatures are fine, the drive is fast, the game is on an SSD, and the machine still jolts. Task Manager shows an idle system. The frame-time graph shows the late frame but says nothing about why it was late.
There is one cause that explains this exact shape, and it is invisible in every tool most people reach for, because it happens underneath them.
First, the honest sentence. The fix for a driver that holds a core is that driver, from its maker. w0a's part is the measurement, the file name, and repairing values that older tools left behind. The one switch it used to offer nearby, steering a device's interrupts to chosen cores, has been read-only since 8 October 2026, because no game A/B ever showed a frame gained by it.
What is actually happening
A device — a network card, a disk controller, a sound chip, a USB controller — needs the processor's attention. It raises an interrupt, and Windows runs the driver's interrupt service routine immediately. That routine runs above every thread priority there is: not "high priority", but outside the thread scheduler entirely. Nothing else can be scheduled on that core until it returns.
Because that is an expensive place to be, drivers are supposed to do the minimum there and defer the rest to a deferred procedure call — a DPC — which runs a moment later, still ahead of every thread on that core.
While either one is executing, that core draws nothing and reads no input. If your render thread was on it, your frame is late. If your mouse report was queued behind it, your input is late. And neither event appears in a task manager, because there is no process to attribute it to.
Why a millisecond is a lot here
The arithmetic is what makes this worth chasing:
- At 1000 Hz polling, a report arrives every millisecond. A 1 ms hold costs a report.
- At 240 Hz, a frame is 4.2 ms. A 1 ms hold is about a quarter of a frame's budget spent on nothing.
- At 4 ms and above, the machine cannot hold a steady frame time whatever else you change — which is why this belongs before every other item on your list, not after them.
Measuring it, and the two ways the measurement fails
w0a's Latency Test opens a kernel tracing session and records, for twelve seconds of real mouse movement, how long each driver held a core. It needs administrator rights. Why the test asks for twelve seconds covers the length; reading the latency test covers the colours.
Two results are not answers, and both are reported as such rather than being rounded down to "clean":
- The session could not be opened. An anti-cheat driver may have claimed kernel tracing for itself. Close the game and measure again.
- The session opened and delivered nothing. No running Windows has zero driver executions in twelve seconds, so this is a measurement that did not happen. Run it again.
There is a third, subtler one: a session that dropped events may have missed the worst execution entirely, so the page says the number may not be the true worst. This is the same principle the stutter scan applies everywhere — a rule that could not run is counted as not checked, never as clean.
The numbers, exactly
| Number | The rule |
|---|---|
| Test length | Twelve seconds by default: long enough to catch a driver that misbehaves once a second, short enough that you actually keep moving the mouse for all of it. |
| Enough mouse data | Two seconds of the device's own reports, and never fewer than 250 samples; for a 1000 Hz mouse that is 2,000. Below that, the 99th percentile is the second- or third-worst sample, not a statistic. |
| Driver verdict | A driver's worst single execution is marked as a warning from 1 ms and as critical from 4 ms. Those are the lines this field has used for two decades; they are a convention, not a measurement w0a made on your machine. |
| A complete measurement | The driver figures count as complete only when the kernel half ran and its logger dropped no events. A counter that refuses to answer is treated like a lossy run, not like a clean one. |
| The system floor | Mouse 99th percentile, plus half a refresh interval, plus the worst driver execution — the last only when the kernel half was measured, because adding zero for an unmeasured kernel would print a better-looking number exactly when the tool knows least. It is a floor, never a total: the game's own input sampling, its render queue, the GPU's work and the panel's response are all outside it. The input lag no software can fix is the rest of the chain. |
Reading the list
Each driver appears with its file name, its longest single hold, its share of the measured time, and how many times it ran. Sort by longest hold; that is the number that costs you a frame.
Two readings people get wrong:
- An amber line is not a problem you must fix. It is a candidate. With no symptom, it explains nothing, and plenty of healthy machines carry one.
- A long interrupt handler is worse than a long deferred call of the same length. During a deferred call other interrupts can still be serviced; during an interrupt handler, nothing at all gets in on that core. The page marks it when a driver's worst was an interrupt.
Which file is which, and what to do about each
The file name is the whole clue, and the family it belongs to decides the fix:
| Family | What it is | What actually helps |
|---|---|---|
| Wireless network | The Wi-Fi adapter's driver | The vendor's own driver rather than the generic one Windows Update supplies. A cable removes the line entirely. |
| Wired network | Motherboard or add-in NIC | The board vendor's driver. Turning interrupt moderation off is not a fix for this line: without it packets are no longer batched, every received packet raises its own interrupt, and the driver runs more often, not less. That is why the Internet page leaves interrupt moderation alone on machines with fewer than six physical cores — see network tweaks. |
| Storage | The controller in the path to your disk | On NVMe, try Windows' own driver and the vendor's, and keep the one the latency test shows lower. A third-party storage driver is worth removing. |
| USB | Host controller | Chipset drivers, and moving the mouse to a port on the board rather than behind a hub. |
| Audio | Codec, and anything layered on it | The vendor's driver; if it persists, Windows' generic audio driver usually lowers it. RGB and audio utilities run on this path. |
| Display | Graphics driver | The vendor's own site. If it started after an update, roll back to the previous version. |
| Windows' own components | Time spent on some other driver's behalf | Nothing to "update" on its own — fixing the drivers above lowers this line too. |
| Power management | The path that changes clock and idle states | Raising the processor minimum state and reducing C-state depth in firmware both shorten it, and both raise idle power draw. That is a trade, not a fix. |
A filter driver deserves its own line here. Traffic-shaping and connection-routing tools pass every packet through a driver of their own, and multi-second network hitches are their best-known side effect; the stutter scan names them when it finds them. The same applies to macro suites and lighting tools that install a filter in the mouse and keyboard path.
The fix, and the non-fixes
The fix is to update that one driver, from the hardware maker. Not the whole system, not through a driver-updater tool, and not by reinstalling Windows. The page names the file precisely so you can look up which device it belongs to.
What does not fix this, and is refused here for that reason: timer-resolution overrides, kernel memory-management values (DisablePagingExecutive, LargeSystemCache), and the registry lists that circulate under the word "latency". None of them changes how long a driver holds a core, because that is the driver's code doing the holding. Disabling devices at random is not a diagnosis either — though disabling one device as a test, with a measurement before and after, is a perfectly good experiment. The same goes for the device-level values that circulate with these lists: MSISupported switches a device's interrupt mode, and set wrong, the result can be a black screen, so w0a never writes it, and the interrupt-steering repair card below leaves it alone.
The two settings w0a touches nearby
Device interrupt policy: read-only, with a repair card
Where Windows keeps it: per device, under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\<device>\<instance>\Device Parameters\Interrupt Management\Affinity Policy. DevicePolicy (DWORD) chooses how the device's interrupts are placed; when it is 4, "specified processors", AssignmentSetOverride is the mask of processors they may use.
Windows default: neither value present. Windows then computes the placement itself, and Microsoft recommends the default policy wherever it applies.
What w0a does: it reads these values and does not write them. Since 8 October 2026 the steering it used to offer from the Latency Test page is gone, for three reasons: no game A/B showed a frame gained by it, Microsoft recommends the placement Windows computes, and a wrong mask is a device that does not start.
Way back: if a tool pinned a device's interrupts and something broke — a mouse dropping out, "Code 10" in Device Manager — the device interrupt steering card deletes both values from every PCI device, including steering left by older w0a versions. It asks for a restart only when it actually removed something, and it leaves MSISupported alone.
"Under load: flow control, interrupt moderation, segment coalescing off" (Internet page)
What it writes: 0 to the network adapter's *FlowControl keyword on every adapter that declares it. *InterruptModeration, *RscIPv4 and *RscIPv6 are written only on machines with at least six physical cores, and only on adapters known to run below 2.5 Gbit/s; on those machines it also switches segment coalescing off at the network-stack level, unless it is already off.
Why moderation stays on smaller machines: with moderation and coalescing both off, every received packet becomes its own interrupt instead of one per moderation interval, and the deferred-call load lands on the core that receives. So switching moderation off is not a way to shorten the network driver's line in the Latency Test: by w0a's own description, what it removes is the wait of tens to hundreds of microseconds a packet spends in the adapter until the batch timer runs out, and what it adds is an interrupt per packet. Its effect on the driver list has not been measured. If the network driver is your line, run the test with the box applied and without it.
What the box itself promises: microseconds, on ping under load. Its message says average ping does not change.
When it applies: when the adapter restarts; w0a asks for a restart whenever it wrote something.
Way back: the network adapter offloads card puts offloads, interrupt moderation, Energy Efficient Ethernet, selective suspend and receive buffers back to the driver's own defaults, as the driver declares them.
Check it yourself
These commands only read. In Command Prompt or PowerShell:
reg query "HKLM\SYSTEM\CurrentControlSet\Enum\PCI" /s /v DevicePolicy
reg query "HKLM\SYSTEM\CurrentControlSet\Enum\PCI" /s /v AssignmentSetOverrideEnd of search: 0 match(es) found. means no device carries an override: Windows' default. A match is listed under the key it was found in, and the PCI part of that path identifies the device.
In PowerShell, for the network adapter:
Get-NetAdapterAdvancedProperty -Name "*" -RegistryKeyword "*FlowControl","*InterruptModeration","*RscIPv4","*RscIPv6" -AllPropertiesThis lists each adapter's current setting for the four keywords the Internet page box can write. An adapter that does not appear for a keyword does not declare it, and the box writes nothing there.
Then measure again
Same method, same twelve seconds, same machine. The page compares against your previous run and reports a change under 5% as no change rather than as an improvement, because two runs on an untouched machine differ by a few per cent anyway — a hand moves differently each time.
If the driver line came down and the stutter did not, you have learned something real: this was not your cause, and why games stutter on Windows 11 has the rest of the list. If what you have is a frame rate that falls and stays down rather than a jolt, it was never this — sudden FPS drops in games is that list instead.
Related
- Reading the latency test
- Why games stutter on Windows 11
- How to reduce input lag: what software can and cannot shorten
- What the stutter scan looks for
- Why the latency test asks for twelve seconds
- Network tweaks
Playing CS2? Which launch options still do anything, and where the frames really are in the video menu: How to fix CS2 stutter and low FPS: a measured checklist
Did this page help?
What was missing, or what did not work? We read every one of these.
If this page did not solve it, write to us — say which article you read, and we will fix the article.