Eine steigende Anzahl von Anwendern meldete Probleme beim Öffnen von Office Dateien beim HelpDesk. Office Dateien aus dem Explorer oder Outlook zu öffnen dauerte ca. eine Minute.
Zunächst dachte ich, es sei ein weiterer Fall, in dem Outlook nach fehlenden Vorlagendateien sucht. Eine Analyse mit Filemon und einem Netzwerk Sniffer zeigte aber, daß das nicht der Fall war.
CPU Last und I/O waren vernachlässigbar gering aber Word / Excel hingen.
Eine Datei aus einer laufenden Office Anwendung lies sich problemlos öffnen.
Eine Googlesuche zeigte, daß das Problem recht häufig auftritt und daß der üblicherweise vorgeschlagene Workaround die Abschaltung der DDE Kommunikation zum Aufruf war.
Den Haken bei „DDE verwenden“ herauszunehmen und stattdessen in den Aufruf der Anwendung ein „%1“ einzusetzen behob das Problem. Allerdings hat das den Nebeneffekt, daß sich neuen Dateien in Excel immer in einem neuen Fenster öffnen. Außerdem ist das keine saubere Lösung.
Ich mußte der Sache auf den Grund gehen.
Da sehr lange Hängen der Anwendung gab mir genug Zeit um zu sehen bei welchem hwndTo / hwndFrom Aufruf die Anwendung hing. Aber das half noch nicht herauszufinden was an dem Problem schuld war. Das ging mit x-spy:
Während die Anwendung hing, aktualisierte ich die Fenster- und Prozessliste in x-spy und ich notierte mir das Window handle in ddespy.
Die Suche nach diesem Windows Handle in x-Spy zeigte, daß die Kommunikation in einen time-out lief und wer der schuldige Prozess war:
naviclient.exe
Beenden des naviclient und naviagent Prozesses löste sofort das Probem auf dem Client. Dies bestätigte sich beim Test an einigen anderen PCs. Natürlich war das Problem beim nächsten Neustart wieder da.
Unser Helpdesk deinstallierte auf allen PCs das Programm per SMS und stoppte auf den Maschinen auf denen die Deinstallation fehlgeschlagen war die zugehörigen Dienste.
Problem gelöst.