What the stutter scan looks for

What it does

The scan reads what Windows and your drivers already recorded, and reports the things that are known to produce a hitch you can feel:

• drivers that held a processor core long enough to cost a frame
• a display running below the refresh rate it supports
• power settings that let a core drop to a speed it cannot recover from quickly
• background work scheduled at a priority that competes with a game
• settings some other tool left behind

Each finding says what was measured, why it matters and — where there is one — what to do about it.

Settings that changed

Each scan also notes a few settings that updates are known to change without asking: the memory speed (an XMP/EXPO profile), memory integrity, the power plan, hardware-accelerated GPU scheduling, the launch priority rules w0a set and the display driver version. The note stays on this computer, in %LocalAppData%\w0a\settings-drift.json. When a later scan finds one of them moved the way that can cost a game, or finds a new display driver, one card says what changed, since when, and whether Windows was updated in the same stretch. Nothing is changed back: if you made the change yourself, there is nothing to do. The card goes away after 14 days or once the setting is back. The first scan only takes the note, so there is nothing to compare until the second one.

What it does not do

It does not guess. If nothing measurable is wrong, it says so rather than filling the page with generic advice. A scan that always finds ten problems is selling you the fixes, not diagnosing the machine.

It sees only partly inside a game. Shader compilation, an asset streaming from a slow disk, a server-side hitch in an online match — these produce the same feeling and mostly leave no trace here. But if you have saved benchmark runs, the scan uses them as evidence: frames measured clearly slower than their neighbours show up as a finding of their own. If the scan is clean and you still stutter in one specific game, that is genuinely useful information: the cause is in the game, not the system.

Reading the labels

Every finding carries one of four words, and there are no percentages:

• PROVEN — measured on this machine, significant, and worth acting on
• LIKELY — the mechanism was measured or seen on this machine; whether it is what you are feeling was not measured
• CANDIDATE — present and known to be able to cause stutter, but nothing here proves it did
• NOT CHECKED — the rule could not run, so nothing is known either way

Fix the PROVEN items first, then re-run. Changing several things at once and re-measuring afterwards tells you nothing about which one helped.

NOT CHECKED is not clean. When rules could not run, one card says exactly how many — "N of M rules could not run" — and why. A scan with unrun rules has not looked at those causes at all.

Running it while a game is open

The page is safe to open mid-game. Hardware polling waits until the game closes — reading sensors takes a graphics-kernel lock and would itself cause a hitch every few seconds — while the ETW frame-time measurement keeps working. Rules skipped for this reason are reported as skipped; scan again with the game closed to cover them.

Related

• Reading the latency test
• Reading the benchmark