Desktop vs. Anmeldebildschirm: Was kostet eine Benutzersitzung

Kurze Antwort

Ein angemeldeter Desktop ist teurer als der Anmeldebildschirm, aber viel weniger, als es scheint: Im stationären Leerlauf verbraucht er etwa 0.012 Kerne gegenüber 0.0074 am Anmeldebildschirm, also 1.6-mal mehr. Der wahre Preis einer Benutzersitzung ist die erste Stunde nach der Anmeldung: Der Defender-Scan und die Welle der Store-Updates verbrauchen zusammen etwa 79% der gesamten CPU-Aktivität des Fünf-Stunden-Fensters. Die Shell selbst ist nahezu kostenlos: explorer, sihost, dwm und der Start-Feed verbrauchen zusammen etwa 2.3% des Budgets.

Status: Gemessen in einem einzigen 5-stündigen Durchlauf auf Windows 11 26H2 in einer virtuellen Maschine. Der Vergleich mit dem Anmeldebildschirm erfolgte auf demselben Build und Snapshot. Die Übertragung auf physische Hardware, andere Builds und Nachtfenster wurde nicht geprüft.

Überprüfbare Aussage

Wir haben vier Aussagen geprüft:

1. Ein angemeldeter Desktop ist deutlich teurer als der Leerlauf des Anmeldebildschirms.
2. Der Hauptpreis der Sitzung ist die ständige Arbeit der Shell.
3. Die Benutzersitzung verändert das Netzwerkprofil des Leerlaufs merklich.
4. Die geplanten Mechanismen von Windows (Updates, Dienst-Timer) verhalten sich in der Sitzung genauso wie ohne sie.

Untersuchungsbereich

• Windows 11 Pro, build 26300.9457 (26H2), virtuelle Maschine 4 vCPU / 8 GB;
• saubere Installation ohne Fremdsoftware; Ruhezustand und Konfigurationsupdates wurden nicht deaktiviert;
• zwei Durchläufe auf einem Snapshot: Anmeldebildschirm ohne Benutzersitzung (6 Stunden) und angemeldeter Desktop (4 Stunden 46 Minuten, vorzeitig beendet);
• die Anmeldung erfolgte manuell; die Beobachtung begann nach Bestätigung des Shell-Starts;
• minütliche Snapshots: CPU der Prozesse, Mengen laufender Dienste, Speicher und bestehende Verbindungen.

Die Messungen umfassten keine physische Hardware, keine reale Arbeit am Computer, keine GPU-Last und keine Nachtfenster (die täglichen Wartungsaufgaben fielen nicht ins Bild).

Methodik

Für jeden Prozess wurden einmal pro Minute die kumulierten CPU-Sekunden erfasst; die Differenz benachbarter Snapshots ergibt den Verbrauch für das Intervall. Dienste wurden anhand der Mengen laufender Instanzen und Übergänge verfolgt; das Netzwerk anhand der zum Zeitpunkt des Snapshots bestehenden Verbindungen. Das Rauschen der eigenen Überwachung (etwa 3.6% CPU) wurde aus der Interpretation ausgeschlossen. Beide Durchläufe wurden anhand der auf eine Stunde normierten Werte verglichen.

Ergebnisse

Zusammenfassender Vergleich

Metrik	Anmeldebildschirm	Desktop	Differenz
CPU im Durchschnitt über das Fenster, Kerne	0.0098	0.0492	×5.0
CPU der stationären Stunde, Kerne	0.0074	0.0120	×1.61
CPU der ersten Stunde nach Anmeldung/Start, Kerne	0.0185	0.2942	×15.9
Starts von Systemprozessen pro Stunde	26.1	79.5	×3.05
Minuten mit Aktivität über 1 CPU-s	5%	13.5%	×2.4 nach Anteil
Bestehende Verbindungen pro Stunde (Endpoint-Minuten)	88.3	228.1	×2.58
Dauerhafte Verbindungen	1	3	×3

Zentraler Fakt: Die Durchschnittszahl „×5“ besteht fast vollständig aus der ersten Stunde. Die stationären Stunden des Desktops sind homogen (0.0118–0.0127 Kerne) und driften nicht.

Die erste Stunde: zwei Wellen

Welle	Anteil	Was geschah
Defender-Anmeldescan	~55% CPU der Stunde	Der Antivirenprozess lief etwa 0.7 Kerne 8 Minuten lang ununterbrochen; der Scan begann unmittelbar nach der Anmeldung
Store- und USO-Update	~27% CPU der Stunde	Installation von 24 Anwendungen, Download von etwa 880 MB über Delivery Optimization, einschließlich Peering

Die Store-Welle ist gesondert wichtig: In diesem Durchlauf kamen die Updates über Microsoft Store und Delivery Optimization, nicht über das klassische Windows Update. Die Netzwerkspitze der Anmeldung ist 67-mal größer als das stationäre Niveau.

Stationärer Leerlauf: wer arbeitet

Quelle	CPU-Sekunden pro Stunde	Kommentar
Allgemeines svchost-Gerüst	13–14	Dienst-Timer
Kernel (System)	8	Teil der Arbeit von Defender und Infrastruktur
Antivirus außerhalb des Scans	~3	Periodische Prüfungen
Shell (explorer, sihost, dwm, Start-Feed, Suche, Widgets, OneDrive)	4.1	2.3% des Budgets; „Desktop-Leerlauf“ ist nahezu kostenlos

Drei Viertel der Differenz bei den Prozessstarts entfallen auf periodische Mechanismen der Benutzersitzung: der Hintergrundhost der UWP-Aufgaben (Zyklus etwa 13 Minuten), RuntimeBroker und SoftLanding alle 15 Minuten.

Netzwerk: drei dauerhafte Verbindungen und zwei neue Timer

Am Anmeldebildschirm besteht eine dauerhafte Verbindung. Am Desktop sind es drei: zwei hält der Start-Feed (MSN-Inhalte: Wetter, Nachrichten, Live-Kacheln) ab der ersten Minute und ohne Unterbrechungen, die dritte ein Systembenachrichtigungsdienst. Der CPU-Preis des Feeds über das gesamte Fenster beträgt weniger als 2 CPU-Sekunden, aber die Verbindung selbst besteht immer.

Neue Timer der Sitzung: OneDrive synchronisiert alle 32–33 Minuten über zwei Verbindungen, Edge-Updates werden alle paar Stunden geprüft. Defender-Signaturprüfungen laufen in Clustern alle 30–40 Minuten. Der gesamte Datenverkehr ist auf die Microsoft-Infrastruktur gerichtet; fremde Verbindungen wurden nicht beobachtet.

Dienst-Timer

Die Aktualisierung der Gruppenrichtlinie läuft am Desktop alle 16–17 Minuten zyklisch gegenüber etwa 80 Minuten am Anmeldebildschirm. Der Anwendungsdienst (AppXSvc) und der Lizenzschutz (sppsvc) behielten denselben Rhythmus. Fünf Sitzungsdienste bestehen dauerhaft, darunter Benachrichtigungen des Benutzers und Clipboard.

Speicher

Es gibt keine Systemlecks: Der Antivirus gab nach dem Scan 81 MB frei, die Shell wuchs nur in den ersten 30 Minuten und erreichte ein Plateau. Die Anzahl der Prozesse beträgt 130–153 gegenüber 84–98 am Anmeldebildschirm.

Was bestätigt wurde

• Gemessen: Der stationäre Desktop ist 1.61-mal teurer als der Anmeldebildschirm in Bezug auf die CPU; die erste Stunde nach der Anmeldung ist der Hauptpreis der Sitzung (79% CPU des Fensters).
• Gemessen: Der Start-Feed hält zwei dauerhafte Verbindungen während der gesamten Sitzung; OneDrive synchronisiert alle 32–33 Minuten.
• Gemessen: Die Store-Welle der Anmeldung lud etwa 880 MB über Delivery Optimization; die Netzwerkspitze der Anmeldung ist 67-mal größer als die stationäre.
• Gemessen: Die Shell (explorer, dwm, Start-Feed, Suche, Widgets) verbraucht im stationären Leerlauf etwa 2.3% CPU.
• Beobachtet: Die Updates kamen über Store/DO, nicht über das klassische WU; die nächtlichen Wartungsaufgaben fielen nicht ins Bild.

Was nicht bestätigt wurde

• Das Verhalten auf physischer Hardware und auf anderen Windows-Builds.
• Nachtfenster und tägliche Wartungsaufgaben (der Durchlauf war tagsüber und wurde vorzeitig beendet).
• Der Einfluss des Deaktivierens des Start-Feeds oder von OneDrive auf diese Zahlen: Wir haben nur ihren Beitrag gemessen, das Deaktivieren wurde nicht getestet.
• Der Einfluss auf FPS und die endgültige Spielleistung: nicht gemessen.

Einschränkungen

Ein Durchlauf pro Zustand, virtuelle Maschine, Tagesfenster. Die Hintergrundarbeit von Windows erfolgt in Wellen, daher ist die Übertragung absoluter Werte auf andere Hardware und einen ganzen Tag nicht gerechtfertigt. Prozesse kürzer als eine Minute und UDP-Datenverkehr (DNS, NTP) sind nicht vollständig sichtbar. Ein Teil der Protokolle erfasste während des zweiten Durchlaufs keine Ereignisse; die Dienstübergänge wurden anhand der Snapshots rekonstruiert.

Praktische Schlussfolgerung

Das „Hintergrundrauschen von Windows“ zerfällt in drei verschiedene Dinge, und man muss sie unterschiedlich bekämpfen. Die Post-Login-Wellen (Defender-Scan und Store-Updates) liefern den größten Teil der CPU — sie lassen sich nicht durch feine Einstellungen abschalten, aber sie enden von selbst. Die System-Metronome (WMI-Polling, Lizenzprüfungen, OneDrive-Timer) sind ein stabiler, aber kleiner Hintergrund. Die Shell ist nahezu kostenlos.

Praktische Konsequenzen: Messen Sie die „Optimierung“ nicht anhand der ersten Stunde nach der Anmeldung, wenn Sie die Wellen nicht isolieren; um das Netzwerk zu minimieren, deaktivieren Sie den Start-Feed und OneDrive, wenn sie nicht benötigt werden; das Erwarten von „Ruhe“ unmittelbar nach dem Login ist nicht gerechtfertigt.

Wiederherstellung des Zustands

Das System wurde nicht verändert: Beide Durchläufe sind reine Beobachtung ohne Änderungen an Einstellungen, Diensten und Registry. Die virtuelle Maschine wurde nach den Messungen auf einen sauberen Snapshot zurückgesetzt.

Quellen und Grenzen

Die Messungen wurden von BoosterX Research auf der beschriebenen virtuellen Maschine durchgeführt. Die Untersuchung gehört dem Entwickler von BoosterX, der Entwickler hat ein direktes Interesse am Ergebnis; Methodik und Einschränkungen sind oben beschrieben, die ursprünglichen Beobachtungen können anhand der offenen Methodik wiederholt werden.

• Microsoft: Delivery Optimization, geprüft am 2026-09-22.
• Microsoft: Connected User Experiences and Telemetry, geprüft am 2026-09-22.

Letzte Prüfung: 2026-09-22.