Kontextmenüs: Explorer.exe stürzt ab (eingeschränkter Benutzer)

[kampmann]

Hallo liebe Thinkpadgemeinde,

auf meinem X220t (Win7 SP1, x86, frische Installation über WDH-Datenträger mit Updatemarathon) gibt es Probleme beim Shell-Handling einiger Kontextmenüs, nachdem ich als eingeschränkter Benutzer über die UAC Dateioperationen (gewöhnliches Verschieben in Ordnern, auf die der Benutzer keinen Zugriff hatte) als Administrator durchgeführt habe.

Seitdem hängt sich explorer.exe konsequent in folgenden Fällen auf:

• Beim Rechtsklick auf Taskleistenelemente können sämtliche Operationen im Bereich "Aufgaben" nicht ausgeführt werden. Explorer.exe hängt sich auf, Aktion wird nicht ausgeführt. Erscheinen Aufgaben im Startmenü, kann ich die mit Linksklick jedoch ausführen.
• Bei Rechtsklicks auf Elemente vom Typ "Datei" oder "Dateiverknüpfung" (also im Explorer, Startmenü oder anderen Explorerinstanzen) hängt sich der Explorer ebenfalls auf. Dadurch sind Dateioperationen im Explorer nur noch über Tastatur möglich und ich kann das Benutzerprofil eigentlich in die Tonne kloppen

Das Ganze passiert mir jetzt zum zweiten Mal. Beim ersten Mal habe ich das Benutzerprofil sauber entfernt, weil ich dachte, dass sowas nach einer Neuinstallation ja schonmal passieren kann (Ordnerebene über Systemsteuerung-> Erweiterte Systemeinstellungen->Erweitert->Benutzerprofile bzw. Systemebene über die Computerverwaltung). Vermutlich scheint es sich hier um ein Problem der ACL zu handeln (vgl. hier für vermutl. ähnliches Problem)- dementsprechend dürftig sind die Aussagen der Ereignisanzeige (Application Error von explorer.exe mit Verweis auf Kernelbase.dll).

Dass Kontextmenühandler am Absturz von Windows Explorer beiteiligt sein könnten, halte ich für unwahrscheinlich, da sämtliche Erweiterungen funktionieren, wenn man ein neues Benutzerprofil anlegt.

Kennt jemand von Euch dieses Verhalten bzw. einen Kniff, um es in den Griff zu bekommen? Ist es generell nicht ratsam, in einem angemeldeten Profil vom Typ "Benutzer" als Admin zu werkeln?

Über jegliche Kommentare würde ich mich sehr freuen- das Problem erscheint mir recht knifflig.

 

[iYassin]

Interessantes Problem - davon habe ich noch nie gehört. Hört sich fast nach einem recht heftigen Bug an.

Was ich aber nicht verstehe, ist das Arbeiten als eingeschränkter Benutzer unter einem modernen Windows - okay, ich habe auch damals unter XP stets einen Administratoraccount verwendet(und hatte noch nie einen Virus o.ä.), aber seit Vista ist man mit aktivierter UAC (bei sinnvoll gewählter Sicherheitsstufe) auch mit einem Admin-Account standardmäßig als Standardbenutzer unterwegs, das ist ja der Sinn der UAC. Nur bestimmte Aktionen musst du dann ja explizit bestätigen - und ob du das jetzt mit der Freigabe durch einen anderen Admin-Account oder den Klick auf "Ja" tust, ist sicherheitstechnisch egal, da es sich dabei um den gleichen Vorgang handelt.

 

[kampmann]

Interessantes Problem - davon habe ich noch nie gehört. Hört sich fast nach einem recht heftigen Bug an.

Erstmal danke für die schnelle und gute Antwort :thumbsup:
Ich frage mich allerdings, warum der Explorer unter Win7 derart anfälig für Verwundungen geworden ist. So schlimm war's zumindest damit unter XP ja i.d.R. nicht.

Was ich aber nicht verstehe, ist das Arbeiten als eingeschränkter Benutzer unter einem modernen Windows. [...] Nur bestimmte Aktionen musst du dann ja explizit bestätigen - und ob du das jetzt mit der Freigabe durch einen anderen Admin-Account oder den Klick auf "Ja" tust, ist sicherheitstechnisch egal [...].

