Wie viel Arbeitsspeicher lässt sich in Windows wirklich freigeben

Auf dieser Seite

Kurze Antwort

Real freigeben lässt sich weniger, als „Speicheroptimierer“ versprechen. In diesem Experiment hat das Deaktivieren von Hintergrundkomponenten 1,0–1,5 GB verfügbaren Speicher freigegeben und das Commit-Volumen in Serie 2 um 52 % reduziert. Doch die populären schnellen Methoden funktionieren nicht: das Beenden von Shell-Prozessen — Windows startet sie von selbst in etwa 20 Sekunden neu; das Leeren des Working Set — ausgelagerte Seiten bleiben als Cache im RAM; Registry-Parameter des Speichermanagers — es gibt keinen bestätigten Nutzen. Punktuelle Deaktivierungen auf einem bereits optimierten System ergaben ehrliche +22–30 MB. Speicher in der Standby-Liste ist ein Cache, der in „verfügbar“ bereits berücksichtigt ist.

Status: Die endgültigen Zahlen wurden in einer virtuellen Maschine mit 8 GB RAM unter Windows 11 (26H2, Build 26300.9457) ermittelt. Die Richtungen sind durch Microsoft-Dokumentation und unsere kontrollierten Experimente bestätigt; die absoluten Werte werden bei einer anderen Konfiguration anders ausfallen.

Überprüfbare Aussagen

Wir haben vier Aussagen überprüft:

Das Beenden „unnötiger“ Hintergrundprozesse gibt Speicher frei.
Das Leeren des Working Set oder der Standby-Liste (die Mechanik der „RAM-Optimierer“) gibt Speicher frei.
Registry-Parameter des Speichermanagers geben spürbar Speicher frei.
Das Deaktivieren von Hintergrundkomponenten gibt ein großes Speichervolumen frei.

Untersuchungsbereich

Windows 11 Pro, Build 26300.9457 (26H2); virtuelle Maschine, 8 GB RAM;
zwei Zustände einer Installation: der ursprüngliche („vorher“) und nach Anwendung des Optimierungsprofils von BoosterX — die Messung wurde in zwei unabhängigen Serien durchgeführt (das ausführliche Protokoll und die übrigen Metriken — in „Stiller Leerlauf: der Windows-Hintergrund vor und nach der Optimierung“);
über dem Zustand „nachher“ — ein Paket punktueller Deaktivierungen von Hintergrundquellen (diagnostische ETW-Autologger, Benachrichtigungsdienste, Schattenkopie- und Update-Orchestrator-Dienste);
Metriken: verfügbarer und belegter Speicher, Commit-Volumen, nonpaged/paged pool, Working Set und private bytes je Prozess, Seitenfehler (hard faults).

Nicht einbezogen: physische Hardware, Systeme mit anderem RAM-Volumen, Experimente mit deaktivierter pagefile und Drittanbieter-Tools zur „Speicheroptimierung“.

Methodik

Das Speicherinventar wurde im eingeschwungenen Leerlauf erfasst: Systemzähler (verfügbar, belegt, commit, Pools) und eine Prozessliste mit Working Set und private bytes.
Kontrolliertes Experiment „Shell-Prozesse beenden“: zwei Oberflächenprozesse (SearchHost.exe und StartMenuExperienceHost) wurden gestoppt, der Zustand nach 20 und 40 Sekunden geprüft; commit wurde vorher und nachher festgehalten.
Das Paket punktueller Deaktivierungen wurde auf den Zustand „nachher“ angewendet, danach erfolgten ein Neustart und der Vergleich mit vier Kontrollstarts desselben Zustands ohne das Paket; Startproben prüften das Fehlen einer Performance-Regression.
Die Messschicht (Tracing, Zähler, Sammelskripte) belegt selbst Speicher — bis zu hundert und mehr MB Working Set in einzelnen Messungen; dies ist in den Einschränkungen erwähnt.

Ergebnisse

Wie viel der Hintergrund belegt

Momentaufnahme des Inventars im Leerlauf (Serie 1):

	Vorher	Nachher	Änderung
Summierte Working Set, MB	3 841	1 868	−51 %
Summierte private bytes, MB	1 524	660	−57 %
Verfügbarer Speicher, MB	5 490	6 518	+1 028

