Why games stutter on Windows 11 (and how to find the real cause)

Your counter says 160. The game jolts anyway — a fraction of a second where the picture stops, your aim lands somewhere you did not put it, and then everything is fine again. The counter never moved, which is why nothing you do to raise it helps.

That gap is the whole subject of this page. Stutter is a frame that arrived late, not a low frame rate. A frame counter averages over a second, so one frame that took 90 ms disappears inside the 159 short ones next to it. The number that describes what you felt is the frame time, and a stutter is a frame much slower than its neighbours.

First, the honest sentence. Two of the ten causes below map to a single box in w0a: the scheduler value in cause 8 and the background game recorder in cause 9. Both boxes only put a setting where it belongs, and on a machine nobody has tuned, the first one finds nothing to change. Whether the stutter you feel was one of them is something only a capture before and after can tell you.

First, work out which of three problems you have

They get called the same word and have almost nothing in common.

• Hitching. The baseline is fine and something long happens every so often. That is this page.
• A rough baseline. Nothing is dramatic, but the game never feels smooth. That is a percentile problem: high average FPS but bad 1% lows.
• A drop. The frame rate falls and stays down for seconds or minutes. Different causes entirely: sudden FPS drops in games.

Get a record before you change anything

Guessing is what makes this take weeks. A capture of the game you actually play, where it actually stutters, turns "what could it be" into "what happened at that spike" — and it is the "before" every later change is judged against. Reading the benchmark covers how.

The causes, one by one

1. A driver holding a processor core

While a driver is inside an interrupt or a deferred procedure call, that core runs above every thread priority there is: it draws nothing and reads no input until the driver lets go. It is easy to miss: it appears in no frame-time graph and in no task manager.

How you tell: measure it. The kernel section of reading the latency test lists every driver that held a core, by longest hold, with the file name. Past about 1 ms a driver is displacing input reports; at 4 ms and up the machine cannot hold a steady frame time whatever else you change.

What you do: update that one driver from the hardware maker — not the whole system, the named file. Network, storage and audio drivers are among the drivers that can do this.

2. Shaders compiling

New effect, new area, new weapon, and the game has to compile a shader before it can draw it. The compile happens on the CPU while the frame waits.

How you tell: it is worst in the first minutes of a session or a map, it fades as you play, and it returns after a driver or game update. If your stutter does not fade, this is not it — shader compilation stutter is the long version.

What you do: play through it, and do not benchmark inside that window; you would be measuring the compiler.

3. The disk the game streams from

A game pulling assets in as you move stutters when the read is slow, and the frame waiting on that data is the late one.

How you tell: hitches line up with entering a new area, and long frame intervals fall in the same window as disk activity. Check the obvious things: is the game on a mechanical disk, is the drive nearly full, is the game folder inside a cloud-synced folder that uploads every write, is the page file on a spinning disk. An SSD for a streaming game is not a tweak, it is the answer.

4. Memory pressure

When RAM fills, Windows moves pages out to disk and the pages coming back are felt as hitches. The less obvious case is the commit limit: as the total memory Windows can hand out runs low, the memory manager trims pages away from programs that are still running, and the game feels those trims as sub-second freezes. Both improve the moment you close a browser with forty tabs.

5. Something else running

Windows Update's worker, a maintenance task, a scheduled malware scan, a video export you forgot about. That work does not stop when a game starts; it queues for the same core as the render thread, so it shows up as frame-time spikes rather than a lower average. Waiting it out is a legitimate fix.

How you tell: a benchmark capture keeps its longest frame intervals with the disk work and hard faults that fell into the same window. When those were Windows maintenance or antivirus processes, the long-interval card counts the intervals and names the processes. That is what fell together, not proof that the work made the frame late: the antivirus reads whatever any program opens.

6. Heat and power limits

When a chip hits its temperature or power ceiling the clock is pulled down and pushed back up repeatedly, and wavy frame times are what that feels like from the inside. Firmware makes this call itself, without asking Windows. It starts after a while rather than immediately, and it tracks how warm the room is.

7. The display

A monitor running below the refresh rate it supports puts a floor under your frame pacing that the hardware does not require. Check the actual rate rather than assuming; it is wrong on a surprising number of machines after a fresh install or a cable swap.

8. A scheduler value left behind by an older tool

Win32PrioritySeparation decides how long a thread keeps the processor and how much more time the foreground application gets. Values with long or fixed quantums, or a foreground share below 3:1, change how the processor is shared between the game and everything else; what that does to frame times has not been measured. The Fix page's Memory and system defaults card puts the Windows default back.

9. Overlays and the capture layer

Overlays draw inside the game's own frame, and a background recorder encodes every frame so the last few minutes can be saved. Close them one at a time and test, rather than all at once.

10. The match, not the machine

