Ryzen Laptop Fans Spike Every Time You Open the Start Menu After KB5121003

You open the Start menu. Two seconds later the fans on your Ryzen laptop audibly spin up, then settle back down. You close the menu, do nothing else, and open it again — the fans do the same thing again. Nothing is installed, nothing is downloading, Task Manager shows CPU usage sitting at four percent. And yet the machine sounds like it is compiling something.

If this started in the last week or two and you are on a Zen 4 mobile chip — a Ryzen 7 7840U, 7940HS, or one of their siblings — this is almost certainly not a fault. It is a Windows feature doing exactly what it was designed to do, on hardware that makes the design very audible. Here is what it is, how to confirm it, and what your actual options are.

The symptom, described precisely

Precision matters here, because there are three or four unrelated problems that all sound like "my fans ramp up for no reason." What we are describing has a very specific fingerprint:

• The spike is tied to a UI action, not to a background task. Start menu, Windows Search, Action Center, and — since the August update — launching almost any application.
• It lasts roughly one to three seconds, then stops on its own.
• CPU utilization does not climb. Task Manager may still read single-digit percentages while the fans are audible. This is the detail that convinces most people something is broken.
• It is repeatable on demand. Open the Start menu ten times and you get ten spikes.
• It began after a specific update, not gradually.

If your fans are running continuously, or ramping while the laptop sits untouched, or getting louder over weeks rather than starting on a particular day, stop reading — that is a different problem and the section near the end of this article covers where to look instead.

What actually changed on your machine

Microsoft has been rolling out a power management behaviour called the Low Latency Profile. The idea is a well-established one in mobile chip design, usually described as race to sleep: instead of running the processor at a moderate clock for a longer stretch, briefly push it to its maximum frequency, finish the work sooner, and drop back to idle. The claim is that total energy spent can be lower even though peak power is higher.

The rollout happened in stages, which is why people experienced it at very different times:

1. KB5089573 (build 26200.8524 and newer) put the code in place, but the feature stayed dormant behind Microsoft's Controlled Feature Rollout.
2. The June 2026 security update switched it on for shell components only — Start menu, Search, Action Center.
3. KB5121003 (build 26200.9168), the August 2026 cumulative update, extended it to general app launches.

That third step is why complaints spiked in August. When the boost only fired on the Start menu, most people never noticed. Once it fires every time you open Chrome, Explorer, Outlook, or Notepad, a laptop with an aggressive fan curve becomes impossible to ignore.

Why Zen 4 laptops specifically

The feature is hardware-agnostic. The experience of it is not. Three things stack up on Ryzen mobile parts:

• Boost latency is very short. AMD's mobile boost algorithm reaches peak frequency in a handful of milliseconds. A request for maximum clock is answered almost instantly, so the full power draw lands inside the one-to-three-second window rather than being smoothed out.
• Thin chassis, small heatsinks. On a 14-inch ultraportable, package power going from roughly 5 W to 30 W or higher for two seconds moves the skin and heatsink temperature enough to cross the fan curve's first threshold.
• Aggressive OEM fan curves. Many Ryzen ultrabooks are tuned to react quickly to temperature deltas rather than to sustained load, precisely the wrong tuning for a workload made of two-second bursts.

The result is that the same feature that is genuinely imperceptible on a desktop or a thick gaming laptop turns into a rhythmic whoosh on a Zen 4 ultrabook.

Confirm it before you change anything

Do not start disabling things on a hunch. Confirming this takes about five minutes.

Step 1 — Check your build number

Go to Settings > System > About and read the OS build. If you are on 26200.9168 or newer, KB5121003 is installed and app-launch boosting is in play. If you are on 26200.8524 through the June update, only shell boosting applies — you would hear it on the Start menu but not on app launches.

Step 2 — Watch frequency, not utilization

This is the step almost everyone skips, and it is the one that settles the question. Install HWiNFO from its official site, launch it in Sensors mode, and find the per-core clock readings. Leave the machine idle for two or three minutes so clocks settle.

Now open the Start menu while watching. If this is the Low Latency Profile, you will see a sharp jump on the active cores to near the chip's maximum boost clock, held for one to three seconds, then a drop back — with CPU utilization barely moving. That combination of "frequency spikes, utilization does not" is the signature. A background process causing the same fan behaviour would show the opposite pattern.

Step 3 — Test the trigger list

Repeat the observation on each of these, giving the machine fifteen seconds to settle between attempts: Start menu, Windows Search, the taskbar clock (Action Center), and launching a small app such as Notepad. If all four produce the same brief spike, you have your answer. If only some do, note which — that distinction matters if you later contact support.

What you can actually do about it

