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.

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 — measured, and on most machines it causes what you are feeling; on yours it may not
• 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