Sudden FPS drops in games: finding what actually causes them

It was 140. Now it is 70 and it stays there until you restart the game — or until you stop, let the machine cool, and come back to find it fine.

That is a different problem from a stutter, and the confusion between the two costs people weeks. A stutter is one late frame in an otherwise healthy run — if that is what you have, why games stutter on Windows 11 is the page you want. A drop is a sustained change in how much work the machine gets done per second, and almost everything below announces itself if you watch the right numbers while it happens.

First, the honest sentence. Nothing on this page makes a game faster. It shows three traces Windows already keeps — display-driver resets, firmware holding the processor clock down, and the processor ceilings in your active power plan — which w0a's stutter scan reads for you, and how to read the same three yourself in a couple of minutes.

The three questions that split the whole field

Before touching a setting, answer these — each eliminates about half the list.

1. Does it recover on its own? A drop that clears after a minute of standing still points at heat or a background task. One that persists until you restart the game points at the game's own state or a driver event.
2. Does it happen in every game or one? Every game points at the machine. One game points at that game's settings, its update, or its servers.
3. Does it track time-in-session, or a place in the map? Time means heat and power. A place means the scene got harder, or something is loading.

Then watch clocks and temperatures while it happens rather than afterwards. A drop that is invisible in retrospect is obvious live: either a clock fell, or it did not.

Heat and the power ceiling

A cause to rule out when "it drops after twenty minutes".

Chips do not fail when they get hot, they slow down. When a temperature or a power limit is reached the clock is pulled down and held there for as long as the condition lasts. Firmware makes that call itself — the board's or the CPU's own protection, not Windows — so nothing in Task Manager explains it. On the graphics side the driver will name the reason if you ask it under load: thermal protection, a power limit set below stock, a program asking the driver to slow down, or a PCIe power connector not properly seated.

How you tell: it correlates with session length and room temperature, and the clock is visibly lower during the drop than at the start.

What you do: cooler mounting, dust, case airflow. Then check whether a power limit was lowered on purpose — in firmware, a vendor utility, or a saved graphics-card profile.

The machine changed power state

Laptops do this most obviously: unplug the charger and the platform moves to a different set of limits. It happens on desktops too — a changed power plan, core parking or a processor-state ceiling left behind by an older tuning script, a plan that reverted after a Windows update.

How you tell: the drop starts at an event — unplugging, a lid, a resume from sleep, a restart — not at a temperature.

What you do: put the plan's own defaults back rather than inventing new values. The Fix page has cards for the power plan and for the processor power settings, and each writes the Windows default unconditionally, whichever tool changed it.

A driver reset

The screen goes black for a second or two, comes back, and everything is slower — or the game has closed. Windows recorded the display driver hanging and being reset.

How you tell: this leaves a clear trace, and the stutter scan reports how many resets happened in the last day. The trail usually points at an overclock or at cooling, not at software.

What you do: if you have a memory or core offset applied, halve it and test one match; zero it and test again. GPU crash recovery covers the rest, including putting the Windows default back if an older tool raised the timeout instead of fixing the cause.

Three traces Windows already keeps

1. A display-driver reset (event 4101)

When the display driver stops responding and is reset, Windows writes event 4101 to the System log. The stutter scan counts those from the last 24 hours and reports them as its only critical finding; above ten it says "10+" rather than pretending to know the exact number. If the log itself cannot be read, the scan says the check could not run instead of calling the machine clean.

To look yourself, in PowerShell:

Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='Display'] and (EventID=4101) and TimeCreated[timediff(@SystemTime) <= 86400000]]]" -MaxEvents 10

If there are none, PowerShell answers with an error saying that no events match the selection criteria: that is the answer "none in the last day". If it says it cannot read the log, run PowerShell as administrator and try again.

The way back is the one in the section above: lower or remove an overclock, look at cooling, and GPU crash recovery if an older tool raised the driver's timeout. w0a will not raise that timeout itself: a longer watchdog only makes each freeze longer, and switching recovery off removes it altogether.

2. Firmware held the clock down (event 37)

Microsoft-Windows-Kernel-Processor-Power event 37 is the firmware recording that it pulled the processor clock down and held it there for whole seconds at a time; the event's own text says for how long. It matters because a temperature reading only shows the moment you look: a machine that throttled an hour ago and has cooled since reads as perfectly healthy, and this event is the only trace of that hour left on it.

The scan counts these from the last 24 hours, on mains power only — on battery the same event is the platform doing its job — and warns at three or more. One or two are common in the first seconds after boot, while the board settles its power limits.

Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Kernel-Processor-Power'] and (EventID=37) and TimeCreated[timediff(@SystemTime) <= 86400000]]]" -MaxEvents 20

Keep the provider name in the filter. Other components use the number 37 for unrelated events, and a count without the provider means nothing.

