How much memory can actually be freed in Windows

Short answer

In reality, less can be freed than the “memory optimizers” promise. In this experiment, disabling background components freed 1.0–1.5 GB of available memory and reduced the commit charge by 52% in series 2. But the popular quick methods do not work: terminating shell processes — Windows restarts them itself in about 20 seconds; clearing the working set — the paged-out pages remain in RAM as cache; registry parameters of the memory manager — there is no confirmed benefit. Targeted disables on top of an already optimized system gave an honest +22–30 MB. Memory in the standby list is cache that is already counted in “available”.

Status: the final numbers were obtained in a virtual machine with 8 GB RAM on Windows 11 (26H2, build 26300.9457). The directions are confirmed by Microsoft documentation and our controlled experiments; the absolute values on another configuration will be different.

Claims under test

We tested four claims:

1. Terminating “unnecessary” background processes frees memory.
2. Clearing the working set or standby list (the mechanics of “RAM optimizers”) frees memory.
3. Registry parameters of the memory manager noticeably free memory.
4. Disabling background components frees a large amount of memory.

Scope of the study

• Windows 11 Pro, build 26300.9457 (26H2); virtual machine, 8 GB RAM;
• two states of one installation: the original (“before”) and after applying the BoosterX optimization profile — the measurement was performed in two independent series (the detailed protocol and the remaining metrics are in “Quiet idle: Windows background before and after optimization”);
• on top of the “after” state — a package of targeted disables of background sources (ETW diagnostic autologgers, notification, shadow copy and update orchestrator services);
• metrics: available and used memory, commit charge, nonpaged/paged pool, working set and private bytes by process, page faults (hard faults).

Not included: physical hardware, systems with a different amount of RAM, experiments with disabling the pagefile, and third-party “memory optimization” utilities.

Methodology

• The memory inventory was taken at steady idle: system counters (available, used, commit, pools) and a list of processes with working set and private bytes.
• Controlled experiment “terminate shell processes”: two interface processes were stopped (SearchHost.exe and StartMenuExperienceHost), the state was checked after 20 and 40 seconds; commit was recorded before and after.
• The package of targeted disables was applied to the “after” state, then a reboot was performed and a comparison was made with four control boots of the same state without the package; boot probes checked for the absence of a performance regression.
• The measurement layer (tracing, counters, collection scripts) itself occupies memory — up to a hundred or more MB of working set in individual measurements; this is stated in the limitations.

Results

How much the background occupies

Inventory snapshot at idle (series 1):

	Before	After	Change
Total working set, MB	3 841	1 868	−51 %
Total private bytes, MB	1 524	660	−57 %
Available memory, MB	5 490	6 518	+1 028

Series 2: used memory 3 017 → 1 538 MB, available 5 174 → 6 653 MB, commit charge 2 617 → 1 249 MB. The direction is the same in both series: background components hold roughly half of the used memory of this profile.

Structure of used memory

In the “after” state, memory was distributed as follows (total working sets, series 1):

• shell (File Explorer, DWM, Start menu search, session host) — about 640 MB;
• background services — about 640 MB (57 services in 39 host processes);
• web search component — about 320 MB;
• kernel pools — about 167 MB, of which about 76 MB is occupied by registry pools.

A process’s working set is not equal to the memory that can be freed: it includes shared pages (system library code, shared data) that are counted in every process at the same time. In the “after” state of series 1, the total working set of 75 processes was 1 868 MB, while the total private bytes was 660 MB; in the control boots of the targeted-disable experiment, the total working set was 2 036 MB. The largest interface processes (series 2):

Process	Working set, MB	Private, MB
SearchHost.exe (search)	187	80
explorer.exe (File Explorer)	167	36
StartMenuExperienceHost	107	24
dwm.exe (DWM)	73	34

In the “after” state, the standby list was 711 MB. This is not lost memory but cache: standby is already counted in “available”, and Windows instantly reuses these pages when an application demands memory.

Experiment: terminating shell processes

After stopping SearchHost.exe and StartMenuExperienceHost (series 2):

• both processes automatically restarted in about 20 seconds with new identifiers; after 40 seconds they were still running;
• the commit charge did not decrease but grew by 12.6 MB (from 1 386.9 to 1 399.5 MB) — restarting shell processes itself creates new work;
• the short-term growth of “available” memory by 93 MB is not a saving: the target processes came back, and commit increased.

Terminating File Explorer in a separate measurement (series 1) also did not produce a sustained increase in free memory: in that window free memory even decreased by 97 MB while standby grew by 13 MB — the paged-out pages remain in the system as cache, and the shell and related processes continue to run.

Conclusion of the experiment: forcibly terminating system processes does not free memory. Windows restarts shell components automatically, and instead of a saving you get additional load.

Clearing the working set and standby list

The mechanics are documented by Microsoft. Paging pages out of the working set (for example, with the EmptyWorkingSet function or SetProcessWorkingSetSize with an “empty” size — these are exactly what “RAM optimizers” use) moves the pages into a transitional state: they remain cached in RAM until they are needed again or are reused. The next access by a process to such a page is a soft page fault and a return to the working set.

Therefore, clearing the working set changes the “free” figure in the counters but does not create physically available memory: the pages do not disappear anywhere, and re-accessing them becomes more expensive. Clearing the standby list is pointless for the same reason: standby is memory already available to the system. In our measurements there was no memory pressure in either state (hard faults remained low), so additional paging out improved nothing.