An online game can hitch for everyone on the server at once. If single-player content on the same machine is clean and the frame-time record shows the game presenting normally, that is a genuinely useful answer: it is not your PC.

The two causes w0a has a box for

Cause 8: "Keep foreground priority at the right value (Win32PrioritySeparation)" (Optimizations page)

One DWORD value: Win32PrioritySeparation under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl.

Microsoft's reference for it is an archived page written for Windows 2000; it describes six bits read in three pairs, written AABBCC:

• Windows default: 0x2 (binary 000010). On a workstation edition that means shorter, variable intervals with the foreground program getting three times the time of the background. The same reference gives 0x26 (100110: shorter, variable, 3:1) for the performance-options choice that favours applications, and 0x18 (011000: longer, fixed, equal) for the one that favours background services.
• What the box does: it reads the value first. A value that already gives the 3:1 foreground share, without longer intervals and without fixed intervals, is left exactly as it is, and the box says so. Only a value that fails one of those three is rewritten, to 0x26. On Windows' own default the box writes nothing: on a client edition 0x2 already schedules the way 0x26 asks for.
• When it applies: after a restart. The kernel turns this value into its scheduling table at boot, so changing it in the registry changes nothing about the scheduler that is already running, and the box asks for a restart when it writes.
• Way back: the memory and system defaults card writes 2 back and asks for a restart. It restores other memory and scheduler defaults at the same time.

Cause 9: "Disable Xbox Game DVR" (Optimizations page)

All are DWORD. On a dual-CCD X3D processor the box leaves the last value alone: the recording pipeline is still switched off, but the Game Bar piece that AMD's driver listens to stays running. That is a precaution, not a proven cause, and the box's message says which path it took. Ryzen X3D, Game Bar and core parking explains why that piece matters on those chips.

• When it applies: w0a asks for no restart for this box.
• What you give up: Game Bar recording. If Win+G stops opening or you want recording back, the Game Bar / game capture card turns Game Bar and Game DVR back on with Windows' defaults.
• What the stutter scan says: it notes, as information, when GameDVR_Enabled or AppCaptureEnabled is still on; both are 1 on a clean install, so this is the default, not a fault. It also reads a third value, HistoricalCaptureEnabled (background recording), but only to choose its wording; the box does not write that value.

Check it yourself

These commands only read:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl" /v Win32PrioritySeparation
reg query "HKCU\System\GameConfigStore" /v GameDVR_Enabled
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\GameDVR"
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\GameDVR" /v AllowGameDVR
reg query "HKCU\Software\Microsoft\GameBar"

How to read the answers:

• Values are printed in hexadecimal: Win32PrioritySeparation REG_DWORD 0x26 means 0x26.
• 0x2 is Windows' default and 0x26 is the applications setting from the reference; on a client edition both schedule the same way. 0x18 is the background-services setting: longer, fixed intervals and no foreground share, which is what cause 8 is about. For any other value, write it as six binary digits and read the table above.
• For Game DVR, 0x0 means off (the box) and 0x1 means on (Windows' default).
• If the AllowGameDVR query ends with an error instead of a line, the policy value does not exist, which is Windows' default.

What the scan does with all this

What the stutter scan looks for runs these checks against what Windows and your drivers already recorded, and labels every finding as proven, likely, a candidate or not checked. Two things worth knowing: a scan that always finds ten problems is selling you the fixes, and a check that could not run is counted rather than quietly treated as clean.

Then change one thing and capture the same scene again. Five changes and one measurement tell you nothing about which one mattered, and anything that did not move a number should be undone.

Things that are not the cause

These circulate endlessly as stutter fixes, and w0a refuses to write every one of them, for reasons on record:

• DisablePagingExecutive, LargeSystemCache and DisablePageCombining change the kernel's memory manager; NtfsMemoryUsage changes the NTFS driver's pool; IoPageLockLimit and SecondLevelDataCache are kernel assumptions too. Kernel-level values are a product rule: never written.
• GlobalTimerResolutionRequests lives under Session Manager\kernel, a key the product refuses outright.
• MSISupported switches a device's interrupt mode; set wrong, the result can be a black screen.
• FeatureSettingsOverride and FeatureSettingsOverrideMask switch off the Spectre and Meltdown mitigations.
• OverlayTestMode and DisableOverlays switch off multi-plane overlay. On a real Windows 11 25H2 machine they froze CS2 hard and repeatably.
• TdrDelay and TdrDdiDelay lengthen the graphics-driver watchdog, which only makes each freeze longer; TdrLevel switches recovery off.

On a machine that is not short of memory, a memory cleaner changes nothing measurable.

Related

• Sudden FPS drops in games
• Shader compilation stutter
• Reading the latency test
• What the stutter scan looks for
• High FPS but bad 1% lows
• DPC latency and driver hitches
• Undoing changes