[English]Ende August 2025 hatte ich auf Grund von Leserberichten über Remote Desktop Server-Freezes berichtet, die sich auf Trend Micro-Sicherheitssoftware zurückführen ließen. Ein Blog-Leser hat mich informiert, dass Trend Micro Version 6.7.4065/14.3.1342 diese Freezes beseitigen soll. Hat jemand das Update getestet und kann dies bestätigen?
Problem Remote Desktop Server-Freezes
Blog-Leser Robert H. hatte mich im August 2025 über ein Problem informiert (danke dafür), welches er bei verschiedene Kunden, die Windows Server (Versionen 2019, 2022 und 2025) einsetzen, hatte. Aus unerklärlichen Gründen frieren die Windows Server-Instanzen bei den Kunden, teilweise zur gleichen Uhrzeit (ca. 14 Uhr MEZ) am selben Tag, ein. Das äußerst sich so, dass zwar alle aktiven Sitzungen am Server bestehen bleiben. Es erscheint jedoch beim Nutzer ein schwarzer Hintergrund der RDP-Verbindung.
Eine neue Anmeldung am Windows Server per Remote Desktop ist nicht mehr möglich. Nur ein Neustart des Windows Servers schafft Abhilfe. Danach ist ein normales Arbeiten wieder möglich – bis zum nächsten Freeze. Das Problem: Zum Zeitpunkt des Freezes werden keine Ereignisse in den Logs protokolliert.
Als Ursache konnte der Leser das allen betroffenen Servern installierte Trend Micro Worry-Free Business Security (WFBS) identifizieren. Ich hatte diesen Sachverhalt Ende August 2025 im Blog-Beitrag Windows: Freezes bei Remote Desktop Server wegen Trend Micro? angesprochen. In Folge meldeten sich weitere Administratoren, die das Fehlerbild bestätigen.
Fixt Trend Micro Version 6.7.4065/14.3.1342 die Freezes?
Blog-Leser Mario H. hat mich zum 30. September 2025 per E-Mail zu obigem Beitrag bei mir gemeldet, weil er eine Ergänzung habe (danke dafür). Mario hatte einen Support-Fall beim Trend Micro zum Problem eröffnet und bekam Rückmeldung. Der Support von Trend Micro teilte dem Leser zum 29. September 2025 mit, dass die Trend Micro Worry Free Business Version 6.7.4065/14.3.1342 zu einem Aktivierungscode von ihm ausgerollt wurde.
Der Leser konnte dies verifizieren, die Version ist seit der Nacht vom 28. September 2025 auf die genannte Version aktualisiert worden. Der deutsche Support habe sich dann telefonisch beim Leser gemeldet und bestätigt, dass diese Version den Fehler mit den einfrierenden Servern beheben soll.
Ich hatte dem Leser vorab den Zugriff auf den Artikel gewährt und er gab folgende Rückmeldung: Es gibt hierzu weitere Neuigkeiten. Der Patch auf die genannte Version brachte nicht die Lösung. Aber die nachfolgend im Screenshot gezeigten ergänzenden Schritte, durchgeführt durch den TM-Support scheint zumindest bisher, immerhin zwei Tage, zu wirken.
Hat jemand aus der Leserschaft, der noch von den Freezes betroffen war, das Update erhalten und kann bestätigen, dass das Problem mit dem Update und obigen Schritten behoben ist?
MVP: 2013 – 2016
Ich kann bestätigen, dass wir auf stark genutzten Terminalservern (mehr als 20 gleichzeitig aktive User) in den letzten Wochen exakt das gleiche Problem hatten. Keine neuen RDP-Verbindungen mehr möglich. Die lokale Console nicht mehr funktional. Server konnten nur durch Poweroff neu gestartet werden. Keine Einträge im Eventlog.
Die Worry-Free Business Security (WFBS) Dienste hatten wir noch nicht als Ursache auf dem Schirm. RDS-Rolle war nach dem Neustart immer 3-4 Tage funktional.
Werden den Workaround mal testen und den Trend Micro Support mit dem Problem konfrontieren.
Vielen Dank für die Info hier im Forum :-)
Bei uns besteht das Problem noch. Hoffentlich gibt es da bald eine funktionierende Lösung.
Wir haben das gleiche Problem mit einer Vielzahl von RD-Hosts seit August. Der Trend Support hat uns den gleichen Hotfix bereitgestellt und wir haben ebenfalls den Treiber tmeyes.sys deaktiviert. Trotzdem sind heute erneut mehrere Server eingefroren.
Das Problem ist also damit noch nicht aus der Welt.
Danke euch für das Feedback – sieht wohl nicht so gut aus.
Heute bei zwei RD-Hosts mit Trend Micro "Hotfix". Das Problem war mit ca. 15 Minuten Unterschied, also fast zeitgleich, auf zwei von 4 mit dem "HotFix" versehenen Servern.
Bei uns wurde auch der Agent-Hotfix installiert. Wir haben alle betroffenen Server neu gestartet und auch die ergänzenden Schritte vorgenommen. Das hat leider trotzdem keine Abhilfe geschaffen. Heute gegen 14:20 standen wieder einige der gepatchten RDS-Server.
Server kommen bei uns nach ca 20-30 Min von allein inkl. aller Sitzungen und ungesicherter Daten ohne Neuanmeldung wieder.
Während des Freeze über LAN auf C$ macht zu diesem Zeitpunkt ersichtlich, dass zum das Windowsverzeichnis, Userverzeichnis und weitere Verzeichnisse fehlen. Sobald die Verzeichnisse wieder auftauchen ist der freeze zu Ende.
Wir habe das gleiche Problem. Haben allerdings watchguard im Einsatz. Regelmäßig frieren die Server ein. Konsole bleibt ebenfalls schwarz. Nur ein Neustart behebt das Problem. Ist es eurer Meinung nach sicher, dass es am Virenscanner liegt?
Wir hatten Trend-Micro bis 2020 im Einsatz. Auch damals gab es schon diese Probleme, insbesondere bei RD-Servern.
Aus diversen Gründen haben wir dieses Produkt in den Wind geschossen.
Servus. Hatte heut auch mal Kontakt zu TM und deren Empfehlung wäre die Installation des Vision One Server Workload Client… hier sollen die Probleme dann gelöst sein
die Lösung für WFB Services dauert wohl noch 🤦🏼♂️
Wir haben das Problem mit ApexOne auch. Die Versionen:
Agent Program 14.0.14081 verursacht die Freezes.
Rollback auf:
Agent Program 14.0.13140 – 14.0.14.39 laufen aktuell noch ohne Probleme.
Der Support von TM wollte das wir nach und nach die Funktionen deaktivieren. Das können wir im Live-System schlecht machen und da die Feezes immer erst am Nachmittag auftreten wäre das eine lange Fehlersuche, daher haben wir den Rollback probiert.
Wir haben das Problem bei Apex One aktuell gottseidank noch nicht. Die haben aber auch Windows Server 2022. Ich hoffe es bleibt so. Ein Kunde hat Trend Micro schon gekündigt. :(
Problem auch mit den oben genannten Schritten besteht weiter. Kunden natürlich extrem sauer.
Wir haben auch das Problem bei verschiedensten Terminalservern (2019-2025) mit WFBS Services. Je mehr User drauf, desto häufiger das Problem, gefühlt. Freezes im Abstand von cirka 1 Woche, wenn die Server täglich durchgebootet werden, seltener.
Werde sicherheitshalber auch ein Ticket bei Trend aufmachen
Gerade die Info von TrendMicro erhalten, dass zum 20. Oktober ein Hotfix erscheinen soll, der das löst. In welcher Form, ob automatisch verteilt, oder manuell was durchzuführen, weiß ich noch nicht
Woher hast du die Info ?
Schreibt er doch: Von TrendMicro – also offizielle Quelle ;-)
Es gibt eine neue Version .4072 die sollte das Problem jetzt beheben.
Anscheined wurde die Datei tmeyes.sys entfernt. Die ist in keinen der beiden Ordner zu finden.
Ich meine 4072 natürlich. Selbst ausprobiert habe ich es nicht. Ich habe bereits mit der 4065 Probleme gehabt, darauf sie deinstalliert, alle Registry-Einträge mit Bezug zu TrendMicro gelöscht, ebenso alle Ordner mit TrendMicro (Programdata, %appdata%, usw.) und darauf hin neustart und Neuinstallation von 4065. Seit dem ist ruhe bei mir. Hoffentlich keine trügerische Ruhe. ;-)
Habe nun die neueste Version 4072, trotzdem träge auf den RDS Servern mit Windows Server 2025. Sobald die Echtzeitsuche aus ist, läuft es viel flüssiger.
Jemand ähnliche Erfahrungen?
Bei mir installiert sich nicht mal die 4072 :(, Mehrmals über Portal angestoßen und auf der VM manuell.. Gibts einen "Sesam öffne dich" Trick zum Update? :D
Ja kann ich nur bestätigen hat sich nicht viel geändert.
Selbes Problem hier, Agent ist auf 4072 gepacht.
Terminalserver friert trotzdem ein, Tickets bei Trend Micro bringen nicht wirklich viel.
Wir haben Server 2019 mit Hyper-V Rolle, da drin sind dann die TS Server.
Komisch ist auch das nicht alle Server betroffen sind betroffen sind,
TS2 und 3 haben das Problem nicht.
Hallo,
wir haben hier das identische Fehlerbild mit Windows Server 2019, CVAD 2203 CU7 und Trend Micro Apex One ("On Premise", Version 14096, https://files.trendmicro.com/documentation/readme/Apex%20One/2020/apex_one_2019_win_cp_b14096_EN_hotfix_Readme.html).
Hat hier noch jemand Ideen zu Workarounds oder weiterführenden Quellen? Der TM Artikel (https://success.trendmicro.com/en-US/solution/ka-0011089) mich nicht wirklich weitergebracht und die "Best Practices"-Liste(n) (TM und MS) habe ich jetzt schon 2x durchgeackert. Danke für Input!
Heiko
Ich habe nochmal vom Support diese Mail bekommen.
On one affected machine kindly check these configuration.
1. C:\Program Files (x86)\Trend Micro\Client Server Security Agent\HostedAgent\CPM\cpmconfig.ini
– Look for the section [Global Setting] and check if AMSP_AEGIS_MODE=0 were present.
2.Verify in Registry [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\TrendMicro\PC-cillinNTCorp\CurrentVersion\AMSP\AEGIS]
AMSP_AEGIS_MODE=0
Wenn ich mir die cpmconfig.ini auf den 3 Terminal Servern anschaue ist die mit dem Freeze anders aufgebaut, gerade unter dem Punkt
# WFBSSVC 6.7 BLP default threshold -s
sind diverse Abweichungen, die . ini Dateien sollten aber meiner Meinung nach gleich sein.
Ich kann den selben Fehler auch bestätigen, sowohl bei RDS 2019, 22 und sogar 25!
die TMEYES Einträge wurde mir vom Support auch empfohlen, haben aber bei mir auch keine Lösung gebracht. Mir wurde im Ticket auch versichert, dass vor ca 1 Woche ein Rollback ohne TMEyes durchgeführt wurde, aber scheinbar scheint das bei euch auch nicht zu helfen bei euch.
Einzige Abhilfe bei mir war es auf es auf das neue Produkt von TrendMicro VisionOne gezwungen zu werden. Seit ich diese Testversion installiert habe, läuft alles überall einwandfrei! Ich warte allerdings auch noch immer auf eine Endgültige Lösung vom Support und habe auch noch immer ein Ticket offen, denn der Umstieg aller Kunden steht eigentlich im Moment nicht am Plan. :-/
Some Problem with XenServer 8.4, w2k22 and latest Trend Micro Apex One. every day on afternoon some machines ca. 20 of 60 freezes for 10-20min and wakre up with no entries in windows log. In a ticket with trend micro they want a reinstall. I tried and hope to get no freezes.
Selbes Problem hier. Diskutiere seit Wochen mit dem Trendmicro-Support ohne Sicht auf Verbesserungen. Sie wollen nun zum zweiten Mal einen Dump der VM. (vmware)