Ein Anwender hatte mir berichtet, dass SpeedCommander bei ihm nach einer gewissen Inaktivität im Hintergrund bei Aktivierung abstürzt. Der Absturzbericht zeigt dabei folgenden Callstack an:

user32.dll!UserCallWinProcCheckWow()
user32.dll!DispatchMessageWorker()
MxMfc90ud.dll!AfxInternalPumpMessage()
MxMfc90ud.dll!CWinThread::PumpMessage()
MxMfc90ud.dll!CWinThread::Run()

Diesem kann man entnehmen, dass der Absturz während der Verarbeitung einer Nachricht in der Funktion UserCallWinProcCheckWow der user32.dll auftrat. Die Ursache ist aber leider nicht ersichtlich. Kurze Zeit später schrieb mir der Anwender, dass er mit Hilfe von ShellExView den Kontextmenüeintrag von StExBar deaktiviert hat. Anschließend stürzte SpeedCommander nicht mehr ab. Nach der Installation von StExBar konnte ich das Problem nachstellen.

StExBar ist eine Erweiterung für den Explorer und stellt ein Kontextmenü sowie eine Symbolleiste zur Verfügung, in denen häufig verwendete Befehle abgelegt werden können. Der Vertrieb erfolgt unter der GPL, der Quellcode steht somit zur Verfügung. Ich habe mir also den Quellcode heruntergeladen und versucht, mit dem Debugger dem Problem auf den Grund zu gehen.

Meine Vermutung war, dass es etwas mit dem vorzeitigen Entladen der Dll zu tun hat. Dazu muss man wissen, dass eine MFC-Anwendung von Zeit zu Zeit nicht mehr benötigte Handles und temporäre Objekte freigibt. Dies geschieht, wenn die Anwendung Däumchen dreht und auf eine Eingabe des Anwenders wartet. Zu den Aufräumarbeiten gehört es auch, dass in bestimmten Zeitabständen durch Aufruf der Windows-Funktion CoFreeUnusedLibraries nicht mehr benötigte COM-Dlls entladen werden. Zu diesen COM-Dlls zählen auch die verschiedensten Shellerweiterungen.

Beim Entladen einer COM-Dll ruft Windows die von der Dll exportierte Funktion DllCanUnloadNow auf. Durch Rückgabe von S_OK stimmt die Dll einer Entladung zu, mit S_FALSE wird das Entladen verhindert. Nach Änderung des Rückgabewertes auf S_FALSE wurde StExBar nicht mehr entladen und der Absturz in SpeedCommander blieb aus.

Nun galt es, den Grund des Entladeproblems zu finden. StExBar erstellt bei der Initialisierung ein Fenster, in dem eine Symbolleiste und ein Eingabefeld platziert werden. Die Anzeige des Fensters erfolgt im Explorer durch den Aufruf der Schnittstelle IDockingWindow::ShowDW, mit IDockingWindow::CloseDW wird das Fenster wieder entfernt.

SpeedCommander ist allerdings nur an der Anzeige des Kontextmenüs interessiert und nicht an der zusätzlichen Symbolleiste. Das führt dazu, dass das Fenster während der Initialisierung erzeugt, bei der Freigabe des Kontextmenüs aber nicht geschlossen wird. Auch beim Entladen der Dll bleibt das Fenster weiter bestehen, was natürlich nicht beabsichtigt ist.

Bei der Aktivierung von SpeedCommander informiert das Hauptfenster alle untergeordneten Fenster. Dazu gehört auch das unsichtbare Fenster der zwischenzeitlich entladenen StExBar-Dll. Dummerweise ist der Speicherbereich, den die Fensterfunktion belegt hat, durch das Entladen ungültig geworden. UserCallWinProcCheckWow greift so auf einen undefinierten Bereich zu und es kommt zum Absturz. Den vorgeschlagenen Fix hat Stefan schon eingecheckt, vielen Dank dafür an dieser Stelle! Mit der nächsten Version von StExBar sollte das Problem dann nicht mehr auftreten.

Dieses Beispiel zeigt wieder einmal, dass die durch das Entladen von Shellerweiterungen verursachten Abstürze äußerst vielgestaltig und schwer zu ermitteln sind. Deshalb habe ich mich dazu entschlossen, die automatische Entladefunktion in der MFC durch eine Option in der SpeedCommander.ini abschaltbar zu machen. Nun bin ich am Überlegen, ob die Entladefunktion standardmäßig aktiviert (wie bisher) oder deaktiviert werden sollte. Für die Aktivierung spricht, dass nicht mehr benötigte COM-Dlls von Zeit zu Zeit entfernt werden und der Arbeitsspeicher etwas entlastet wird. Die Deaktivierung hat den Vorteil, dass möglicherweise der eine oder andere unerklärliche Absturz der Vergangenheit angehören könnte. Die Tendenz geht im Moment zur Deaktivierung, was meint ihr?

