Placebo-Test: Dämpfen feine Registry-Tweaks die Hintergrundaktivität

Kurze Antwort

Nein. Die 17 „feinen“ Registry-Parameter, die in Optimierungs-Guides als Dämpfung der Hintergrundaktivität beschrieben werden, haben den Gesamthintergrund nicht gesenkt: Registry- und Dateioperationen blieben im Bereich der natürlichen Streuung der sauberen Stunden. Ein punktueller Effekt ist nur bei zwei Mechanismen belegt: Das Deaktivieren von LLMNR setzte die entsprechenden Netzwerkanfragen auf null, und die Telemetrie-Gruppe stoppte die periodische Abfrage der DiagTrack-Konfiguration (−98–99.8%). Drei weitere Parameter wurden gelesen, zeigten aber keinen beobachtbaren Effekt.

Status: gemessen in einem einzigen A/B-Durchlauf mit vier Kontrollstunden auf Windows 11 26H2 in einer virtuellen Maschine. Das Urteil „kein Effekt“ bezieht sich auf den beobachtbaren Leerlauf-Hintergrund; für Parameter mit langer Laufzeit reichte das Messfenster nicht aus.

Zu prüfende Behauptung

Eine allgemeine: Die Anwendung eines bekannten Satzes von 17 Registry-Parametern senkt die Hintergrundaktivität eines im Leerlauf befindlichen Windows spürbar. Dazu 17 einzelne: Verändert jeder Parameter das beobachtbare Verhalten.

Untersuchungsbereich

• Windows 11 Pro, Build 26300.9457 (26H2), virtuelle Maschine, eingeschwungenes System;
• 17 Registry-Parameter aus dem Kreis der häufig empfohlenen: Telemetrie, Diagnose, Netzwerke, Kompatibilität und Suche;
• Fenster mit Parametern: 9.2 Minuten nach 3 Minuten Stabilisierung; sauberes Kontrollfenster gleicher Dauer plus vier zusätzliche Kontrollstunden desselben Laufs;
• Metriken: Prozess- und Thread-Starts, Registry-, Datei- und Netzwerkoperationen per Kernel-Tracing;
• alle Parameter gleichzeitig angewendet und unmittelbar nach der Messung wiederhergestellt.

Nicht geprüft: Szenariolast (Installation, Updates, Arbeit von Anwendungen), Parameter mit einer Laufzeitperiode länger als das Fenster, physische Hardware und andere Builds.

Methodik

Striktes A/B in einem einzigen Boot-Zyklus: Fenster mit angewendeten Parametern gegen ein sauberes Fenster gleicher Dauer, plus vier saubere Kontrollstunden zur Bewertung der natürlichen Streuung. Kernel-Tracing-Ereignisse wurden nach Prozessen gruppiert; begleitender Monitoring-Rauschen wurde ausgeschlossen. Raten wurden auf die Minute normiert; zur Robustheit gegen Spitzen wurden die Mediane der minütlichen Summen ohne die erste Minute verglichen.

Ergebnisse

Gesamthintergrund: Parität

Metrik	Mit Parametern	Sauberes Fenster	Saubere Stunden (Streuung)	Urteil
Prozessstarts/Min	2549	2601	2601	Parität
Registry-Operationen/Min	14235	14780	14394–18951	im Bereich der Streuung
Dateioperationen/Min	3098	4472	3251–4472	im Bereich der Streuung

Die natürliche Variabilität der Hintergrundstunden (bis zu 28% bei der Registry) ist größer als jeder Effekt des Satzes. Die rohen Deltas „−13% Registry“ und „−53% Dateien“ erklären sich durch eine Spitze in der ersten Beobachtungsminute, nicht durch die Parameter.

Was sich tatsächlich geändert hat

Mechanismus	Ergebnis	Beleg
Deaktivieren von LLMNR (Multicast-Namensauflösung)	LLMNR-Anfragen: 17.8–20.7 pro 10 Minuten in allen sauberen Stunden → 0	Wahrscheinlichkeit des Zufalls unter 1e-7; die gepaarte mDNS-Anfrage kam weiterhin an
Telemetrie-Gruppe (AllowTelemetry ×2 + Verbot des DiagTrack-Uploads)	Aktivität des Telemetrie-Hosts: 131–1950 Registry-Operationen/Min → 3	die periodische Abfrage der Telemetrie-Konfiguration wurde sofort gestoppt

Die Telemetrie-Gruppe wurde mit drei Parametern gleichzeitig angewendet, daher lässt sich der Beitrag jedes einzelnen in diesem Experiment nicht trennen.

Was widerlegt wurde