Our criterion from this experiment: the result of “freeing memory” must be evaluated by commit, page faults and latencies on re-use of memory, not by a short-term increase in the “free” line.

Targeted disables: the honest gain

On top of the “after” state, we disabled nine ETW diagnostic autologgers and four background services (notification, shadow copy, update orchestrator) and compared the result with four control boots:

Metric	Control boots	With the package	Difference
Free memory, MB	6 664–6 674	6 696	+22…+30
Nonpaged pool, MB	69.8–71.8	58.7	−11…−13
Total working set, MB	2 036	1 959	−77
Probe performance	unchanged	unchanged	—

Only the autologgers gave −13.2 MB of nonpaged pool (measured separately). Important: the total working set of the disabled components according to the inventory was about 78 MB, while the real gain in free memory was +22–30 MB. The difference arises because part of what was “disabled” was not running anyway. This is the honest boundary of targeted disables without removing system components; as a side effect, the same package reduced idle background activity by a further 24%.

The registry parameters of the memory manager (pool sizes, system cache and similar) were not even considered in this experiment as a source of gain: their reading and practical usefulness are discussed in “Memory Manager and system cache” — they have no confirmed benefit for freeing RAM.

What is confirmed

• Reproduced (two series): disabling background components frees 1.0–1.5 GB of available memory; the total working set decreased by 51% (series 1), used memory by 49% and the commit charge by 52% (series 2).
• Measured: automatic restart of stopped shell processes within 20 seconds; commit does not decrease in the process (in our experiment it grew by 12.6 MB).
• Measured: terminating File Explorer does not produce a sustained increase in free memory; the paged-out pages remain in standby.
• Documented: paging pages out of the working set moves them into a transitional state, cached in RAM; standby memory is counted in available.
• Measured: targeted disables on top of an optimized system give +22–30 MB of free memory with unchanged performance; the total working set of what was disabled is not equal to the gain in free memory.

What is not confirmed

• Third-party “RAM optimizers” were not tested directly: the mechanics on which they are built (clearing the working set) was verified.
• Disabling the pagefile was not measured; it is only known that the pagefile is needed for a crash dump and for the commit limit.
• Transferring the values to machines with a different amount of RAM, other builds and physical hardware.
• The persistence of the saving over long windows: the measurements were performed at steady idle.

Limitations

• A virtual machine with 8 GB RAM: the absolute numbers are tied to this configuration; a profile with a larger amount of background components will free more, a “quiet” system — less.
• The sum of working sets by process overstates the unique footprint because of shared pages; that is exactly why we give private bytes alongside.
• The measurement layer itself occupied noticeable memory (up to hundreds of MB of working set in individual measurements) — the state figures include the presence of the measurement.
• There was no memory pressure in the experiment (hard faults were low), so we did not check whether the saving reduces thrashing under conditions of RAM shortage.
• Part of the freeing is related to disabling Microsoft Defender protection components — this is a trade-off with security, not memory obtained for free.

The study and the tools used belong to the developer of BoosterX, and BoosterX is a Windows optimizer, so measuring the effect of optimization is its direct interest. The methodology and the boundaries of applicability are described above, and the conclusions can be verified against open data and the listed public sources. Negative results on popular methods of “freeing memory” are published on a par with positive ones.

Practical conclusion

What actually frees memory, according to this experiment:

• close unused applications — their private bytes are freed entirely;
• disable genuinely unnecessary background components — the measured combined effect is described in “Quiet idle”; this is the only method among those tested that gave gigabytes, and its price is the loss of the corresponding features;
• evaluate the result by commit and available memory (Task Manager → “Performance” → “Memory”), not by the “free” line.

What does not work:

• forcibly terminating system processes: Windows restarts them within seconds, and commit grows;
• “RAM optimizers” and clearing standby: the paged-out pages remain in RAM as cache, and bringing them back into operation costs soft page faults;
• registry parameters of the memory manager.

Standby memory is not a problem but the work of the cache: “available” already includes it. Leave the pagefile under system management: it is needed for the commit limit and crash dumps.

Restoring the state

The experiments were performed in an isolated virtual machine on test state branches; after the measurements, the test branches were reset and the machine was returned to its original state. The article does not recommend terminating system processes or disabling the pagefile, so no separate restore action is required on a user’s computer.

Public primary sources

• Microsoft: Working Set — the composition of the working set, paging out of pages, transitional pages cached in RAM, and the EmptyWorkingSet/SetProcessWorkingSetSize functions; checked 2026-09-20.
• Microsoft: EmptyWorkingSet — the API used by “memory optimization” utilities; checked 2026-09-20.
• Microsoft: About Memory Management — the virtual memory model and shared pages; checked 2026-09-20.
• Microsoft: Introduction to the page file — commit charge, the commit limit and the role of the pagefile; checked 2026-09-20.
• Memory Manager and system cache — a study of the registry parameters of the memory manager.
• Quiet idle: Windows background before and after optimization — the measurement protocol and the remaining metrics of this same experiment.
• How we research Windows — evidence levels and measurement rules.

Change history

• 2026-09-20: the numbers were brought into line with the series tables: the “after” of series 1 — 1 868/660 MB, the attribution of percentages by metrics and series was refined; the conflict-of-interest disclaimer was strengthened to the full wording.
• 2026-09-20: first publication — the memory inventory in two series, the negative experiments with terminating processes and clearing, and the honest gain of targeted disables.