Serie 2: belegter Speicher 3 017 → 1 538 MB, verfügbar 5 174 → 6 653 MB, Commit-Volumen 2 617 → 1 249 MB. Die Richtung stimmt in beiden Serien überein: Hintergrundkomponenten halten etwa die Hälfte des belegten Speichers dieses Profils.

Struktur des belegten Speichers

Im Zustand „nachher“ verteilte sich der Speicher so (summierte Working Set, Serie 1):

Shell (File Explorer, DWM, Suche im Startmenü, Sitzungshost) — etwa 640 MB;
Hintergrunddienste — etwa 640 MB (57 Dienste in 39 Host-Prozessen);
Web-Komponente der Suche — etwa 320 MB;
Kernel-Pools — etwa 167 MB, davon belegen Registry-Pools etwa 76 MB.

Das Working Set eines Prozesses ist nicht gleich dem freigebbaren Speicher: es enthält geteilte Seiten (Code von Systembibliotheken, gemeinsame Daten), die in jedem Prozess gleichzeitig gezählt werden. Im Zustand „nachher“ von Serie 1 betrug die Summe des Working Set von 75 Prozessen 1 868 MB, die Summe der private bytes 660 MB; in den Kontrollstarts des Experiments mit punktuellen Deaktivierungen betrug das summierte Working Set 2 036 MB. Die größten Oberflächenprozesse (Serie 2):

Prozess	Working Set, MB	Private, MB
`SearchHost.exe` (Suche)	187	80
`explorer.exe` (File Explorer)	167	36
`StartMenuExperienceHost`	107	24
`dwm.exe` (DWM)	73	34

Im Zustand „nachher“ betrug die Standby-Liste 711 MB. Das ist kein verlorener Speicher, sondern ein Cache: Standby ist in „verfügbar“ bereits berücksichtigt, und Windows verwendet diese Seiten sofort wieder, wenn eine Anwendung Speicher benötigt.

Experiment: Beenden von Shell-Prozessen

Nach dem Stoppen von SearchHost.exe und StartMenuExperienceHost (Serie 2):

beide Prozesse starteten automatisch in etwa 20 Sekunden mit neuen Identifikatoren neu; nach 40 Sekunden liefen sie noch;
das Commit-Volumen sank nicht, sondern stieg um 12,6 MB (von 1 386,9 auf 1 399,5 MB) — der Neustart der Shell-Prozesse erzeugt selbst neue Arbeit;
der kurzzeitige Anstieg des „verfügbaren“ Speichers um 93 MB ist keine Einsparung: die Zielprozesse kehrten zurück, commit stieg.

Das Beenden von File Explorer in einer separaten Messung (Serie 1) ergab ebenfalls kein stabiles Wachstum des freien Speichers: in diesem Fenster sank der freie Speicher sogar um 97 MB bei einem Anstieg von Standby um 13 MB — ausgelagerte Seiten bleiben als Cache im System, und die Shell und zugehörige Prozesse arbeiten weiter.

Fazit des Experiments: das erzwungene Beenden von Systemprozessen gibt keinen Speicher frei. Windows startet Shell-Komponenten automatisch neu, und statt einer Einsparung erhalten Sie zusätzliche Last.

Leeren des Working Set und der Standby-Liste

Die Mechanik ist von Microsoft dokumentiert. Das Auslagern von Seiten aus dem Working Set (etwa mit der Funktion EmptyWorkingSet oder SetProcessWorkingSetSize mit „leerer“ Größe — genau diese verwenden „RAM-Optimierer“) versetzt die Seiten in einen Übergangszustand: sie bleiben im RAM zwischengespeichert, bis sie wieder benötigt oder wiederverwendet werden. Der nächste Zugriff eines Prozesses auf eine solche Seite ist ein weicher Seitenfehler und die Rückkehr ins Working Set.

Deshalb ändert das Leeren des Working Set die Zahl „frei“ in den Zählern, erzeugt aber keinen physisch verfügbaren Speicher: die Seiten verschwinden nirgendwohin, und der erneute Zugriff auf sie wird teurer. Das Leeren der Standby-Liste ist aus demselben Grund sinnlos: Standby ist bereits für das System verfügbarer Speicher. In unseren Messungen fehlte der Speicherdruck in beiden Zuständen (hard faults blieben niedrig), daher verbesserte das zusätzliche Auslagern nichts.

Unser Kriterium aus diesem Experiment: das Ergebnis einer „Speicherfreigabe“ muss anhand von commit, Seitenfehlern und Latenzen bei der erneuten Speichernutzung bewertet werden, nicht anhand eines kurzzeitigen Anstiegs der Zeile „frei“.

Punktuelle Deaktivierungen: der ehrliche Zuwachs

Über dem Zustand „nachher“ deaktivierten wir neun diagnostische ETW-Autologger und vier Hintergrunddienste (Benachrichtigungen, Schattenkopie, Update-Orchestrator) und verglichen das Ergebnis mit vier Kontrollstarts:

Metrik	Kontrollstarts	Mit Paket	Differenz
Freier Speicher, MB	6 664–6 674	6 696	+22…+30
Nonpaged pool, MB	69,8–71,8	58,7	−11…−13
Summiertes Working Set, MB	2 036	1 959	−77
Performance der Proben	ohne Änderungen	ohne Änderungen	—

Nur die Autologger ergaben −13,2 MB nonpaged pool (separat gemessen). Wichtig: die Summe des Working Set der deaktivierten Komponenten betrug laut Inventar etwa 78 MB, der reale Zuwachs an freiem Speicher aber +22–30 MB. Die Differenz entsteht, weil ein Teil des „Deaktivierten“ ohnehin nicht gestartet war. Das ist die ehrliche Grenze punktueller Deaktivierungen ohne Entfernen von Systemkomponenten; nebenbei senkte dasselbe Paket die Hintergrundaktivität im Leerlauf um weitere 24 %.

Registry-Parameter des Speichermanagers (Größen der Pools, des System-Cache und Ähnliches) wurden in diesem Experiment nicht einmal als Gewinnquelle betrachtet: ihr Lesen und ihr praktischer Nutzen sind in „Memory Manager und System-Cache“ untersucht — einen bestätigten Nutzen für die Freigabe von RAM haben sie nicht.

Was bestätigt ist

Reproduziert (zwei Serien): das Deaktivieren von Hintergrundkomponenten gibt 1,0–1,5 GB verfügbaren Speicher frei; das summierte Working Set sank um 51 % (Serie 1), der belegte Speicher um 49 % und das Commit-Volumen um 52 % (Serie 2).
Gemessen: der automatische Neustart gestoppter Shell-Prozesse innerhalb von 20 Sekunden; commit sinkt dabei nicht (in unserem Experiment stieg es um 12,6 MB).
Gemessen: das Beenden von File Explorer ergibt kein stabiles Wachstum des freien Speichers; ausgelagerte Seiten bleiben in Standby.
Dokumentiert: das Auslagern von Seiten aus dem Working Set versetzt sie in einen Übergangszustand, zwischengespeichert im RAM; Standby-Speicher wird in verfügbar berücksichtigt.
Gemessen: punktuelle Deaktivierungen über einem optimierten System ergeben +22–30 MB freien Speicher bei unveränderter Performance; die Summe des Working Set des Deaktivierten ist nicht gleich dem Zuwachs an freiem Speicher.

Was nicht bestätigt ist

Drittanbieter-„RAM-Optimierer“ wurden nicht direkt getestet: geprüft wurde die Mechanik (Leeren des Working Set), auf der sie aufbauen.
Das Deaktivieren der pagefile wurde nicht gemessen; bekannt ist nur, dass die pagefile für Crash Dump und die Grenze des Commit-Volumens benötigt wird.
Die Übertragung der Werte auf Maschinen mit anderem RAM-Volumen, anderen Builds und physischer Hardware.
Die Stabilität der Einsparung über lange Fenster: die Messungen wurden im eingeschwungenen Leerlauf durchgeführt.

Einschränkungen

Virtuelle Maschine mit 8 GB RAM: die absoluten Zahlen sind an diese Konfiguration gebunden; ein Profil mit einem größeren Volumen an Hintergrundkomponenten wird mehr freigeben, ein „stilles“ System weniger.
Die Summe des Working Set über die Prozesse überschätzt den eindeutigen Fußabdruck wegen geteilter Seiten; wir führen daneben genau deshalb private bytes an.
Die Messschicht belegte selbst spürbar Speicher (bis zu Hunderten MB Working Set in einzelnen Messungen) — die Zahlen des Zustands schließen die Anwesenheit der Messung ein.
Speicherdruck gab es im Experiment nicht (hard faults niedrig), daher haben wir nicht geprüft, ob die Einsparung Thrashing unter RAM-Mangel verringert.
Ein Teil der Freigabe hängt mit dem Deaktivieren von Komponenten des Microsoft Defender-Schutzes zusammen — das ist ein Kompromiss mit der Sicherheit und nicht Speicher, der gratis anfiel.

Die Untersuchung und die verwendeten Werkzeuge gehören dem Entwickler von BoosterX, und BoosterX ist ein Windows-Optimierer, daher ist die Messung des Optimierungseffekts sein direktes Interesse. Die Methodik und die Anwendungsgrenzen sind oben beschrieben, und die Schlussfolgerungen lassen sich anhand offener Daten und der aufgeführten öffentlichen Quellen überprüfen. Negative Ergebnisse zu populären Methoden der „Speicherfreigabe“ sind gleichberechtigt mit positiven veröffentlicht.

Praktische Schlussfolgerung

Was laut diesem Experiment tatsächlich Speicher freigibt:

nicht genutzte Anwendungen schließen — ihre private bytes werden vollständig freigegeben;
wirklich unnötige Hintergrundkomponenten deaktivieren — der gemessene Gesamteffekt ist in „Stiller Leerlauf“ beschrieben; das ist die einzige der geprüften Methoden, die Gigabytes ergab, und ihr Preis ist der Verlust der entsprechenden Funktionen;
das Ergebnis anhand von commit und verfügbarem Speicher bewerten (Task Manager → „Leistung“ → „Arbeitsspeicher“), nicht anhand der Zeile „frei“.

Was nicht funktioniert:

das erzwungene Beenden von Systemprozessen: Windows startet sie in Sekunden neu, commit steigt;
„RAM-Optimierer“ und das Leeren von Standby: ausgelagerte Seiten bleiben als Cache im RAM, und ihre Rückkehr in den Betrieb kostet weiche Seitenfehler;
Registry-Parameter des Speichermanagers.

Standby-Speicher ist kein Problem, sondern die Arbeit des Cache: „verfügbar“ schließt ihn bereits ein. Belassen Sie die pagefile unter der Verwaltung des Systems: sie wird für die Grenze des Commit-Volumens und für Crash Dumps benötigt.

Wiederherstellung des Zustands

Die Experimente wurden in einer isolierten virtuellen Maschine auf Testzweigen des Zustands durchgeführt; nach den Messungen wurden die Testzweige zurückgesetzt, die Maschine in den Ausgangszustand zurückversetzt. Der Artikel empfiehlt nicht, Systemprozesse zu beenden oder die pagefile zu deaktivieren, daher ist keine separate Wiederherstellungsaktion auf dem Computer des Nutzers erforderlich.

Öffentliche Primärquellen

Microsoft: Working Set — Zusammensetzung des Working Set, Auslagern von Seiten, im RAM zwischengespeicherte Übergangsseiten und die Funktionen EmptyWorkingSet/SetProcessWorkingSetSize; geprüft am 2026-09-20.
Microsoft: EmptyWorkingSet — die von Tools zur „Speicheroptimierung“ verwendete API; geprüft am 2026-09-20.
Microsoft: About Memory Management — das Modell des virtuellen Speichers und der geteilten Seiten; geprüft am 2026-09-20.
Microsoft: Introduction to the page file — commit charge, die Grenze des Commit-Volumens und die Rolle der pagefile; geprüft am 2026-09-20.
Memory Manager und System-Cache — Untersuchung der Registry-Parameter des Speichermanagers.
Stiller Leerlauf: der Windows-Hintergrund vor und nach der Optimierung — das Messprotokoll und die übrigen Metriken desselben Experiments.
Wie wir Windows untersuchen — Evidenzstufen und Messregeln.

Änderungsverlauf

2026-09-20: Die Zahlen wurden an die Tabellen der Serien angeglichen: „nachher“ von Serie 1 — 1 868/660 MB, die Zuordnung der Prozentsätze nach Metriken und Serien präzisiert; der Disclaimer zum Interessenkonflikt wurde bis zur vollständigen Formulierung verstärkt.
2026-09-20: Erste Veröffentlichung — das Speicherinventar in zwei Serien, die negativen Experimente mit dem Beenden von Prozessen und dem Leeren, der ehrliche Zuwachs punktueller Deaktivierungen.