Warum die Taskleiste einfriert und der Explorer sich neu startet — und wie Sie den Schuldigen finden

Die Taskleiste ist keine eigene App

Alles, was Sie an der Desktop-Shell sehen — Taskleiste, Infobereich, Desktopsymbole, jedes Datei-Explorer-Fenster — lebt in einem einzigen Prozess: explorer.exe. Die von Windows 95 geerbte Architektur ist bequem und verletzlich zugleich: Ein Hänger, und die ganze Oberfläche friert; ein Crash, und alles verschwindet gemeinsam. Stirbt der Explorer, startet Windows still eine neue Instanz — deshalb erlischt die Taskleiste für eine Sekunde und kommt frisch zurück: laufende Programme überleben, aber Tray-Icons registrieren sich oft nicht sauber nach, und es bleiben Geister-Icons zurück, die beim Klick einfrieren.

Ein Einfrieren ohne Neustart ist der mildere Zwillingsbruder: Der UI-Thread des Explorers ist blockiert und wartet auf etwas, das nie zurückkommt. Die Klassiker sind eine Shell-Erweiterung, die beim Abfragen hängt, ein Tray-Programm, dessen Icon nicht mehr antwortet, ein eingebundenes Netzlaufwerk, das unerreichbar wurde, und — auf Rechnern mit zickigen Grafiktreibern — ein Display-Treiber-Reset (TDR), der die komplette Shell für Sekunden stilllegt. In Windows 11 hat das Startmenü einen eigenen Host-Prozess, aber die Taskleiste selbst wohnt weiterhin im Explorer, deshalb gilt das alte Diagnose-Skript unverändert.

Den Schuldigen in zehn Minuten in die Enge treiben

Die gute Nachricht: Der Explorer protokolliert fast alles, was er falsch macht, an zwei Orten, die die meisten Nutzer nie öffnen. Zehn Minuten mit der Ereignisanzeige und einem sauberen Start legen den Übeltäter meist namentlich bloß; Rätseln kostet mehr.

• Task-Manager > Windows-Explorer > Neu starten — die 10-Sekunden-Lösung, die die Taskleiste ohne Reboot zurückbringt
• Ereignisanzeige > Windows-Protokolle > Anwendung: Ereignis-ID 1000 (Absturz) und 1002 (Stillstand) für explorer.exe — das fehlerhafte Modul nennt den Schuldigen beim Namen
• ShellExView (NirSoft) — alle Nicht-Microsoft-Shell-Erweiterungen deaktivieren, dann hälfteweise reaktivieren, bis der Hänger zurückkehrt
• Ereignis-ID 4101, „Anzeigetreiber wurde wiederhergestellt“ — zeigt auf den GPU-Treiber, nicht auf den Explorer selbst
• net use */delete — verwaiste Netzlaufwerke trennen, die die Shell immer weiter abfragt
• Sauberer Start (msconfig) — verschwindet der Hänger, Autostart-Einträge hälfteweise wieder aktivieren

Reparaturen, die halten

Hat das fehlerhafte Modul erst einmal einen Namen, ist die Reparatur meist langweilig. Ein Absturz in einem Drittanbieter-Kontextmenü-Handler oder einem Overlay-Icon stirbt in dem Moment, in dem Sie die zugehörige App aktualisieren oder deinstallieren — Sync-Overlays und Packer sind hier Stammgäste. Zeigt die Ereignisanzeige Display-Treiber-Resets, machen Sie eine saubere GPU-Treiber-Neuinstallation, statt den Explorer zu beschuldigen: Treiber vom Hersteller laden, den alten deinstallieren, frisch installieren und erst danach die Hersteller-Panels zurückholen, die Sie wirklich nutzen.

Bei Hängern ganz ohne Absturzereignisse verdächtigen Sie Software neben dem Metall: exotische Utilities, die sich in den Explorer injizieren, Tastatur- und Maus-Suiten mit Shell-Hooks und alte Versionen beliebter Programme. Halten Sie auch den Tray ehrlich — jede Autostart-App mit Icon ist Code, mit dem der Explorer für immer reden muss, weshalb eine entschlankte Autostart-Liste ebenso vor Hängern schützt wie vor langsamen Boots. Und wenn die Hänger direkt nach einem Windows-Funktionsupdate begannen, suchen Sie zuerst auf den Herstellerseiten nach Updates der Shell-Integrationen, bevor Sie Drastisches tun: Kaputtgebrochen ist meist die Integration, nicht Windows.

Fragen und Antworten

Weiterlesen