Startmenü oder Explorer geht nicht mehr/ist langsam

Es gibt immer wieder Meldungen von Anwendern, die sich beschweren, dass die Links im Startmenü nicht mehr anklicken lassen – oder das der Windows Explorer abstürzt bzw. nichts mehr anzeigt. Manchmal scheint dies nach dem Einspielen eines Windows-Update aufzutreten. Andere Anwender (speziell bei 64-Bit-Vista-Varianten) "meckern" über eine irre langsame Reaktion beim Anklicken von Startmenüeinträgen.

Nachdem ich diese Diskussionen eine zeitlang verfolgt habe, brachte mich Frank Weitz, bei dem das Problem auftrat, auf die richtige Spur.

Das Windows-Update könnte zwar als "Casus Belli" betrachtet werden. Der "Casus Knacktus" oder "crux of the matter" (wie der Engländer sagt) liegt aber an einer ganz anderen Stelle. In der Regel sind es Kontextmenühandler von Drittsoftware, die unsauber programmiert sind und sich in die betreffende Handlerkette einklinken.

Hintergrundinfo: Die Windows-Shell ruft beim Anklicken eines Links oder bei der Anzeige eines Ordnerfensters den Einsprungpunkt für den Handler auf. An diesem Einsprung können sich Kontextmenühandler mit einer eigenen Einsprungadresse registrieren. Dabei muss der Handler sich bei der Registrierung merken, welcher "Vorgänger" dort registriert war. Wird ein Handler aktiviert, arbeitet er seine Aktionen ab und gibt dann die Kontrolle (über die gemerkte Einsprungadresse) an den nächsten Handler ab. Das letzte Glied in dieser Kette ist dann der Kontextmenühandler der Windows-Shell.

Wirft nun einer der Kontextmenühandler das "Handtuch", wird die Kette der Aufrufe unterbrochen und die Windows-Shell erhält die Kontrolle nicht zurück. Als Ergebnis tut es ein Startmenülink oder irgend etwas im Explorer nicht mehr.

Anmerkung: Unter microsoft.public.windows.vista.general findet sich ein Thread, dessen Quintessenz originär auf die richtige Ursache zeigt.

Abhilfe: Es gilt, den fehlerhaften Kontextmenühandler bzw. dessen "Mutterprogramm" zu identifizieren.

Ansatz 1: Mit Florett oder Skalpell

Diese Methode erfordert etwas Fingerspitzengefühl und Verständnis für die Zusammenhänge, ermöglicht aber sehr genau den Übeltäter zu identifizieren.

Laden Sie sich das Werkzeug ShellExView v1.17 – Shell Extensions Manager aus dem Internet und lesen Sie sich den folgenden Artikel durch. Anschließend versuchen Sie mit den angegebenen Methoden den fehlerhaften Kontextmenühandler herauszufinden. Dessen Name gibt i. d. R. einen Hinweis auf die Anwendung, die Sie vom System verbannen sollten.

Ansatz 2: Mit Säbel oder Schlachtermesser

Der zweite Ansatz ist für alle, die sich nicht mit den Feinheiten und Innereien der Windows-Shell auseinander setzen möchten.

1. Rufen Sie über das Startmenü die Systemsteuerung auf und klicken Sie in der Kategorie Programme auf den Eintrag Programme deinstallieren.
2. Bestätigen Sie die Sicherheitsabfrage der Benutzerkontensteuerung (ggf. mit Eingabe eines Administratorenkonten-Kennworts).
3. Werfen Sie schrittweise alle Anwendungen, die von obskuren Herstellern stammen, aus dem System.

Die Methode ist zwar etwas zeitintensiv. Aber wenn Sie zwischen jeder Desinstallation testen, wird sich der Übeltäter identifizieren lassen.

Auf diese Art ist z.B schon mal eine Version von Steganos Safe aufgefallen (ältere Versionen waren nur für Win XP ausgelegt). Falls Sie also eine Anwendung als fehlerhaft im Hinblick auf die Zusammenarbeit mit der Windows-Shell identifiziert haben, sollten Sie auf den Herstellerseiten nachsehen, ob es nicht einen Patch gibt. Gibt es keine Korrektur, wäre ein Hinweis an den Hersteller nicht schlecht – vielleicht kann der ja das Problem beheben und eine korrekt arbeitende Version bereitstellen.

Verschobene Benutzerordner als Ursache?

Falls unkompatible Shell-Erweiterungen als Ursache für nicht mehr funktionierende Links (z. B. in zuletzt verwendeten Programmen) ausgeschlossen werden können, gibt es noch einen anderen Problemkandiaten: Verschobene Benutzerordner unter Windows Vista. Wird das Benutzerprofil des Kontos im Zweig C:\Users\ vom Administrator (z. B. über einen Registrierungseingriff) auf eine andere Partition verschoben, gehen häufig die Berechtigungen zum Zugriff verloren. Neben Problemen mit dem Internet Explorer (z. B. in der Favoritenverwaltung oder beim Drucken) kann auch das Startmenü betroffen sein. Testen lässt sich dies, indem ein neues Benutzerkonto angelegt wird. Tritt der Fehler dort nicht auf, liegt das Problem an den Einstellungen des alten Benutzerkontos bzw. des Profils.

Ein Administrator kann dann versuchen, dem Profilordner und dessen Unterordnern die Zugriffsberechtigungen auf NTFS-Ebene (Kontextmenübefehl "Eigenschaften", Registerkarte "Sicherheit") für den betreffenden Benutzer zuzuweisen.

Nachtrag: Medienordner verursachen Explorerabsturz

Eine gänzlich andere Ursache steckt hinter dem Phänomen, dass der Windows Explorer beim Zugriff auf einen Medienordner (Bilder, Musik oder Videos) abstürzt. Der Effekt tritt auf, wenn die Miniaturansichten eingeschaltet sind. Im besten Fall bekommt der Anwender nur den Dialog COM Surrogate funktioniert nicht mehr zu sehen, im schlimmsten Fall stürzt der Windows Explorer ständig ab und die Shell startet neu.

1. Sie können dann als erstes den Ordner des Benutzerprofils über das Startmenü öffnen und dessen Darstellung auf Details umstellen.
2. Dann wählen Sie im Menü der Schaltfläche Organisieren den Befehl Ordner- und Suchoptionen.
3. Wählen und dann auf der Registerkarte Ansicht die Schaltfläche Für Ordner übernehmen.

Mit dem Schließen der Registerkarte über die OK-Schaltfläche sollten alle Unterordner auf den Modus Details zurückgesetzt werden. Dies verhindert, dass der Handler zur Anzeige der Miniaturansichten aufgerufen wird. Der Explorerabsturz sollte unterbleiben.

Die Ursache für die Abstürze oder den COM-Surrogate-Fehler ist kein Bug in Vista sondern liegt an den "netten" Codec-Packs, die sich die Anwender unter Vista installieren, um z. B. DivX-Videos sehen zu können. Insbesondere ältere Fassungen des XviD-Codec-Pack installieren DirectShow-Filter, die unter Vista (Stand August 2007) den Windows Explorer zum Absturz bringen. Erst Xvid-Version 1.1.3 (vom 12.04.2008) habe ich unter Windows Vista stabil zum Laufen bekommen. Beim DivX-Codec (Version 6.8.2) gab es erneute Kollateralschäden (der Explorer stürzte zwar nicht ab, aber ich konnte keine VCDs mehr abspielen). Deinstallieren Sie alle diese ominösen Codec-Packs und DirectShow-Filterpakete (die übrigens auch für viele Abstürze im Windows Movie Maker verantwortlich sind).

Tipp: Wer unbedingt DivX-Filme oder Mov-Clips sehen möchte, sollte einen Blick auf den VLC Media Player werfen. Ich habe da in dieser Richtung in den letzten Tagen ausgiebig im Rahmen eines neuen Multimedia-Buchprojekts getestet. Der Player funktioniert in Vista und kann viele Dateiformate durch interne DirectShow-Filter direkt unterstützen. Wer unbedingt meint, ein Codec-Pack zu brauchen, kann einen Blick in das Vista Codec-Pack werden. Ich hatte zwar in der Beta-Fassung noch ein paar kleinere Probleme, aber zumindest keine Abstürze.

Nachtrag: Zwischenzeitlich hat sich noch eine weitere Baustelle für "nicht mehr funktionierende" Desktop-Verknüpfungssymbole aufgetan: Leute, die im Internet kursierende Tipps zum Abschalten der Verknüpfungspfeile befolgen, stellen fest, dass Desktop-Verknüpfungen nicht mehr zuverlässig funktionieren.5% der Beiträge sich mit Nachbesserungen oder HowTos befassen, die Funktionen eines in der Distro verbockten Linux zum Arbeiten bewegen sollen.

These: Es steht jedem frei, mit Windows Vista zu arbeiten (und dann auch dafür zu zahlen) oder aber zu einer Linux-Distribution zu greifen (wobei die Profi-Distros kostenpflichtig sind). Man sollte sich aber im Klaren sein, dass Linux eine Menge Einarbeitungszeit und Kenntnisse erfordert. Nach meiner Beobachtung ist Windows (als XP oder Vista) für die Breite der Masse nach wie vor die stressfreiere Lösung.