Hallo zusammen,
wir beobachten auf unseren Windows-Terminalserver wiederholt ein auffälliges Verhalten im Zusammenhang mit Microsoft Word und DATEV-Arbeitsplatz.
Windows Terminalserver / Remotedesktopserver
Microsoft Office 365 Apps for Enterprise (Word Version 16.0.20026.20112)
DATEV Arbeitsplatz
Outlook läuft parallel in der Benutzersitzung
Bei einem Benutzer entstanden im Laufe des Arbeitstages mehrere Word-Prozesse, obwohl kein sichtbares Word-Fenster mehr geöffnet war.
Die Prozesse wurden mit folgenden Parametern gestartet:
WINWORD.EXE /Automation -Embedding WINWORD.EXE -Embedding
Einige Beispiele:
12:44:23 WINWORD.EXE -Embedding 13:35:42 WINWORD.EXE /Automation -Embedding 13:35:45 WINWORD.EXE /Automation -Embedding 13:41:38 WINWORD.EXE /Automation -Embedding 13:41:42 WINWORD.EXE /Automation -Embedding 13:43:02 WINWORD.EXE /Automation -Embedding 13:43:05 WINWORD.EXE /Automation -Embedding 14:31:53 WINWORD.EXE /Automation -Embedding
Eine Word-Instanz lief über mehrere Stunden im Hintergrund und verursachte erhebliche CPU-Last:
PID: 11108 Startzeit: 12:44:23 CPU-Zeit: > 4000 Sekunden Kein sichtbares Word-Fenster Session des Benutzers aktiv
Weitere Word-Instanzen sammelten ebenfalls CPU-Zeit, wenn auch deutlich weniger.
Alle Word-Prozesse wurden per COM-Automatisierung gestartet (/Automation -Embedding).
Als Parent-Prozess wird lediglich svchost.exe -k DcomLaunch -p angezeigt.
Die Prozesse liefen im Benutzerkontext einer aktiven DATEV-Arbeitsplatz-Sitzung.
Parallel waren DATEV Arbeitsplatz, verschiedene DATEV-Komponenten sowie Outlook geöffnet.
Nach der Abmeldung des Benutzers wurden sämtliche WINWORD-Prozesse beendet.
Sind ähnliche Effekte mit DATEV Arbeitsplatz bekannt?
Gibt es bekannte Probleme, bei denen Word-Instanzen nach Erstellung von Dokumenten, Vorlagen, PDFs oder Archivierungsvorgängen nicht sauber beendet werden?
Existieren bekannte Inkompatibilitäten mit bestimmten Word-/Outlook-Add-Ins?
Gibt es DATEV-seitige Protokolle oder Logs, mit denen sich nachvollziehen lässt, welcher DATEV-Prozess eine Word-Instanz erzeugt hat?
Über Hinweise oder ähnliche Erfahrungen würden wir uns freuen.
Moin Moin,
nur weil Windows in der Taskleiste kein offenen Prozesse anzeigt, heißt das noch lange nicht, dass vorherige Prozesse im Hintergrund auch wirklich beendet wurden. Ich tippe darauf, dass dies Zombie-Prozesse von vorherigen Word-Aufrufen sind.
Wenn ich das erlebte, war immer mindestens ein Abmelden und wieder Anmelden des Mitarbeiters notwendig, konnte aber auch so schlimm sein, dass der TS neu gestartet werden musste. Das konnte bereits nach einer Woche notwendig sein, hin und wieder war es aber sogar in der Woche notwendig.
Sie können natürlich auch versuchen über den Taskmanager die Word-Instanzen abzuschießen. Mit Glück re4icht das.
Aber das ganz System Datev/Office hat sich meist im Hintergrund, schwer "verknotet".
HTH
QJ
Vielen Dank für die Rückmeldung.
Dass sich solche Word-Prozesse im Laufe der Zeit "verknoten" und sich das Problem häufig durch Ab- und Anmelden des Benutzers beheben lässt, kann ich aus dem aktuellen Fall nachvollziehen.
Mein eigentliches Interesse geht allerdings in eine etwas andere Richtung:
Ich suche weniger nach einer Möglichkeit, das Problem nachträglich zu beseitigen, sondern möchte die Ursache bzw. das Entstehungsmuster besser verstehen und idealerweise proaktiv erkennen.
Im aktuellen Fall konnten wir feststellen, dass die Word-Prozesse nicht als normale Benutzerinstanzen liefen, sondern als:
WINWORD.EXE /Automation -Embedding WINWORD.EXE -Embedding
Die Prozesse wurden also per COM-Automatisierung gestartet und liefen unsichtbar im Hintergrund. Eine Instanz sammelte dabei über mehrere Stunden CPU-Zeit, während parallel DATEV Arbeitsplatz und Outlook in derselben Benutzersitzung aktiv waren.
Nach der Abmeldung des Benutzers wurden alle Word-Prozesse sauber beendet.
Mich würde daher interessieren, ob jemand ähnliche Beobachtungen im Zusammenhang mit DATEV Arbeitsplatz gemacht hat und ob bekannt ist, welche DATEV-Funktionen bzw. Workflows Word über COM automatisieren. Ebenso wäre interessant, ob es bekannte Ursachen gibt, warum solche Word-Instanzen gelegentlich nicht sauber freigegeben werden.
Langfristig würde ich das Verhalten gerne überwachen und auffällige Instanzen automatisiert erkennen, bevor daraus CPU-Probleme auf dem Terminalserver entstehen.
Zwischenzeitlich konnten wir ein ähnliches Verhalten auch bei WPWIN.exe (DATEV Abschlussprüfung) beobachten.
Die Anwendung war durch den Benutzer bereits geschlossen worden, der Prozess lief jedoch weiterhin als:
WPWIN.exe -Embeddingohne sichtbares Fenster weiter und erzeugte über längere Zeit CPU-Last.
Auch hier wurde die Anwendung über COM/DCOM aktiviert (Parentprozess: DcomLaunch).
Daher stellt sich für mich zunehmend die Frage, ob es bekannte Fälle gibt, in denen DATEV-Anwendungen als COM-Server (-Embedding) nach Abschluss eines Vorgangs nicht sauber beendet werden.
Sofern noch nicht geschehen, wäre mir das einen Servicekontakt wert.
@Justus_2026 schrieb:....
Fragen
Sind ähnliche Effekte mit DATEV Arbeitsplatz bekannt?
Gibt es bekannte Probleme, bei denen Word-Instanzen nach Erstellung von Dokumenten, Vorlagen, PDFs oder Archivierungsvorgängen nicht sauber beendet werden?
Existieren bekannte Inkompatibilitäten mit bestimmten Word-/Outlook-Add-Ins?
Gibt es DATEV-seitige Protokolle oder Logs, mit denen sich nachvollziehen lässt, welcher DATEV-Prozess eine Word-Instanz erzeugt hat?
Über Hinweise oder ähnliche Erfahrungen würden wir uns freuen.
zu 1): ich kenne Tage an denen bis Mittag locker 40 WinWord-Prozesse im Taskmanager erkennbar sind. An anderen Tagen läuft alles erwartungskonform.
zu 2) ja, allerdings ist die Ursachenforschung wohl nicht so einfach. Während bei uns es ausreichend war folgende Prozesse/Dateien "AI.exe" bzw. "aimgr.exe" aus dem Umfeld von MS Office durch Umbenennung manuell zu deaktivieren, scheint diese Lösung in andern Konstellationen nicht zielführend; so aus Diskussionen mit den Entwicklern. Jedes Office-Update/-Reparatur spielt neue Versionen in das Verzeichnis.
zu 3.) ich kenne keine die eindeutig mit der Problematik zusammenhängen
zu 4.) allenfalls für Entwickler, nicht aber frei zugänglich
@agmü schrieb:zu 2) ja, allerdings ist die Ursachenforschung wohl nicht so einfach. Während bei uns es ausreichend war folgende Prozesse/Dateien "AI.exe" bzw. "aimgr.exe" aus dem Umfeld von MS Office durch Umbenennung manuell zu deaktivieren, scheint diese Lösung in andern Konstellationen nicht zielführend; so aus Diskussionen mit den Entwicklern. Jedes Office-Update/-Reparatur spielt neue Versionen in das Verzeichnis.
Die beiden Dateien bspw. per AppLocker oder SRP an der Ausführung hindern.