Quiet idle: Windows background activity before and after optimization
On this page
Short answer
Section titled “Short answer”Disabling background Windows components really does make idle quieter: across two independent measurement series, the number of processes fell by 49–56 %, idle CPU utilization fell by 17–67 %, and memory commit fell by 52 % in the second series. But under full CPU load, throughput increased by only 0,2–0,5 %. “Quiet idle” means a confirmed reduction in background activity and resource contention, not an FPS increase: the gaming effect was not measured in this study.
Status: The direction of the effect was reproduced in two independent series on the same Windows 11 build in a virtual machine. The magnitudes differ between series because Windows background activity comes in bursts: during a window with a Microsoft Defender scan, the difference in CPU utilization reaches −67 %, while in an already quiet window it is −17 %.
Verifiable claim
Section titled “Verifiable claim”We tested four claims:
- Disabling background components noticeably reduces system activity at idle.
- It noticeably reduces activity during the first minutes after startup.
- It noticeably reduces memory usage.
- It produces a measurable performance increase under full CPU load.
Scope of the study
Section titled “Scope of the study”- Windows 11 Pro, build 26300.9457 (26H2);
- virtual machine: 4 vCPU, 8 GB RAM, VMware virtualization;
- two states of the same installation: original (“before”) and after applying the BoosterX optimization profile (the build current on the measurement dates);
- two independent measurement series: 2026-09-18 and 2026-09-19; states were compared on independent disk copies so the measurements would not affect each other;
- phases: 5 minutes after startup, 5 minutes of stabilization, 5 minutes idle;
- short synthetic workloads: 1, 4, and 8 threads, memory load, pulsed load, and mixed-priority workloads.
The measurements did not include real games, GPU load, physical hardware, or long measurement windows (hours and days).
A separate series on a physical Ryzen 7 7800X3D PC, with four stages and gaming measurements, is published in the article “BoosterX: Windows background activity and FPS in CS2”. Its results are not combined with this virtual-machine series.
Methodology
Section titled “Methodology”The protocol follows “How we research Windows”:
- each phase was recorded using an ETW trace (Windows Performance Recorder, lightweight CPU, disk, file, and network profiles) and performance counters at 5-second intervals (system-wide) and 15-second intervals (per process);
- the “after startup” phase began with a controlled reboot and started at an uptime of about one minute;
- each trace was checked for lost events — the count was zero in all windows reported here;
- averages were calculated only over complete five-second intervals within the phase boundaries (59 intervals per phase);
- in series 2, the first “before” run was excluded because the virtual machine went to sleep; a repeat run was used;
- workload tests were run twice, and medians are reported; CPU utilization was normalized to four vCPUs.
“Before” and “after” are states of the same Windows installation: “after” was produced by applying the optimization profile, while “before” is the original state. A set of settings was changed as a whole, so the isolated contribution of any individual change was not assessed.
Results
Section titled “Results”Series 1 (2026-09-18) — steady-state idle with no active maintenance:
| Metric | Before | After | Change |
|---|---|---|---|
| CPU utilization, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| Context switches, /s | 469 | 381 | −19 % |
| Processes (average) | 134,9 | 69,3 | −49 % |
| Threads (average) | 1 444,6 | 738,7 | −49 % |
| Total CPU across all processes, % | 1,22 | 1,06 | −13 % |
| Available memory, MB | 5 490 | 6 518 | +1 028 |
| Disk reads, KB/s | 22,6 | 24,4 | +8 % |
| Disk writes, KB/s | 311,3 | 262,1 | −16 % |
| Network (receive), KB/s | 132,6 | 2,2 | −98 % |
| Network (send), KB/s | 43,2 | 4,7 | −89 % |
Series 2 (2026-09-19) — the same idle window, but a Microsoft Defender background scan was running in the “before” state:
| Metric | Before | After | Change |
|---|---|---|---|
| CPU utilization, % | 33,37 | 11,03 | −67 % |
| Context switches, /s | 3 737 | 291 | −92 % |
| Processes (average) | 142,3 | 61,9 | −56 % |
| Threads (average) | 1 494,7 | 637,1 | −57 % |
| Available memory, MB | 5 174 | 6 653 | +1 479 |
| Physical memory in use, MB | 3 017 | 1 538 | −49 % |
| Memory commit, MB | 2 617 | 1 249 | −52 % |
| Nonpaged pool, MB | 298,2 | 212,9 | −29 % |
| Paged pool, MB | 258,5 | 86,0 | −67 % |
| DPC, % CPU | 0,89 | 0,19 | −78 % |
| Disk reads, MB/s | 7,42 | 0,01 | −99,9 % |
| Disk writes, MB/s | 4,57 | 0,23 | −95,0 % |
There was almost no network activity during idle in series 2 in either state (tens of bytes per second), so network rows are not included for that series. The difference between the series is not a contradiction, but a property of background activity itself: disabling background components saves more when Windows is performing maintenance, and less when the measurement window is already quiet.
First minutes after startup
Section titled “First minutes after startup”| Metric | Series 1 (before → after) | Series 2 (before → after) |
|---|---|---|
| CPU utilization, % | 3,42 → 2,59 | 14,62 → 11,88 |
| Context switches, /s | 1 114 → 600 | 1 257 → 393 |
| Processes | 132 → 74 | 139 → 64 |
| Threads | — | 1 719 → 746 |
| Physical memory in use, MB | — | 2 821 → 1 581 |
| Available memory, MB | — | 5 370 → 6 610 |
| Disk reads, KB/s | — | 826 → 433 |
| Disk writes, KB/s | 634 → 418 | 709 → 298 |
| Network (receive), KB/s | — | 1,15 → ~0 |
A dash means that the metric was not recorded for this phase in that series.
Composition and memory
Section titled “Composition and memory”Idle inventory snapshot (series 1):
| Before | After | |
|---|---|---|
| Processes | 136 | 70 |
| Threads | 1 679 | 842 |
| Total working set, MB | 3 841 | 1 868 |
| Total private bytes, MB | 1 524 | 660 |
The largest memory consumers before optimization were the antivirus process MsMpEng.exe (257 MB), explorer.exe (213 MB), StartMenuExperienceHost (144 MB), msedge.exe (133 MB), and SearchHost.exe (122 MB). After optimization, the list was led by explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB), and StartMenuExperienceHost (106 MB).
Available memory increased by 1,0–1,5 GB, while commit decreased by 52 %. What can actually be “freed” and why the sum of process working sets is not the same as free memory is explained in “How much memory can actually be freed in Windows”.
Under full load
Section titled “Under full load”Short synthetic tests (series 2, medians of two runs):
| Scenario | Throughput change | CPU utilization: before / after |
|---|---|---|
| One thread | +5,4 % | 21,9 / 22,6 % |
| Four threads (full) | +0,19 % | 88,9 / 89,4 % |
| Eight threads (full) | +0,50 % | 88,9 / 88,8 % |
| Memory load | +11,2 % | 84,8 / 87,5 % |
| Pulsed (1 ms pauses) | +5,4 % | 64,3 / 67,7 % |
| Mixed priorities | +8,5 % | 21,2 / 22,5 % |
| Background priority | +77,1 % | 38,8 / 65,2 % |
Under a full four-thread load, the workload process received about 89 % of the capacity of four vCPUs both before and after optimization. The remaining ~11 % in the virtual machine cannot be declared removable “Windows noise”: hypervisor scheduling is not visible in the guest trace. The worker threads were distributed evenly (the spread in work volume between them was 0,994–0,997); no starvation was observed, and the CPU queue at idle was practically empty after optimization.
Where the background activity comes from
Section titled “Where the background activity comes from”Measured sources of background activity in the “before” state:
- antivirus scanning — the main source during the series 2 window: process
MsMpEng.exeused 212 CPU-seconds during the five-minute idle window; - in the original state, the Search service, SysMain service, telemetry, Print Spooler, and other components were running — the optimization profile disables about 50 background services and 58 scheduled tasks;
- after startup, activity is accompanied by the Windows Update Orchestrator.
Disabling background components does not eliminate background activity entirely: in the optimized state, the application compatibility assessment continued to run (about 3,7 ms of CPU per second during the maintenance window), and total residual background activity during steady-state idle was 4,8 ms of CPU per second — about 0,12 % of the capacity of four vCPUs (measured from the trace).
What is confirmed
Section titled “What is confirmed”- Reproduced (two independent series): processes −49…−56 %, threads −49…−57 %, available memory +1,0–1,5 GB.
- Measured (series 2): commit −52 % at idle; physical memory in use −49 % at idle and −44 % in the after-startup phase.
- Measured: idle CPU utilization −17 % in the quiet window and −67 % in the window with a scan; context switches −19 % and −92 %; DPC −78 % (series 2 window); activity after startup was lower in both series.
- Measured: under full CPU load, throughput increased by +0,19 % (4 threads) and +0,50 % (8 threads); under partial and mixed loads, the increase ranged from +5,4 to +11,2 %.
- Measured: a background-priority workload ran 77,1 % faster — in the “before” state, it competed with Windows background activity, including antivirus scanning.
- Observed: the main sources of background activity were antivirus scanning, maintenance, and compatibility tasks; after optimization, residual background activity was close to zero, but not zero.
What is not confirmed
Section titled “What is not confirmed”- An FPS increase, lower input lag, or lower frametime in real games: not measured. Synthetic CPU tests do not model a game with a GPU and do not prove a gaming effect.
- The isolated contribution of each individual change: a set of changes was applied.
- Applying the absolute values to physical hardware, other builds, or other optimization profiles.
- Stability over long windows: each phase lasted 5 minutes; Windows background activity comes in bursts, so an “average day” was not measured.
Limitations
Section titled “Limitations”- Measurements were performed in a virtual machine. Virtualization contributes its own share of DPC/ISR and hides host scheduling; absolute values will differ on physical hardware. The proportions and direction of the before/after comparison are preserved under identical conditions.
- The ISR metric is excluded from the tables: in the virtual machine, the ISR counter from PDH differs from interrupt handlers reported by ETW by about 10 % and does not add up to an exact total.
- The “before” window in series 2 included an active Defender scan, and host load differed between windows (44 % on average versus 24 %). Therefore, the values apply to the specific windows; the direction was confirmed in two series.
- In series 1, part of the idle phase was interrupted by an external virtual-machine pause of about 26 seconds; capture ended after resumption, with no lost events.
- Workload tests were run twice: this is descriptive statistics, and statistical significance was not assessed.
- Some of the idle improvement is associated with disabling Microsoft Defender protection components. A system without antivirus protection is a deliberate trade-off, not an optimization without costs; protection should be disabled only with an understanding of the consequences.
- The measurement layer (tracing and counters) itself creates a small background load; it is present in both states.
The study and the tools used belong to the BoosterX developer, so the developer has a direct interest in the results. The methodology and limits of applicability are described above, and the conclusions can be checked against the open data and the public sources listed below.
Practical conclusion
Section titled “Practical conclusion”Reducing background noise is a real effect reproduced twice: half as many processes and threads, half as much memory commit, and an order of magnitude less disk and network activity at idle. This is useful in itself — for system responsiveness, background tasks, temperature, fan noise, and battery life — and does not require promises about FPS.
What not to expect: a performance increase under full load. If the CPU is already doing useful work at ~89 % of its capacity, disabling background activity will not add the remaining 11 % — in a virtual machine, that capacity does not belong to Windows. The system’s activity at the time of comparison determines how large the visible effect is: the difference is several times greater during a maintenance window and moderate during a quiet window.
Recommendation: assess background activity before and after any changes on your own computer (Task Manager → “Performance” and “Processes”, Resource Monitor), rather than relying on someone else’s percentages. If the goal is FPS in a specific game, measure FPS itself before and after the change.
Restoring the state
Section titled “Restoring the state”Both series were run in isolated virtual machines on independent disk copies; after the measurements, the machines were returned to their original states. The article does not require readers to change any settings, so no separate restoration action is needed on a user’s computer.
Public primary sources
Section titled “Public primary sources”- Microsoft: Windows Performance Recorder — the ETW trace recording tool used in the methodology; checked 2026-09-20.
- Microsoft: About Event Tracing — the ETW model and lost-event checks; checked 2026-09-20.
- Microsoft: Microsoft Defender Antivirus in Windows — Defender processes and services, including
MsMpEng.exe(“Antimalware Service Executable” in Task Manager); checked 2026-09-20. - How we research Windows — evidence levels and measurement protocol.
- Service Host and Windows 11 background components — how Windows hosts background services in processes.
- How much memory can actually be freed in Windows — a detailed analysis of memory from this same experiment.
- Desktop versus sign-in screen — follow-up: what user-session noise consists of.
Change history
Section titled “Change history”- 2026-09-20: first publication — two independent idle measurement series, after-startup phases, inventory, and workload tests.
- 2026-09-20: attribution of results by series clarified (commit and physical memory in use — series 2 only; processes −49…−56 %); conflict-of-interest disclaimer revised to the canonical wording.