Vor knapp zwei Jahren hatte ich darüber berichtet, dass Carbonite Backup die Anzeige von Overlaysymbolen nur für bestimmte Anwendungen erlaubt. Auf meine Bitte, in die Liste der erlaubten Anwendungen aufgenommen zu werden, habe ich damals keine Antwort bekommen.

Ich weiß nicht, ob dieses Verhalten eine Spezialität von Onlinebackup-Lösungen ist. Mozy macht es jedenfalls genauso, Overlaysymbole werden nur in bestimmten Anwendungen angezeigt:

• explorer.exe
• dopus.exe
• conf.exe
• pifsdr.exe
• piimporter.exe
• verclsid.exe
• regsvr32.exe

Nenne ich SpeedCommander.exe zum Beispiel auf Explorer.exe oder dopus.exe um, dann zeigt auch SpeedCommander die Overlaysymbole. Das gleiche gilt auch für die Anzeige des Ordners MozyHome Remote Backup unterhalb von Computer. Die Auflistung dieses Ordners ist nur möglich, wenn die Anwendung einem der oben genannten Prozessnamen entspricht.

Die Intention einer Whitelist liegt wohl darin, möglichen Problemen bei der Zusammenarbeit mit anderen Anwendungen aus dem Weg zu gehen. Leider weiß der normale Anwender davon nichts und schiebt die Schuld immer auf die andere Anwendung, in diesem Fall auf SpeedCommander. Der Explorer zeigt die Symbole ja schließlich auch an.

Wie schon beim Carbonite-Fall habe ich auch an Mozy eine Anfrage geschickt. Ich bin gespannt auf die Antwort.

Es ist geschafft, die finale Version von SpeedCommander 13 kann nun heruntergeladen werden. An dieser Stelle noch einmal vielen Dank an die internen und externen Betatester für die tolle Unterstützung!

SpeedCommander 13 war für mich das erste Projekt, das von Anfang an mit Visual Studio 2008 und Team Foundation Server (TFS) entwickelt wurde. Vor einem knappen Jahr habe ich von der damaligen Version 12.30 einen Entwicklungsstrang abgespalten und dann zweigleisig entwickelt. Im Hauptstrang ging es weiter bis zur Version 12.50, während im Entwicklungsstrang die Version 13 entstand. Änderungen im Hauptstrang wurden in regelmäßigen Abständen in den SC13-Strang übertragen. Nach dem Erscheinen der Version 12.50 wurde der SC13-Strang dann wieder in den Hauptstrang zurückgeführt.

Von diesen Erfahrungen wird auch der für 2011 geplante SC14 profitieren. Der Entwicklungsstrang wird schon jetzt für Arbeiten am SC14 verwendet. Bisher war es immer so, dass die Entwicklung der nächsten Hauptversion frühestens nach einem Jahr begann. Im Hauptstrang geht es wie gewohnt mit der Version 13 weiter, Updates sind wieder im Abstand von 100 Tagen geplant.

In den nächsten Tagen werde ich hoffentlich einmal etwas Zeit finden, einen Blick auf die Beta 2 von Visual Studio 2010 zu werfen. Ein möglicher Umstieg hängt auch davon ab, ob ich EasyTabs ohne großen Aufwand anpassen kann. Unter der Haube hat sich in Visual Studio 2010 ja einiges geändert.

Gestern habe ich die finale Version von SpeedCommander 13 fertiggestellt. Gegenüber der RC-Version wurden noch sechs kleine Fehler behoben, die alle im Forum berichtet wurden. Die Veröffentlichung der finalen Version ist für den 27. Oktober 2009 geplant.

Jetzt muss ich mich nur noch um das Handbuch und um die Website kümmern.

Ab sofort könnt ihr euch den Veröffentlichungskandidaten herunterladen. Neue Funktionen und behobene Fehler werden wie gewohnt im Anwenderforum aufgelistet.

Die finale Version wird wie geplant Ende Oktober erscheinen.

Ab sofort könnt ihr euch die zweite Beta herunterladen. Neue Funktionen und behobene Fehler finden sich wie gewohnt im Anwenderforum.