Shell Extension läuft nicht unter Windows 7
-
Freitag, 11. November 2011 14:45
Hallo,
ich habe eine Shell Extension, die unter Windows XP einwandfrei läuft. Sie erzeugt hauptsächlich einen Shell Folder, und implementiert IShellFolder, IPersistFolder und IContextMenu. Die Anwendung ist in C++ geschrieben und läßt sich mit Visual Studio 6 compilieren.
Wenn ich die Shell Extension unter Windows 7 64 bit installiere (d.h. die entsprechenden Registry-Einträge mache), dann wird sie beim ersten Start des Windows Explorers richtig angezeigt, und zeigt im Shell Folder den richtigen Inhalt an. Bei weiteren Starts des Windows Explorers ist der Folder leer.
Möglich wäre, dass verclsid.exe die Extension als "böse" markiert, und bei nachfolgenden Starts nicht mehr lädt; aber warum hat es dann beim ersten Mal geklappt?
Ich habe Visual Studio 6 unter Windows 7 installiert. Sogar der Debugger funktioniert. Anschließend habe ich den Windows Explorer als "Executable for debug Sessions" angegeben, und Haltepunkte bei InitInstance und DllGetClassObject angegeben. Anschließend habe ich den Explorer mit dem Task Manager beendet, und aus dem Visual Studio heraus per Debugger gestartet. Das funktioniert auch, aber leider hält das Programm nicht bei meinen Haltepunkten. Meine Vermutung ist, dass verclsid.exe einigen Aufwand treibt, um genau das zu verhindern, d.h. um zu vermeiden, dass man ihm per Debugger "in die Karten schauen" kann.
Ich wäre für jede Hilfe dankbar.
Ach ja: für folgende Ratschläge wäre ich NICHT dankbar:
- Portieren der Anwendung auf Visual Studio 2010 (das ist Plan B; hier wäre ich an einer Lösung für Plan A interessiert)
- Korrektes Implementieren der Interfaces (außer jemand weiß GENAU, was sich gegenüber XP geändert hat)
Alle Antworten
-
Freitag, 11. November 2011 17:31
Aus meiner Sicht mußt Du Deine Shell Extension auch in 64 Bit compilieren, da Du diese ja unter Windows 7 64 verwenden möchtest. Ich denke nicht dass VC6 64 Bit Targets erzeugen kann. Es ist nicht meiner Meinung nicht möglich eine 32 Bit Shell Extension in einem 64 Bit Prozess laufen zu lassen.
Ich würde Dir raten, das ganze Teil auf VC2008/2010 zu portieren und dann als x64 Target zu compilieren. Du mußt evtl. ein paar Datentypen anpassen / ändern für die 64 Bit Targets. Es hat sich da von VC6.0 bis heute viel getan.
- Bearbeitet BordonMicrosoft Community Contributor Freitag, 11. November 2011 17:34
-
Freitag, 11. November 2011 19:09
Aber es gibt doch auch unter Win7 x64 einen 32-Bit-Explorer. Der sollte im Prinzip in der Lage sein, meine Extension zu laden. Ich habe ihn explizit im Debugger angegeben, aber geladen wurde trotzdem (laut Task Manager) die 64-Bit-Version. Auch etwas, das ich nicht verstehe...
Und nochmal: beim ersten Mal wurde die Extension richtig ausgeführt; erst danach wurde sie nicht mehr geladen. Ich wüßte gern, woran das liegt, bzw. wie ich das feststellen kann. Im Internet heißt es, das ich meine Extension debuggen muß, während sie von verclsid.exe geprüft wird. Leider hält der Debugger nicht, vermutlich, weil die Extension bereits vom Explorer abgeklemmt wurde. Kann ich das irgendwie zurücksetzen?
-
Samstag, 12. November 2011 16:08
-
Samstag, 12. November 2011 16:13
Aber es gibt doch auch unter Win7 x64 einen 32-Bit-Explorer.
Ja.
Der sollte im Prinzip in der Lage sein, meine Extension zu laden.
Ja.
Ich habe ihn explizit im Debugger angegeben, aber geladen wurde trotzdem (laut Task Manager) die 64-Bit-Version. Auch etwas, das ich nicht verstehe...
Ja... das ist immer dann der Fall, wenn Du nicht gesagt hast, dass für explizit ein neuer Prozess gestartet werden soll (was Default-Einstellung ist)
Und nochmal: beim ersten Mal wurde die Extension richtig ausgeführt;
Vermutlich nimmt er die Werte nur aus der Registry ohne die DLL zu laden...
erst danach wurde sie nicht mehr geladen.
Weil er dann gemerkt hat, dass die DLL nicht ladbar ist..
Ich wüßte gern, woran das liegt, bzw. wie ich das feststellen kann.
Woran es liegt is ja wohl eindeutig, oder?
Im Internet heißt es, das ich meine Extension debuggen muß, während sie von verclsid.exe geprüft wird.
Soweit kommst Du doch gar nicht, wenn Du den Beitrag von Bordon und mir gelesen hättest...
Leider hält der Debugger nicht, vermutlich, weil die Extension bereits
vom Explorer abgeklemmt wurde. Kann ich das irgendwie zurücksetzen?
Was nicht geladen werden kann, kann auch nicht abgeklemmt werden...
Jochen Kalmbach (MVP VC++) -
Samstag, 12. November 2011 18:16
Meine Extension liest Datensätze aus dem Sql Server und zeigt sie als Folder an. Diese Folder werden nach der Installation beim ersten Start des Explorers richtig angezeigt (also letztendlich Daten aus der Datenbank). Dann wird ja wohl die Extension geladen und richtig ausgeführt. Bei nachfolgenden Starts wird leider nur noch das Icon dargestellt, das ich in der Registry angegeben habe, aber die Extension wird nicht mehr geladen.
Im Debugger habe explizit den Pfad des 32-Bit-Explorers angegeben (irgendwas kryptisches, leider sitze ich im Moment nicht am passenden Rechner). Der Debugger startet dann einen Explorer. Im Taskmanager kann man als Spalte den Pfad des Prozesses anzeigen lassen, und das ist der 64 bit-Explorer.
Übrigens: danke für den Ratschlag, das Ganze auf 64 bit umzustellen. Ich habe den Code geerbt, die Autoren sind nicht mehr verfügbar, das ganze ist ziemlich komplex, und ich suche nach einem möglichst einfachen Weg.
Nochmal: gibt es einen Weg, die Extension zu debuggen, bzw. den Explorer zumindest zu einem Versuch zu bewegen, die Extension zu laden, so dass ich im Debugger sehen kann, was schiefläuft?
-
Samstag, 12. November 2011 18:22
Der einfachste Weg ist ein 32-Bit Win7 zu nehmen und kein 64-Bit...
Temporär auf 32-Bit Explorer umschalten ist z.B. hier beschrieben:
http://extended64.com/forums/t/1018.aspxoder auch länger hier:
http://extended64.com/blogs/bhpaddock/archive/2005/05/22/539.aspx
Jochen Kalmbach (MVP VC++) -
Samstag, 12. November 2011 18:40Danke, das werde ich dann Montag probieren.
-
Montag, 14. November 2011 08:57
Der Beitrag
http://extended64.com/blogs/bhpaddock/archive/2005/05/22/539.aspx
bezieht sich auf Windows XP 64bit. Spätestens seit Windows 7 enthält das 64bit-Betriebssystem keinen 32bit-Explorer mehr. Die Befehlszeile
C:\Windows\SysWow64\explorer.exe /separate
startet nur ein 32bit-Dummy, das einen 64bit-Explorer startet. Siehe
http://social.technet.microsoft.com/Forums/en-US/w7itproui/thread/e237260d-ca42-4fbc-a657-89796d884715/
Also, ich sehe jetzt ein, dass ich meine Extension auf 64 Bit portieren muss. Das Debuggen wird dann vermutlich auch klappen.
- Als Antwort markiert Peter Schmeichel Montag, 14. November 2011 08:57
- Tag als Antwort aufgehoben Peter Schmeichel Freitag, 20. April 2012 10:52
-
Montag, 14. November 2011 11:01
Also, ich sehe jetzt ein, dass ich meine Extension auf 64 Bit portieren muss. Das Debuggen wird dann vermutlich auch klappen.
Du wolltest es mir und Jochen ja nicht glauben.... :-) -
Freitag, 20. April 2012 10:03
IContextMenu::GetCommandString war schuld:
Alter Aufruf:
STDMETHODIMP GetCommandString(UINT, UINT, UINT*, LPSTR, UINT);
Neuer Aufruf:
STDMETHODIMP GetCommandString(UINT_PTR, UINT, UINT*, LPSTR, UINT);
Kaum macht mans richtig, schon funktionierts.
Noch schöner wäre es, wenn man das "einfach so" aus MSDN erfahren würde, z.B. mit der Überschrift "Breaking Changes bei Shell Folders seit Windows Vista".
- Als Antwort markiert Peter Schmeichel Freitag, 20. April 2012 10:52
- Bearbeitet Peter Schmeichel Freitag, 20. April 2012 10:54