Here is the uncomfortable part, stated plainly: there is no user-facing toggle. Microsoft did not ship a Settings switch for this, and has said that once the feature is fully deployed, disabling it is not an expected user action. The options below range from officially supported to distinctly unofficial, in that order.

Option A — Change the fan curve, not the CPU

This is the fix most people actually want, because the CPU behaviour is harmless and the noise is the complaint. Most Ryzen laptop vendors ship a control app: Lenovo Vantage, ASUS Armoury Crate, HP Command Center, Dell Power Manager. Look for a quiet or balanced thermal profile, which typically raises the fan's activation threshold by several degrees and lengthens its response delay. A two-second thermal blip then finishes before the fan is asked to respond at all.

This addresses the symptom without touching the feature, and it survives future updates. Start here.

Option B — Cap the processor's maximum state on battery

Windows still exposes a maximum processor state in advanced power settings, though on many modern systems it is hidden by default. If it is available on your machine, setting the maximum processor state to 99% on battery disables boost entirely on many platforms. The boost request still arrives; the chip simply cannot answer it.

Be honest with yourself about the trade: you are giving up peak single-thread performance in every workload, not just this one, to silence a two-second burst. On a machine used mainly for browsing and documents, that trade is often fine. On a machine used for compiling or video work, it is not.

Option C — Disable the feature flag directly

The Low Latency Profile is gated behind a Windows feature ID, 58989092, which can be toggled with ViVeTool — a community utility that manipulates Microsoft's own feature-flag system. Download it from its official GitHub releases page, extract it to a folder such as C:\ViveTool, open Command Prompt as administrator, change to that folder, and run:

vivetool /disable /id:58989092

Restart afterward. The same command with /enable reverses it.

Two warnings that belong with this, not buried at the bottom. First, ViVeTool is not a Microsoft product and toggling feature flags is not a supported configuration. Second, and more practically: cumulative updates frequently re-enable flags. Expect to redo this after future patch Tuesdays, and expect it to eventually stop working once the feature graduates out of the flag system entirely.

When this is not the cause

Four other things produce fan behaviour that gets misattributed to this update. Each has a distinguishing tell.

• Windows Search indexing. Runs after large file moves or a fresh install. Tell: fans run for many minutes continuously, and SearchIndexer.exe shows real CPU usage in Task Manager. Not tied to UI actions.
• Microsoft Defender scheduled scan. Tell: happens at a consistent time of day, and MsMpEng.exe is visible in Task Manager. Check the scan schedule in Windows Security.
• Modern Standby drain. Tell: the laptop is warm when taken out of a bag, and battery dropped overnight. Different symptom entirely — run powercfg /sleepstudy and read the generated report.
• Degraded thermal paste or blocked intakes. Tell: developed gradually over months, idle temperatures are elevated, and the fan never fully stops. Age of the machine matters more than the update date.

The counterargument, and it is a real one

It would be dishonest to present this purely as a defect, because the measured evidence largely does not support that framing.

Independent testing published after the June rollout found no measurable battery or thermal penalty from the short bursts, and at least one round of testing concluded that battery life was marginally better with the feature active — consistent with the race-to-sleep theory. Microsoft has publicly defended the approach, pointing out that comparable boost behaviour has existed in other operating systems for years without complaint. Measured across a full workday, a few hundred two-second bursts genuinely may cost less energy than the alternative.

So both things are true at once. The feature is probably not hurting your battery or your processor, and the noise you are hearing is still real and still annoying. Those are not in conflict. What follows from that is a specific recommendation: solve it at the fan curve, not at the CPU. Option A costs you nothing. Options B and C cost you performance or stability to fix a problem that is, on the evidence, acoustic rather than thermal.

There is one narrow case where the stronger options are justified: if HWiNFO shows your chip pinned at maximum clock for far longer than three seconds, or the spikes fire continuously without any UI interaction, that is not the documented behaviour and is worth escalating to your laptop vendor with the HWiNFO log attached.

Keeping it from coming back

• If you used Option C, re-check after every cumulative update. Note the feature ID somewhere you will find it again.
• If you used Option A, verify the thermal profile survived the update — vendor control apps sometimes reset to default after a major Windows patch.
• Record your current build number now. When the next behavioural change lands, knowing what you moved from turns a mystery into a five-minute diagnosis.
• Keep HWiNFO installed. The single most useful habit here is checking frequency versus utilization before assuming anything is broken.

Most "my laptop suddenly got loud" problems are not hardware failures. They are behavioural changes that arrived on a specific date, and the fastest path to an answer is almost always working out which date.

Ran into a variation of this on a different chip or chassis? Note your exact build number and what the frequency graph does — that pair of details is what separates a real fault from a feature working as designed.