Parameter	Erwartet	Tatsächlich
Deaktivieren von mDNS	Beendigung der mDNS-Anfragen	Häufigkeit unverändert: 35.9 pro 10 Minuten gegenüber 29.6–35.6 in den sauberen Stunden; der Wert wird vom Dienst gelesen
Deaktivieren von NetBIOS over TCP/IP	Beendigung der NetBT-Anfragen	Kadenz identisch: 16.8 gegenüber 16.1–16.7 pro 10 Minuten
Deaktivieren von Auto-DoH	Senkung der DNS-Anfragen	ohne Änderungen; in diesem System war Auto-DoH ohnehin nicht aktiv

Was dieses Fenster nicht geprüft hat

Zehn Parameter blieben ohne Urteil: vier WDI-Diagnosen wurden im Fenster nicht gelesen, ihre Arbeitsintervalle sind länger als 9 Minuten oder zeigen sich nur bei Szenariolast; die Drosselungen des Such-Tracings wirken auf den eigenen Suchkanal, der nicht in die Erfassung einbezogen war; Kompatibilitäts- und USB-Parameter hatten im Leerlauf keine Aktivität zur Prüfung.

Ein wichtiger Nebenbefund: Die Anwendung der Parameter in den Richtlinienzweigen weckte selbst die Aktualisierung der Gruppenrichtlinie und den Anwendungsdienst auf — ein einmaliger „Preis der Anwendung“, der in einem kurzen Fenster als Aktivitätsanstieg erscheint.

Was bestätigt ist

• Gemessen: Es gibt keine summarische Senkung der Hintergrundoperationen; die Raten mit Parametern liegen innerhalb der Streuung der sauberen Stunden.
• Gemessen: Das Deaktivieren von LLMNR beendet die LLMNR-Anfragen vollständig, ohne mDNS und NetBIOS anzutasten.
• Gemessen: Die Telemetrie-Gruppe stoppt die periodische Abfrage der DiagTrack-Konfiguration (−98–99.8% Aktivität des Hosts).
• Beobachtet: Die Parameter mDNS und NetBIOS werden vom Dienst gelesen, zeigen aber keinen beobachtbaren Effekt.

Was nicht bestätigt ist

• Effekte der Parameter WDI, Kompatibilität, USB und der Such-Drosselungen: Fenster oder Beobachtungskanäle passten nicht.
• Der Beitrag jedes Telemetrie-Parameters einzeln.
• Das Verhalten auf anderen Builds und physischer Hardware.
• Alle Effekte unter Last: gemessen wurde nur der Leerlauf.

Einschränkungen

Ein Fenster pro Zustand ohne Randomisierung der Reihenfolge. Die Hintergrundvariabilität von Windows ist groß, daher stützt sich die Aussage zur Parität auf vier Kontrollstunden, nicht auf ein einziges Fensterpaar. Ein Teil der Scheduler-Journale hörte während des Fensters mit Parametern auf, Ereignisse zu schreiben; geplante Aufgaben, die in dieser Zeit ausgelöst wurden, sind an den Prozessen erkennbar, aber nicht am Journal. Die punktuellen Urteile (LLMNR, Telemetrie) sind robust: Der Effekt ist in allen Kontrollstunden vorhanden und geht im Fenster mit Parametern auf null.

Praktische Schlussfolgerung

Die Unterscheidung zwischen „Parameter wird gelesen“ und „Parameter steuert das Verhalten“ ist das Wichtigste. Von den 17 geprüften Einstellungen ändern nur zwei Gruppen tatsächlich das beobachtbare Verhalten, und beide haben ihre eigenen regulären Steuerungspunkte: LLMNR schließt in BoosterX die Einstellung „Auflösung lokaler Namen“, die Telemetrie — „Telemetrie in der Richtlinie zur Datenerfassung“ zusammen mit „Hintergrund-ETW-Autologgern“. Den übrigen Hintergrund eines im Leerlauf befindlichen Windows erzeugen Defender, WMI, Lizenzprüfungen und Store — deren „feine“ Registry-Parameter dieses Satzes dämpfen sie nicht.

Verwandte Materialien: die Untersuchung „Stiller Leerlauf“ zeigt, was den Hintergrund tatsächlich senkt; „Desktop gegen Anmeldebildschirm“ erklärt, woraus sich das Restrauschen zusammensetzt.

Wiederherstellung des Zustands

Alle 17 Werte wurden unmittelbar nach dem Stoppen der Messung wiederhergestellt; die erfolgreiche Rückkehr wurde durch Backups festgehalten. Das System wurde bis zur Wiederherstellung nicht neu gestartet.

Quellen und Grenzen

Die Messungen wurden von BoosterX Research auf der beschriebenen virtuellen Maschine durchgeführt. Die Untersuchung gehört dem Entwickler von BoosterX, daher hat der Entwickler ein direktes Interesse am Ergebnis; Methodik und Grenzen sind oben beschrieben, die Schlussfolgerungen lassen sich anhand der offenen Methodik überprüfen.

• Microsoft: LLMNR und der Parameter EnableMulticast, geprüft am 2026-09-22.
• Microsoft: Configure Windows diagnostic data, geprüft am 2026-09-22.

Letzte Prüfung: 2026-09-22.