Sehe ich nicht ganz so.
Deine Mauer ist erheblich dicker, wenn Du für außenstehende sowohl auf NTFS-Ebene als auch auf UAC-Ebene Einschränkungen hast, darüber hinaus gibt es ja auch Berechtigungshierarchien für den Zugriff auf Scripting, Registrierung und Anderes. Diese Vorgänge sind zwar nach meinem Wissen samt und sonders durch UAC geschützt. Wenn ein Angreifer es aber (z.B. über WMI) schafft, UAC für Deinen Admin-Account auszuhöhlen bzw. für sich transparent zu machen, dann steht ihm Dein System uneingeschränkt zur Verfügung.

Klar, generell ist es natürlich die Abwägung Sicherheit vs. Bedienbarkeit- da sollte ich mir das bei der verbesserten UAC vielleicht nochmal überlegen.

Kennt sonst noch jemand das Verhalten oder hätte evtl. Vorschläge, Links? Sonst muss ich mich vielleicht dochmal an der Geschichte mit den Watson-Dumps versuchen- aber das ist die Suche nach der Nadel im Heuhaufen.

Irgendwo müsste ja was (außer Kontextmenühandler) zu finden sein, was beim Zugriff auf "Datei" Probleme für meinen konkreten Benutzer macht

 

[kampmann]

Kennt denn sonst noch irgendjemand das Problem? Gibt es generell Probleme, wenn man in einem Benutzerprofil Dateiverschiebungen als Admin durchführt?

Ich hänge mal eine Problemsignatur mit an- das Erzeugen von Memorydumps funktioniert bei mir leider noch nicht so wirklich bzw. die Dumperzeugung legt mir fast mein System lahm.

Problemsignatur
Problemereignisame: APPCRASH
Anwendungsname: Explorer.EXE
Anwendungsversion: 6.1.7601.17567
Anwendungszeitstempel: 4d6727a7
Fehlermodulname: KERNELBASE.dll
Fehlermodulversion: 6.1.7601.18015
Fehlermodulzeitstempel: 50b83b16
Ausnahmecode: 0eedfade
Ausnahmeoffset: 0000812f
Betriebsystemversion: 6.1.7601.2.1.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: 370f
Zusatzinformation 2: 370f015df6ddcbe7aa2429f99ed20a88
Zusatzinformation 3: 5597
Zusatzinformation 4: 5597d11295a7e802087734328146374c

 

[gerli09]

Ich würde zuerst mal eine Systemdateireparatur versuchen:
​
cmd mit Adminrechten starten und "sfc /scannow"

 

[toby]

Das Problem ist ganz einfach zu erklären, aber nicht ganz einfach zu verstehen: Normalerweise verschiebt ein Benutzer seine eigenen Dateien mit dem Explorer, die Benutzerrechte bleiben erhalten und am "Rechtsstatus" der Datei verändert sich gar nichts. Das gleiche gilt natürlich auch als Admin.
Wenn aber ein Benutzer Dateien verschiebt, für die er Adminrechte braucht, ist irgend etwas faul, denn es kann sich unmöglich um normale Benutzerdateien handeln, sondern nur um Dateien, für die man Adminrechte braucht, also installierte Programme bzw. dessen Dateien! Wie soll WINDOWS das denn handeln? Soll er dem Programm jetzt Benutzerechte oder Adminrechte geben, obwohl sie vielleicht sogar mal Systemstatus hatten?
Wenn Du also tatsächlich Programme oder Dateien hast, die Du im Startmenü ausführen kannst, aber im Kontextmenü nicht, dann hat die zu startende Datei im Kontextmenü andere Rechte als die, die der Ausführende im Startmenü hat. Was also verschiebst Du da eigentlich? Und wenn Du schon Systemdateien verschieben musst, warum loggst Du Dich nicht wenigstens als Admin ein, um der UAC-Abfrage zu entgehen?

P.S. Im Übrigen lassen sich Kontextmenüs reparieren, in dem man mit der rechten Maustaste auf die Datei klickt und ein neues Standardprogramm auswählt.

 

[der_ingo]