If you find a trail of these, the cause is heat or a power limit, as in the heat section above; CPU and GPU temperatures while gaming covers what to read, and on a laptop gaming laptop slow covers the charger and the power modes.

3. The active plan caps the processor

A plan's name is not what runs. "High performance" with the maximum processor state at 80% is a capped machine wearing the right label. The scan reads four settings from the processor section of whichever plan is active, on mains power:

The scan reads these through Windows' power interface rather than through powercfg, because on a standard install two of them are hidden and powercfg prints nothing at all for them. If none of the four can be read, the scan says it could not measure, not that the plan is clean.

To look yourself, in Command Prompt or PowerShell:

powercfg /getactivescheme
powercfg /query SCHEME_CURRENT SUB_PROCESSOR PROCTHROTTLEMAX
powercfg /query SCHEME_CURRENT SUB_PROCESSOR IDLEDISABLE
powercfg /query SCHEME_CURRENT SUB_PROCESSOR PERFBOOSTMODE
powercfg /query SCHEME_CURRENT SUB_PROCESSOR CPMINCORES

How to read the answers:

• The value is on the last two lines of the answer, in hexadecimal: the first is the value on mains power (AC), the second the value on battery (DC). 0x00000064 is 100, 0x00000050 is 80, 0x00000001 is 1, 0x00000000 is 0.
• The setting names around the numbers are printed in your Windows language; the aliases you type (SUB_PROCESSOR, PROCTHROTTLEMAX) are the same in every language.
• If the whole answer is a single line with the plan's GUID and nothing under it, the command is asking about a setting Windows hides on this install. That tells you nothing about its value; the stutter scan is the way to read it.

The way back, setting by setting:

• PROCTHROTTLEMAX or CPMINCORES written into Windows' own plans: the processor power settings card puts the minimum and maximum processor state and core parking back to each plan's own declared default, then re-applies the active plan, because Windows reads a plan's values when it is activated.
• A cap that lives in a plan some tool created: the power plan and battery card switches to Balanced first, so that plan stops being the one that runs, and deletes w0a's own plans.
• PERFBOOSTMODE or IDLEDISABLE: no repair card resets these two by name today. The way back is the plan itself, with powercfg, to the value the plan declares as its default.

It happened right after an update

Two very different things hide here.

A game or driver update invalidates the shader cache, and the game recompiles as you play. The frame rate is genuinely lower for a while and then it is not. It fades; that is the signature. Shader compilation stutter explains why, and why you should not benchmark inside that window.

A driver branch regression does not fade. Vendors do admit these in writing — release notes carry "lower performance in this title on branches newer than X" entries. Do not reflexively downgrade: finish your updates, measure on your own machine, and consider another version only if you can document the regression yourself.

Something else started running

A scheduled scan, an update worker unpacking, an archive extracting, a video export. It queues for the same cores as the game and, unlike a hitch, does not go away between frames — often reproducible at a certain time of day. Total CPU usage is the wrong number to look at: a single saturated core on an eight-core machine reads as a modest total. Wait it out, or move the work.

The frame rate did not actually drop

A cap. If the number you land on is exactly your refresh rate, your in-game limit or a driver-side limit, nothing is bottlenecked — you are at the ceiling you asked for.

Dynamic resolution. A game that scales its own render resolution to hold a target frame rate shows a stable counter while the image quality moves instead.

It is one game, and the counter looks fine

Then the drop may not be on your machine at all. An online match degrades for everyone on the server at once, and network trouble is not a frame-rate problem: packets arriving late make the world stutter around you while your machine keeps drawing at full speed. If frame times are healthy through the event, stop looking at the PC.

If instead the frame rate is simply lower than it should be while the graphics card sits idle, that is a separate diagnosis with its own list: GPU not at 100% works through it in order.

A run that produces an answer

1. Take a capture of a normal session before anything is wrong, and keep it. Reading the benchmark covers how, and why the average is the least useful number there.
2. When the drop happens, note clocks and temperatures during it, not after.
3. Change one thing, then reproduce the same scene and session length.
4. Judge against your own run-to-run variation. If three unchanged runs vary by more than the difference you are pleased about, you found noise.

What not to do about a drop

Do not raise the graphics driver's recovery timeout to hide a driver reset: it turns a short recovery into a longer freeze and removes the evidence. Do not disable cores or simultaneous multithreading on the strength of an unsourced guide — you would trade known multi-core capacity for a gain nobody has published a method for. And do not apply kernel memory-management values as a performance fix; this product refuses to write them, and no measurement supports them.

The same goes for power settings: none of the four above is a "performance" switch to flip the other way. Turbo off holds the processor at its nominal clock, and w0a's own scan flags idle states off as a limit too, wherever it finds them.

Related

• Why games stutter on Windows 11
• GPU not at 100%
• Shader compilation stutter
• GPU crash recovery
• What the stutter scan looks for
• CPU and GPU temperatures while gaming