Leerlauf: Windows-Hintergrundaktivität vor und nach der Optimierung
Auf dieser Seite
Kurzantwort
Abschnitt betitelt „Kurzantwort“Das Deaktivieren von Windows-Hintergrundkomponenten sorgt tatsächlich für einen ruhigeren Leerlauf: In zwei unabhängigen Messreihen sank die Zahl der Prozesse um 49–56 %, die CPU-Auslastung im Leerlauf um 17–67 % und der Umfang der Speicherzusagen (Commit) in der zweiten Reihe um 52 %. Unter voller CPU-Last stieg der Durchsatz jedoch nur um 0,2–0,5 %. Ein „ruhiger Leerlauf“ bedeutet eine bestätigte Verringerung der Hintergrundaktivität und der Ressourcenkonkurrenz, nicht mehr FPS: Die Auswirkungen auf Spiele wurden in dieser Untersuchung nicht gemessen.
Status: Die Wirkungsrichtung wurde in zwei unabhängigen Messreihen mit demselben Windows-Build 11 in einer virtuellen Maschine reproduziert. Die Werte unterscheiden sich zwischen den Reihen, weil die Hintergrundaktivität von Windows in Schüben auftritt: In einem Zeitfenster mit einem Scan von Microsoft Defender beträgt der Unterschied bei der CPU-Auslastung −67 %, in einem bereits ruhigen Zeitfenster −17 %.
Überprüfbare Aussage
Abschnitt betitelt „Überprüfbare Aussage“Wir haben vier Aussagen überprüft:
- Das Deaktivieren von Hintergrundkomponenten verringert die Systemaktivität im Leerlauf deutlich.
- Es verringert die Aktivität in den ersten Minuten nach dem Start deutlich.
- Es reduziert den Speicherverbrauch deutlich.
- Es führt unter voller CPU-Last zu einem messbaren Leistungszuwachs.
Untersuchungsumfang
Abschnitt betitelt „Untersuchungsumfang“- Windows 11 Pro, Build 26300.9457 (26H2);
- virtuelle Maschine: 4 vCPU, 8 GB RAM, VMware-Virtualisierung;
- zwei Zustände derselben Installation: Ausgangszustand („vorher“) und nach Anwendung des BoosterX-Optimierungsprofils (zum Messzeitpunkt aktueller Build);
- zwei unabhängige Messreihen: 2026-09-18 und 2026-09-19; die Zustände wurden auf unabhängigen Festplattenkopien verglichen, damit die Messungen einander nicht beeinflussten;
- Phasen: 5 Minuten nach dem Start, 5 Minuten Stabilisierung, 5 Minuten Leerlauf;
- kurze synthetische Lasttests: 1, 4 und 8 Threads, Speicherlast, getaktete Last und Prioritätsmischungen.
Die Messungen umfassten keine realen Spiele, GPU-Last, physische Hardware oder längere Zeiträume (Stunden und Tage).
Eine separate Messreihe auf einem physischen PC mit Ryzen 7 7800X3D, vier Phasen und Messungen in Spielen wurde im Artikel „BoosterX: Windows-Hintergrundaktivität und FPS in CS2“ veröffentlicht. Ihre Ergebnisse werden nicht mit dieser Messreihe in virtuellen Maschinen zusammengeführt.
Methodik
Abschnitt betitelt „Methodik“Das Protokoll entspricht „Wie wir Windows untersuchen“:
- jede Phase wurde mit ETW-Tracing (Windows Performance Recorder, leichte Profile für CPU, Datenträger, Dateien und Netzwerk) und Leistungsindikatoren in Intervallen von 5 Sekunden (System) und 15 Sekunden (Prozesse) aufgezeichnet;
- die Phase „nach dem Start“ wurde durch einen kontrollierten Neustart eingeleitet und bei einer Betriebszeit von etwa einer Minute gestartet;
- in jeder Aufzeichnung wurde die Zahl verlorener Ereignisse überprüft — in allen angegebenen Zeitfenstern beträgt sie null;
- die Mittelwertbildung erfolgte ausschließlich über vollständige Fünf-Sekunden-Intervalle innerhalb der Phasengrenzen (59 Intervalle pro Phase);
- in Reihe 2 wurde der erste Durchlauf „vorher“ ausgeschlossen, weil die virtuelle Maschine in den Energiesparmodus wechselte; verwendet wurde die Wiederholung;
- die Lasttests wurden jeweils zweimal ausgeführt, angegeben sind die Mediane; die CPU-Auslastung wurde auf vier vCPU normiert.
„Vorher“ und „nachher“ bezeichnen Zustände derselben Windows-Installation: „nachher“ wurde durch Anwendung des Optimierungsprofils erreicht, „vorher“ ist der Ausgangszustand. Geändert wurde ein ganzes Bündel von Einstellungen; der isolierte Beitrag einzelner Deaktivierungen wurde daher nicht bewertet.
Ergebnisse
Abschnitt betitelt „Ergebnisse“Leerlauf
Abschnitt betitelt „Leerlauf“Reihe 1 (2026-09-18) — stabiler Leerlauf ohne aktive Wartung:
| Metrik | Vorher | Nachher | Änderung |
|---|---|---|---|
| CPU-Auslastung, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| Kontextwechsel, /s | 469 | 381 | −19 % |
| Prozesse (Durchschnitt) | 134,9 | 69,3 | −49 % |
| Threads (Durchschnitt) | 1 444,6 | 738,7 | −49 % |
| CPU-Auslastung aller Prozesse, % | 1,22 | 1,06 | −13 % |
| Verfügbarer Speicher, MB | 5 490 | 6 518 | +1 028 |
| Datenträgerlesevorgänge, KB/s | 22,6 | 24,4 | +8 % |
| Datenträgerschreibvorgänge, KB/s | 311,3 | 262,1 | −16 % |
| Netzwerk (Empfang), KB/s | 132,6 | 2,2 | −98 % |
| Netzwerk (Senden), KB/s | 43,2 | 4,7 | −89 % |
Reihe 2 (2026-09-19) — dasselbe Leerlaufzeitfenster, aber im Zustand „vorher“ lief ein Hintergrundscan von Microsoft Defender:
| Metrik | Vorher | Nachher | Änderung |
|---|---|---|---|
| CPU-Auslastung, % | 33,37 | 11,03 | −67 % |
| Kontextwechsel, /s | 3 737 | 291 | −92 % |
| Prozesse (Durchschnitt) | 142,3 | 61,9 | −56 % |
| Threads (Durchschnitt) | 1 494,7 | 637,1 | −57 % |
| Verfügbarer Speicher, MB | 5 174 | 6 653 | +1 479 |
| Belegter physischer Speicher, MB | 3 017 | 1 538 | −49 % |
| Speicherzusagen (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 % |
| Datenträgerlesevorgänge, MB/s | 7,42 | 0,01 | −99,9 % |
| Datenträgerschreibvorgänge, MB/s | 4,57 | 0,23 | −95,0 % |
Im Leerlauf gab es in Reihe 2 in beiden Zuständen kaum Netzwerkaktivität (Dutzende Byte pro Sekunde); daher werden dafür keine Netzwerkzeilen angegeben. Der Unterschied zwischen den Reihen ist kein Widerspruch, sondern eine Eigenschaft der Hintergrundaktivität selbst: Wenn Windows Wartungsarbeiten ausführt, spart das Deaktivieren von Hintergrundkomponenten mehr ein; in einem bereits ruhigen Zeitfenster ist die Einsparung geringer.
Die ersten Minuten nach dem Start
Abschnitt betitelt „Die ersten Minuten nach dem Start“| Metrik | Reihe 1 (vorher → nachher) | Reihe 2 (vorher → nachher) |
|---|---|---|
| CPU-Auslastung, % | 3,42 → 2,59 | 14,62 → 11,88 |
| Kontextwechsel, /s | 1 114 → 600 | 1 257 → 393 |
| Prozesse | 132 → 74 | 139 → 64 |
| Threads | — | 1 719 → 746 |
| Belegter physischer Speicher, MB | — | 2 821 → 1 581 |
| Verfügbarer Speicher, MB | — | 5 370 → 6 610 |
| Datenträgerlesevorgänge, KB/s | — | 826 → 433 |
| Datenträgerschreibvorgänge, KB/s | 634 → 418 | 709 → 298 |
| Netzwerk (Empfang), KB/s | — | 1,15 → ~0 |
Ein Gedankenstrich bedeutet, dass die Metrik für diese Phase in der jeweiligen Reihe nicht erfasst wurde.
Zusammensetzung und Speicher
Abschnitt betitelt „Zusammensetzung und Speicher“Bestandsaufnahme im Leerlauf (Reihe 1):
| Vorher | Nachher | |
|---|---|---|
| Prozesse | 136 | 70 |
| Threads | 1 679 | 842 |
| Gesamter Working Set, MB | 3 841 | 1 868 |
| Gesamte Private Bytes, MB | 1 524 | 660 |
Die größten Speicherverbraucher vor der Optimierung: Antivirenprozess MsMpEng.exe (257 MB), explorer.exe (213 MB), StartMenuExperienceHost (144 MB), msedge.exe (133 MB), SearchHost.exe (122 MB). Nach der Optimierung standen explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB) und StartMenuExperienceHost (106 MB) an der Spitze der Liste.
Der verfügbare Speicher stieg um 1,0–1,5 GB, während der Umfang der Speicherzusagen (Commit) um 52 % sank. Was davon tatsächlich „freigegeben“ werden kann und warum die Summe der Working Sets der Prozesse nicht mit dem freien Speicher gleichzusetzen ist, wird in „Wie viel Speicher lässt sich unter Windows tatsächlich freigeben“ erläutert.
Unter Volllast
Abschnitt betitelt „Unter Volllast“Kurze synthetische Tests (Reihe 2, Mediane aus zwei Wiederholungen):
| Szenario | Änderung des Durchsatzes | CPU-Auslastung: vorher / nachher |
|---|---|---|
| Ein Thread | +5,4 % | 21,9 / 22,6 % |
| Vier Threads (voll) | +0,19 % | 88,9 / 89,4 % |
| Acht Threads (voll) | +0,50 % | 88,9 / 88,8 % |
| Speicherlast | +11,2 % | 84,8 / 87,5 % |
| Getaktet (Pausen 1 ms) | +5,4 % | 64,3 / 67,7 % |
| Gemischte Prioritäten | +8,5 % | 21,2 / 22,5 % |
| Hintergrundpriorität | +77,1 % | 38,8 / 65,2 % |
Bei voller Last auf vier Threads nutzte der Arbeitsprozess sowohl vor als auch nach der Optimierung etwa 89 % der Kapazität von vier vCPU. Die verbleibenden ~11 % in der virtuellen Maschine können nicht als vermeidbares „Windows-Rauschen“ bezeichnet werden: Die Planung durch den Hypervisor ist in der Gastaufzeichnung nicht sichtbar. Die Arbeits-Threads waren gleichmäßig verteilt (Abweichung des Arbeitsvolumens zwischen ihnen: 0,994–0,997); es wurde kein Aushungern beobachtet, und die CPU-Warteschlange war im Leerlauf nach der Optimierung praktisch leer.
Woher die Hintergrundaktivität kommt
Abschnitt betitelt „Woher die Hintergrundaktivität kommt“Gemessene Quellen der Hintergrundaktivität im Zustand „vorher“:
- Antivirenscan — wichtigste Quelle im Zeitfenster von Reihe 2: Der Prozess
MsMpEng.exeverbrauchte während des fünfminütigen Leerlaufzeitfensters 212 CPU-Sekunden; - im Ausgangszustand liefen der Suchdienst, der SysMain-Dienst, Telemetrie, der Druckspooler und weitere Komponenten — das Optimierungsprofil versetzt etwa 50 Hintergrunddienste und 58 geplante Aufgaben in den deaktivierten Zustand;
- nach dem Start wird die Aktivität vom Windows-Update-Orchestrator begleitet.
Das Deaktivieren von Hintergrundkomponenten beseitigt die Hintergrundaktivität nicht vollständig: Im optimierten Zustand lief weiterhin die Bewertung der Anwendungskompatibilität (etwa 3,7 ms CPU pro Sekunde im Wartungszeitfenster); die gesamte verbleibende Hintergrundaktivität im stabilen Leerlauf betrug 4,8 ms CPU pro Sekunde — etwa 0,12 % der Kapazität von vier vCPU (gemessen anhand der Aufzeichnung).
Was bestätigt wurde
Abschnitt betitelt „Was bestätigt wurde“- Reproduziert (zwei unabhängige Reihen): Zahl der Prozesse −49…−56 %, Zahl der Threads −49…−57 %, verfügbarer Speicher +1,0–1,5 GB.
- Gemessen (Reihe 2): Commit im Leerlauf −52 %; belegter physischer Speicher im Leerlauf −49 % und in der Phase nach dem Start −44 %.
- Gemessen: CPU-Auslastung im Leerlauf −17 % in einem ruhigen Zeitfenster und −67 % in einem Zeitfenster mit Scan; Kontextwechsel −19 % und −92 %; DPC −78 % (Zeitfenster von Reihe 2); die Aktivität nach dem Start war in beiden Reihen geringer.
- Gemessen: Unter voller CPU-Last stieg der Durchsatz um +0,19 % (4 Thread) und +0,50 % (8 Threads); bei unvollständiger und gemischter Last um +5,4 bis +11,2 %.
- Gemessen: Eine Last mit Hintergrundpriorität wurde um 77,1 % schneller — im Zustand „vorher“ konkurrierte sie mit der Hintergrundaktivität von Windows selbst, einschließlich des Antivirenscans.
- Beobachtet: Die wichtigsten Quellen der Hintergrundaktivität waren Antivirenscans, Wartungsarbeiten und Kompatibilitätsaufgaben; nach der Optimierung lag die verbleibende Hintergrundaktivität nahe null, war aber nicht null.
Was nicht bestätigt wurde
Abschnitt betitelt „Was nicht bestätigt wurde“- Höhere FPS, geringere Eingabelatenz oder kürzere Frame Times in realen Spielen: nicht gemessen. Synthetische CPU-Tests bilden kein Spiel mit GPU ab und belegen keine Auswirkungen auf Spiele.
- Der isolierte Beitrag jeder einzelnen Deaktivierung: Es wurde ein Bündel von Änderungen angewendet.
- Die Übertragbarkeit absoluter Werte auf physische Hardware, andere Builds und andere Optimierungsprofile.
- Stabilität über längere Zeiträume: Jede Phase dauerte 5 Minuten; die Hintergrundaktivität von Windows tritt in Schüben auf, daher wurde kein „durchschnittlicher Tag“ gemessen.
Einschränkungen
Abschnitt betitelt „Einschränkungen“- Die Messungen wurden in einer virtuellen Maschine durchgeführt. Die Virtualisierung trägt selbst zu DPC/ISR bei und verbirgt die Hostplanung; auf physischer Hardware fallen die absoluten Werte anders aus. Die Anteile und die Richtung des Vorher-Nachher-Vergleichs bleiben unter gleichen Bedingungen erhalten.
- Die ISR-Metrik wurde aus den Tabellen ausgeschlossen: In der virtuellen Maschine weicht der ISR-Zähler über PDH um etwa 10 % von den über ETW erfassten Interrupt-Handlern ab und ergibt keine exakte Summe.
- Das Zeitfenster „vorher“ in Reihe 2 enthielt einen aktiven Defender-Scan, und die Hostauslastung unterschied sich zwischen den Zeitfenstern (durchschnittlich 44 % gegenüber 24 %). Daher beziehen sich die Werte auf konkrete Zeitfenster; die Wirkungsrichtung wurde in zwei Reihen bestätigt.
- In Reihe 1 wurde ein Teil der Leerlaufphase durch eine externe Pause der virtuellen Maschine von etwa 26 Sekunden unterbrochen; die Aufzeichnung endete nach der Wiederaufnahme, es gingen keine Ereignisse verloren.
- Die Lasttests umfassten zwei Wiederholungen: Es handelt sich um deskriptive Statistik; die statistische Signifikanz wurde nicht bewertet.
- Ein Teil des Leerlaufgewinns hängt mit der Deaktivierung von Schutzkomponenten von Microsoft Defender zusammen. Ein System ohne Virenschutz ist ein bewusster Kompromiss und keine Optimierung ohne Nachteile; der Schutz sollte nur deaktiviert werden, wenn man sich der Folgen bewusst ist.
- Die Messebene (Tracing und Leistungsindikatoren) erzeugt selbst eine geringe Hintergrundlast; diese ist in beiden Zuständen vorhanden.
Die Untersuchung und die verwendeten Tools stammen vom Entwickler von BoosterX, der daher ein unmittelbares Interesse an den Ergebnissen hat. Methodik und Grenzen der Anwendbarkeit sind oben beschrieben; die Schlussfolgerungen lassen sich anhand der offenen Daten und der aufgeführten öffentlichen Quellen überprüfen.
Praktisches Fazit
Abschnitt betitelt „Praktisches Fazit“Die Verringerung des Hintergrundrauschens ist ein realer, zweimal reproduzierter Effekt: halb so viele Prozesse und Threads, halb so viele Speicherzusagen, eine um eine Größenordnung geringere Datenträger- und Netzwerkaktivität im Leerlauf. Das ist für sich genommen nützlich — für die Reaktionsfähigkeit des Systems, Hintergrundaufgaben, Temperatur, Lüftergeräusche und Akkulaufzeit — und erfordert keine Versprechen zu FPS.
Was man davon nicht erwarten sollte: einen Leistungszuwachs unter Volllast. Wenn die CPU bereits mit nützlicher Arbeit zu ~89 % ausgelastet ist, fügt das Deaktivieren der Hintergrundaktivität die verbleibenden 11 % nicht hinzu — in der virtuellen Maschine gehören sie nicht zu Windows. Je nachdem, womit das System zum Zeitpunkt des Vergleichs beschäftigt ist, fällt der sichtbare Effekt unterschiedlich aus: In einem Wartungszeitfenster ist der Unterschied um ein Vielfaches größer, in einem ruhigen Zeitfenster moderat.
Empfehlung: Bewerten Sie die Hintergrundaktivität vor und nach Änderungen auf Ihrem eigenen Computer (Task-Manager → „Leistung“ und „Prozesse“, Ressourcenmonitor), statt sich an fremden Prozentangaben zu orientieren. Wenn Sie FPS in einem bestimmten Spiel verbessern möchten, messen Sie diese vor und nach der Änderung direkt.
Wiederherstellung des Zustands
Abschnitt betitelt „Wiederherstellung des Zustands“Beide Reihen wurden in isolierten virtuellen Maschinen auf unabhängigen Festplattenkopien durchgeführt; nach den Messungen wurden die Maschinen in ihren Ausgangszustand zurückversetzt. Der Artikel erfordert keine Änderung von Einstellungen durch die Leser, daher ist auf dem Computer des Nutzers keine separate Wiederherstellungsmaßnahme erforderlich.
Öffentliche Primärquellen
Abschnitt betitelt „Öffentliche Primärquellen“- Microsoft: Windows Performance Recorder — das in der Methodik verwendete Tool zur Aufzeichnung von ETW-Traces; geprüft am 2026-09-20.
- Microsoft: About Event Tracing — ETW-Modell und Überprüfung verlorener Ereignisse; geprüft am 2026-09-20.
- Microsoft: Microsoft Defender Antivirus unter Windows — Defender-Prozesse und -Dienste, einschließlich
MsMpEng.exe(„Antimalware Service Executable“ im Task-Manager); geprüft am 2026-09-20. - Wie wir Windows untersuchen — Evidenzstufen und Messprotokoll.
- Service Host und Windows-Hintergrundkomponenten 11 — wie Windows Hintergrunddienste auf Prozesse verteilt.
- Wie viel Speicher lässt sich unter Windows tatsächlich freigeben — ausführliche Analyse des Speichers aus demselben Experiment.
- Desktop im Vergleich zum Anmeldebildschirm — Fortsetzung: Woraus sich das Rauschen einer Benutzersitzung zusammensetzt.
Änderungsverlauf
Abschnitt betitelt „Änderungsverlauf“- 2026-09-20: Erstveröffentlichung — zwei unabhängige Messreihen zum Leerlauf, Phasen nach dem Start, Bestandsaufnahme und Lasttests.
- 2026-09-20: Zuordnung der Ergebnisse zu den Messreihen präzisiert (Commit und belegter physischer Speicher — nur Reihe 2; Prozesse −49…−56 %); der Haftungsausschluss zum Interessenkonflikt wurde an die kanonische Formulierung angepasst.