Wenn der Benutzer Daten verschieben will, für die er Adminrechte zum Schreiben/Löschen braucht, kommt eine UAC Rückfrage, so er denn grundsätzlich Adminrechte auf dem PC hat. Damit kann er dann problemlos diese Dateien verschieben. Die Dateien behalten auch dann beim Verschieben auf dem Laufwerk ihre Berechtigungen. Braucht er zum Lesen schon Adminrechte, sieht er die Datei eh nicht und das Problem tritt nicht auf.
In keinem der Fälle sollte aber der Explorer crashen.

 

[toby]

In keinem der Fälle sollte aber der Explorer crashen.

Tut er aber, und deshalb löst es nicht sein Problem. Das einzig Richtige, was man ihm raten kann, ist Dateioperationen nicht als eingeschränkter User auszuführen. Dann hat er auch keine Verknüpfungen im Kontextmenü, die Adminrechte brauchen und die der Explorer so nicht ausführen kann.

 

[kampmann]

@gerli09: Das hatte ich schon mit der explorer.exe und kernel32.dll ausprobiert, aber dann auch nochmal komplett untersucht. Ergebnis: Systemdateien sind komplett integer.

@toby: In dem konkreten Fall hattee ich die AcroRead-Plugins für PDF (nppdf32.dll und ihren Anhang) aus den verschiedenen Plugin-Ordnern von Firefox in benachbarte temporäre Ordner verschoben, weil mich diese Software mit ihrer Hartnäckigkeit geärgert hat. Einfaches Deaktivieren des AcroRead-Plugins funktioniert ja nicht, man muss die Plugins über Firefox/ aboutlugins aufspüren. Ich nutze derzeit zwar Acrobat, aber im Wesentlichen für Digitalisieraufgaben mit OCR-Anwendungen oder Formblätter und wollte zum Lesen ein anderes PlugIn benutzen. Unter XP war ich es gewohnt, als angemeldeter Benutzer den Explorer kurz als Admin auszuführen und dann z.B. Dateien verschieben zu können- da waren solche Aktionen nie ein Problem (UAC gab's da zugegeben nur rudimentärster Form). Sollte dies unter Win7 nicht mehr möglich sein..?

@der_ingo: Eben, das sollte eigentlich kein Problem mit UAC darstellen. Also tut es das in der alltäglichen Admin-Erfahrung auch nicht? Dann sollte ich mir evtl. doch nochmal überlegen, ein Backup vom Zustand vor der Softwareaktualisierung aufzuspielen- danach hieße es aber auch Software neu einrichten. Im Rahmen der Updates gab es nach Auskunft des Wartungscenters Probleme mit der consent.exe, die den UAC-Dialog anstößt, obwohl ich da mit einem Admin-Konto gearbeitet habe. Hat die consent.exe zufällig eine irgendwo sichtbare Shell-Extension für das Kontextmenü, die man evtl. reparieren könnte?

 

[toby]

@toby: In dem konkreten Fall hattee ich die AcroRead-Plugins für PDF (nppdf32.dll und ihren Anhang) aus den verschiedenen Plugin-Ordnern von Firefox in benachbarte temporäre Ordner verschoben, weil mich diese Software mit ihrer Hartnäckigkeit geärgert hat. Einfaches Deaktivieren des AcroRead-Plugins funktioniert ja nicht, man muss die Plugins über Firefox/ aboutlugins aufspüren. Ich nutze derzeit zwar Acrobat, aber im Wesentlichen für Digitalisieraufgaben mit OCR-Anwendungen oder Formblätter und wollte zum Lesen ein anderes PlugIn benutzen. ...

Sorry, wenn ich Dich als "alter Hase" jetzt etwas nerve, aber da liegt das Problem:

1. Man verschiebt niemals (!) system.dll's, man benennt sie höchstens in system.bak um und wartet, was passiert.
2. Man arbeitet im System niemals (!) als eingeschränkter Benutzer, sondern nur als reiner Admin, weil sonst das System durcheinandergerät.
3. Wenn eine Software nervt, dann deinstalliert man sie und besorgt sich eine bessere. Man schraubt aber nicht an der nervenden Software herum, wenn man nicht wirklich Ahnung hat oder sie selbst programmiert hat...
4. Firefox ist keine Referenzsoftware für WINDOWS, sondern nur ein fremdes Anwendungsprogramm. Das MS-Betriebssystem kann also nicht wissen, was die Firefox-Programmierer geplant haben, wenn Du einfach mal system.dll's verschiebst.
5. Wenn Du Acrobat benutzt, ist Acrobat-Reader zum Lesen Dein Referenz-Programm, und nicht irgendwelche Plug-Ins diverser Dritthersteller.
6. Damit ist dann auch nicht Firefox, sondern der Internet Explorer Referenz für die Anzeige von PDFs. Sollten diese auch unter Firefox angezeigt werden, um so besser, aber ist nicht zwingend notwendig, solange es eine vom Betriebssystem vorgegebene Referenz gibt.

Du solltest also mal Deine ganze Arbeitsweise überprüfen, und Dich auf WIN7, Acrobat, Acrobat Reader und IE beschränken. Denn irgendwer muss ja dann Deine digitalisierten Dokumente auch lesen können, und der Firefox ist bei allem Respekt kein systeminterner, ausgewiesener PDF-Reader, sondern ein Internet Browser, der von einem Drittanbieter stammt und Plug-Ins benutzt, die einem Viertanbieter stammen.

 

[Helios]

Ohne jetzt alles gelesen zu haben. Bei mir stürzte der Windows Explorer auch stets unter Windows 7 im abgesicherten Modus ab. Im normalen Modus kein Problem.

Nun habe ich seit zwei Wochen Windows 8 Pro installiert. Im abgesicherten Modus stürzt der Windows Explorer derart schnell ab, dass man nicht von einem wirklichen Öffnen sprechen kann. Und im normalen Modus wieder alles in Ordnung.

Da soll noch einer schlau daraus werden ?


LG Uwe

 

[kampmann]

Sorry, wenn ich Dich als "alter Hase" jetzt etwas nerve, aber da liegt das Problem:

1. Man verschiebt niemals (!) system.dll's, man benennt sie höchstens in system.bak um und wartet, was passiert.
2. Man arbeitet im System niemals (!) als eingeschränkter Benutzer, sondern nur als reiner Admin, weil sonst das System durcheinandergerät.

Okay, das kann ich gut nachvollziehen. Zu Zeiten von UAC ist es etwas offensichtlich anderes als zu Zeiten von XP, bei angemeldetem eingeschränkter Benutzer Administratoroperationen durchzuführen. Das DLL-Verschieben würde ich allerdings nicht grundsätzlich verteufeln, sofern man es im richtigen Konto vornimmt.

Sofern es sich tatsächlich um Systembibliotheken handelt, hat ein Verschieben natürlich unmittelbar fatale Auswirkungen. Im Falle von Browsererweiterungen bzw. der PlugIns für den Adobe Reader ist es allerdings in der Regel so, dass die Bibliotheken nicht fest registriert sind, sondern beim Laden des Programms eingelesen werden, da Erweiterungen sich ja auch ständig ändern. Somit sehe ich hier nicht so die großen Gefahren.

Dann wollte ich noch gern auf eine brauchbare Fehlersuchliste für Explorerabstürze hinweisen, die umfassend und sinnvoll von naheliegenden zu diffizileren Explorer-Fehlern alles Wesentliche abarbeitet. Mit dem passenden Registry-Schlüssel für Win7 sollte auch das Erstellen von Dumps für den Explorer-Prozess funktionieren, die man in WinDbg durch "File->Open CrashDump" mit dem Befehl "analyze -v" auslesen kann, wie hier beschrieben.

Denn--und wen wird's wundern--mein Problem lag doch in einer fehlerhaften Shellerweiterung, und zwar der zur Erstellung einer Simple Tap-Kachel. Ich hätte es nicht für möglich gehalten.

Ich danke allen Helfern für die Unterstützung beim Problemfinden, da mich letztlich u.A. die sfc-Kommandos auf die passende Forenseite gebracht haben!

PS: Ist das Thinkpad-Forum eigentlich nur bei mir so extrem langsam?

 

[toby]

PS: Ist das Thinkpad-Forum eigentlich nur bei mir so extrem langsam?

Das passiert nur, wenn man die thinkpad-forum.dll als Gast im System verschiebt...

 

[kampmann]

:thumbup: