Windows: Freezes bei Remote Desktop Server wegen Trend Micro?

Windows[English]Mir ist ein Leserbericht zugegangen, der über Probleme beim Remote Desktop Server klagt. Unter virtualisierten Windows Server-Instanzen kommt es bei diversen Kunden zum Einfrieren. Das Krasse ist, dass dieser Effekt zu einer bestimmten Uhrzeit auftritt. Es könnte bzw. dürfte an Trend Micro liegen – vielleicht gibt es noch mehr Betroffene.

Blog-Leser Robert H. ist als IT-Mitarbeiter unterwegs und betreut dort verschiedene Kunden, die Windows Server einsetzen. Im Rahmen dieser Aktivitäten ist er auf ein Problem gestoßen, und bat darum, dieses hier im Blog anzusprechen.

Die Windows Server-Umgebungen

Bei verschiedenen Kunden des Lesers sind virtuelle Windows-Server-Versionen (2019, 2022 und 2025) im Einsatz. Bei allen Windows Server-Instanzen ist Remote-Desktop-Server-Rolle installiert. Diese Server sind entweder standalone oder Teil einer RDS-Farm, teilweise mit User Profile Disks (UPDs) oder lokalen Benutzerprofilen, schrieb der Leser.

Remote Desktop Server-Freezes

Aus unerklärlichen Gründen frieren die Windows Server-Instanzen teilweise zur gleichen Uhrzeit (ca. 14 Uhr MEZ) 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 für den Leser: Zum Zeitpunkt des Freezes werden keine Ereignisse in den Logs protokolliert.

Kann Trend Micro die Ursache sein?

Der Blog-Leser schrieb, dass auf allen betroffenen Servern Trend Micro Worry-Free Business Security (WFBS) installiert ist. Ergänzung: In einem Nachtrag vom 28. August schrieb der Leser, dass keine On-Premises-Variante, sondern die Trend Micro™ Worry-Free™ Business Security Services (wfbs-svc) zum Einsatz kommen. Nachdem der Verdacht auf kam, dass das Produkt vielleicht die Ursache wäre, hat die IT Trend Micro auf den betroffenen Maschinen deinstalliert.

Seit diesem Zeitpunkt laufen die Remote Desktop-Verbindungen auf den Windows Servern ohne Freezes durch. Man kann also den Schluss ziehen, dass die Freezes durch Trend Micro Worry-Free Business Security (WFBS-svc) verursacht wurden.

Die Frage von Robert ist: Gibt es in der Leserschaft ähnlich bekannte Probleme? Ich bitte aber alle Leute, die das Problem nicht bestätigen können, weil WFBS nicht eingesetzt wird, oder keine Freezes auftreten, auf Kommentare zu verzichten, um kein unnötigen "Rauschen" zu verursachen. Danke.

Ergänzung: Es sind, gemäß nachfolgenden Kommentaren, ja einige Leute betroffen. Ein Leser hat sich ende September 2025 gemeldet und berichtet, dass der Trend Micro-Support auf sein Ticket hin ein Update ausgerollt und anschließend per manuellem Eingriff wohl das Problem behoben haben könnte. Details finden sich unter Remote Desktop Server: Fixt Trend Micro Version 6.7.4065/14.3.1342 die Freezes?.

Dieser Beitrag wurde unter Problem, Virenschutz, Windows Server abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

53 Antworten zu Windows: Freezes bei Remote Desktop Server wegen Trend Micro?

  1. MadJack sagt:

    Habe nur einen Kunden bei dem Worry-Free Business Security eingesetzt wird auf Windows Server 2016 Terminal Server mit lokalen Benutzerprofilen.
    Bei diesem sind momentan noch keine Probleme aufgetreten. Daher kann ich das nicht bestätigen

    Nachtrag:
    Gerade mit einem Kollegen von einer anderen IT Firma telefoniert. Er hatte das bei einem Windows 2019 Terminal Server das Problem wo Worry-Free installiert war mit Lokalen Profilen. Da arbeiten aber max. 3 User darauf. Wurde neu installiert. Seit dem ist nichts mehr aufgetreten.

    Nachtrag 2:
    Hat er mir erst jetzt gesagt das anstatt Worry-Free jetzt Apex One im Einsatz ist.

  2. Nicky sagt:

    Hallo,

    ja wir können das Problem bestätigen – seit Jahren. Unabhängig von Windows Server 2016 – 2022 (2025 als RDS bisher nicht Einsatz) oder Umgebung von 1 – 15 RDS-Servern mit und ohne FSLogix / User Disks.
    Gefühlt immer dann, wenn der Trend Micro Agent das Network Modul aktualisiert. Es besteht defintiv ein Zusammenhang mit dem Update des Agents auf dem betroffenen Server. Dies passiert allerdings nur sehr selten bei mehreren Servern gleichzeitig.
    Lösungen gibt es weder von Microsoft, noch von Trend Micro.
    Man "lebt" damit ….

    Viele Grüße

  3. Tobi sagt:

    Guten Morgen,

    wir können genau diese Probleme bestätigen! Im Einsatz ist ein Windows Server 2019 RDP-Rollen mit Worry Free Business Services. Fehlerverhalten ist zu 100% gleich und tatsächlich stimmt sogar die Uhrzeit, wann der Server einfriert. Nach dem Entfernen des WFBS funktioniert der Server einwandfrei.

    Grüße

  4. Anonym sagt:

    Andere Trendmicro Lösungen abseits von WFBS scheinen das Problem nicht zu haben

  5. Mika sagt:

    Hmm, hatte dieses Problem auch … allerdings auf 'nem virtuellen 2012R2 (unserem Veeam-Backupserver, mit ESU): schwarzer Bildschirm, Server lief aber, Verbindungen alle stabil.

    Neustart: wieder schwarzer Bildschirm, warten, nach ein paar Minuten war das Bild da.

    Auf dem Server läuft übrigens kein Schlangenöl. Und es war so gegen 12:00 Uhr.

  6. Sebastian sagt:

    Hi,

    wir nutzen auch Trend Micro Worry Free Services auf verschiedenen RDS (alle Server 2022 Standard) und haben dieses Phänomen zum Glück nicht.

    LG

  7. Martin sagt:

    Moin,
    auch in unserer Umgebung vielen Windows Server RD – Hosts sporadisch aus.
    Nach dem Wechsel vor ca. 3 Monaten von WFBS (On Prem) auf die SaaS Lösung , WF-SVC, ist Ruhe.

  8. Stefan sagt:

    Guten Morgen,

    wir können ebenfalls das Problem bestätigen! Unter Windows Server 2019 RDP-Rolle mit Worry Free Business Standard 10.0SP1 Patch 2518. 10 RDP User.

  9. Alexander Aichinger sagt:

    Hallo Leute,

    Kann das tatsächlich bestätigen… Wir haben auch 2 Kunden die betroffen sind… wir rätseln jetzt schon einige Zeit aber jetzt ist es mir klar. In beiden Fällen Win 2019 Server mit Worry Free von Trend Micro. Danke für die Info.

  10. Johannes sagt:

    Wir haben viele 2022 Terminalserver mit WFBS und lokalen Benutzerprofilen im Einsatz und können das Problem nicht bestätigen. Alles auf Proxmox virtualisiert.

  11. RoNie sagt:

    hatte die Problematik ebenfalls, schuld daran dürfte leidlich der Firewall Treiber sein, bei der onprem Variante wird dieser installiert auch wenn die Firewall nicht verwendet wird, bei der SaaS Variante wir er nur installiert wenn die Firewall explizit aktiviert ist.

  12. Martin sagt:

    Wir können es auch bestätigen.
    Hier läuft allerdings die Saas Lösung auf Server 2019.
    Somit nicht nur die On Premise WFBS betroffen.
    Tritt meines Erachtens seit dem 06 August regelmäßig auf.

    Ich hab jetzt diverse Module deaktiviert wie z.b. die EDR Funktionen. Seit Freitag ist jetzt Ruhe. Aber von 10 rds erwischt es teilweise nur 2-3 server. Und an machen Tagen gar keinen, daher will ich mich noch nicht zu früh freuen.

    • Martin sagt:

      Leider trat es wieder auf.
      Bei uns hat sich seit gestern die Uhrzeit von ca 14:00 Uhr (was es nun wochenlang war) auf ca 18:30 verschoben.

      Irgendwas dreht TM wohl.

  13. Stefan sagt:

    Wir haben nur 3 wts im Einsatz, alle mit Trend Micro worry free Business Security Services,
    und keine derartigen Probleme.
    Dafür soll aber bei einem Kunden laut Agenda, Hotline Trend Micro für das abstürzen von Agenda schuld sein? Werden wir nach der Urlaubszeit prüfen!

    • Ansprechpartner sagt:

      Das Agenda Problem habe ich aktuell ebenfalls seit einigen Tagen bei einem Kunden, dort ist nun WBS deinstalliert, seit dem ist Agenda stabil und deutlich schneller. Lt Agenda Hotline ist Trendmicro auch nicht supportet. Ich nutze Trendmicro bei allen Kunden bisher seit 20 Jahren weitestgehend problemlos.

  14. Markus sagt:

    Hi, das Problem kann ich ebenfalls bestätigen. Wir haben einen RDS 2019 mit Trend-Micro WF im Einsatz. Hier trat immer wieder das Problem auf, dass der Server eingefroren ist und der Server neugestartet werden musste. Allerdings wurde kurz vor dem Absturz im Log protokolliert, dass eine Datei einen Fehler verursacht hat. Die Datei gehört zu Trend-Micro. Seit der Deinstallation des TM-Clients auf dem Server, läuft er, toi toi toi, durch.
    Der Support von Trend-Micro hat sich dazu leider nicht geäußert. Ist jetzt schon drei Monate her.

  15. Andy sagt:

    Auf einem Server 2016 ohne Zusatzsoftware ist es mir diese Woche auch mehrfach passiert, daß nach kurzer Inaktivität der Bildschirm schwarz war und die Verbindung zur Admin-Sitzung getrennt und neu verbunden werden musste. Die Sitzung selber lief auf dem Server weiter. Client ist ein W11-24H2-Arbeitsplatz mit neuestem Update. Die Uhrzeit hab ich mir nicht gemerkt.

  16. J. sagt:

    Haben das gleiche Problem mit RDS auf Server 2022. Aber nicht mit Worry Free, sondern der Vision One Server & Workload Protection.

    Nicht nachzuvollziehen, wann und warum die Kiste einfriert, aber gleich Symptome. Schwarzer Schirm und hilft nur noch Reboot. Keinerlei Eintrag in irgendwelchen Logfiles oder Ereignisanzeige. Komischerweise auch nicht auf allen Servern.

  17. Lukas sagt:

    Haben zur Zeit ähnliche Probleme aber es handelt sich um das Einfrieren von Remotverknüpfungen zu Azure Virtual Desktops, wobei dort kein Trend Micro installiert ist. Auf den Azure Virtual Desktops läuft Windows 11 Multiuser.

  18. Dirk sagt:

    Moin Zusammen,
    wir haben extakt das gleiche.
    Allerdings nur bei Server 2022 RDS, veschiedene Kunden, alle via Hyper-V gehostet
    Fast täglich gegen 16Uhr stehen die Server.
    Wir sind nun auch damit angefangen TM zu deinstallieren, seitdem ist Ruhe.

  19. Manuel sagt:

    Ich habe dieselbe Konstellation mit rds und trend micro worry free services bei mehreren kunden. auch bei mir frieren (nur die rds) ein! nach ca 15-20min erwecken sie sich aber auch selbst wieder zum leben und es kann weiter gearbeitet werden. Seit 2 Tagen ist das Problem bei meinen Kunden.
    keine Einträge in den Logs ersichtlich, habe auch trend micro in Verdacht

    das ist natürlich ein Nogo, hoffe TM unternimmt etwas.

  20. Mario sagt:

    Hallo zusammen,

    exakt dasselbe Problem haben wir mit Windows 2019 und 2022 Remotedesktop Rolle und Worry Free Business Security Services seit Anfang August bei einigen Servern.
    Der Server friert ein und alle Sitzungen werden getrennt. Auf der VM kann man anhand der Uhrzeit am Anmeldebildschirm erkennen, wann der Server eingefroren ist, da die Uhrzeit stehen bleibt.
    Nur noch ein aus- und wieder einschalten hilft. Im Windows LOG können wir keine Fehler finden.
    Trendmicro hatte ich auch schon in Verdacht und deshalb bei einem System eine De- und Neuinstallation durchgeführt, leider bisher ohne Erfolg.
    Grüße
    Mario

  21. Manuel sagt:

    Heute sind wieder mehrere RDS Server gestanden!
    na ca 25min waren sie wieder verfügbar.
    Wie alle schreiben, Uhrzeit friert ein, alle Sitzungen werden getrennt, danach läuft es weiter als ob nichts gewesen wäre…
    Und auch immer um 16h herum!

    Hat jemand schon eine Lösung gefunden?
    Katastrophe!!

    • Nicky sagt:

      Können wir auch absolut bestätigen. ca. 15:55 – 16 Uhr bei 4 verschiedenen Kunden insgesamt 9 RDS Server mit Server 2022 und WFBS-SVC krachen gegangen. Haben uns zum Schwenk auf Bitdefender entschieden, da dies einfach nicht mehr tragbar ist.

  22. Rana sagt:

    Moin! Wir haben auch das gleiche Problem bei einigen Kunden.

  23. Christian sagt:

    Selbiges Problem auch bei uns:
    – virtuelle Windows Terminal Server (2016/2019/2022)
    – Single und als Farm
    – Mit und ohne UPD
    – TrendMicro WFBS Svc installiert
    – Wahllos Random durch die Kundschaft
    – Uhrzeiten zwischen 15 und 17 Uhr
    – Server sind nach 20-30 Minuten wieder erreichbar als wenn nicht gewesen wäre

  24. Alexander Aichinger sagt:

    Also wir haben einen Support Case bei Trend Micro. die behaupten sie wissen von nichts. Auch der Link zu diesem Blog hat nichts geholfen… Versuchen es jetzt über die Partnerbetreuung. Wäre super wenn alle betroffenen einen Case starten würden. Unser Case lautet: TM-03748868 P3

  25. Tomas Jakobs sagt:

    Jedem Verantwortlichem ISB/CISO sollten die Alarmglocken klingeln. Ist ja nicht so, dass gerade ein elementares Schutzziel Avialbility Ex gegangen ist, ist ja nicht so, dass man sowas unlängst erlebt hat, als amoklaufendes Schlangenöl weltweit Milliardenschäden verursacht hat.

    Aber selbstverständlich wird das alles ohne Konsequenzen bleiben, weil kein Entscheider den Arsch in der Hose haben wird, 3rd Party Schlangenöl rauszuwerfen und statt dessen andere mitigierende Maßnahmen einzuführen.

  26. Daniel und Hermann sagt:

    Wir haben die gleichen Probleme und eröffnen gleich einen Fall mit Referenz auf den Fall: TM-03748868 P3

  27. Shannen sagt:

    Within the last month or so we are experiencing this issue along with Intel WIFI Adapters disappearing when returning from Sleep requiring a reboot to resolve.

    Both support tickets with Trend mentioned a new driver TMEYES which appears to do with improved Ransomware Protection, they have requested testing Disabling it under Behaviour Monitoring for the WIFI Adapter issue and getting support to set AMSP_AEGIS_MODE=0 on the backend for the RDS (implied it might be larger then just RDS) freeze/BSOD issue.

    • Manuel sagt:

      Hi,
      Bist du dir sicher, dass das WiFi Problem auch mit TM zu tun hat?
      Ich habe seit ein paar Monaten dasselbe Problem bei Notebooks!
      Dachte bisher aber an HP, Treiber und Windows. TM hatte ich bisher nicht in Verdacht, aber auch noch nicht gegengetestet…

      lg

      • Phil sagt:

        Wir können das Phänomen mit dem WLAN nach dem Ruhezustand bestätigen. Ohne TM passiert das nicht. Es gibt dazu einen Patch, welcher durch den TM-Support bei uns jetzt priorisiert ausgerollt wird.

  28. Agostino Vignola sagt:

    Wir haben dasselbe Problem zu 90% immer zwischen 15 und 16 Uhr. Diese Woche zum ersten Mal am Vormittag um ca. 9.30Uhr. Bei uns sind mehrere RDS Server betroffen. Alle sind auf vmware. Proxmox nicht betroffen. Unterschiedliche Instanzen frieren gleichzeitig ein. Ticket eröffnet TM-03761338. Nach dem CDT musste ich die CPMConfig.ini Datei anpassen und ein Regkey erstellen. Das haben wir auf einem RDS gemacht, und müssen nun warten ob es nochmals passiert :-(

    1. Unload Agent
    2. Open notepad as admin and copy the contents of CPMConfig.ini located under C:\Program Files (x86)\Trend Micro\Client Server Security Agent\HostedAgent\CPM:
    3. Add the contents in CPMConfig under [Global Setting] and save:
    [Global Setting]
    AMSP_AEGIS_MODE=0
    4. Check the following regkey, manually modify it if not present:
    Reg key:

    Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\TrendMicro\PC-cillinNTCorp\CurrentVersion\Misc.

    AMSP_AEGIS_MODE=0
    5. Reload the agent and verify if issue persists

  29. Alexander Aichinger sagt:

    Kann man schon sagen ob das hilft?

  30. Manuel sagt:

    Bei mir ist es heute auch exakt gleich aufgetreten 16-Sep-2025 15:43
    16-Sep-2025 16:06.
    Sowie auch gestern: 15-Sep-2025 15:36 – 15-Sep-2025 15:46

    Für mich ist es eins wenn sich ein Fehler im Produkt einschleicht, kann passieren.
    Aber das ein Haufen Techniker den Fehler innerhalb mehrere Wochen nicht finden kann, der eh immer zur selben Zeit auftritt und wenigstens einen Workaround bieten kann, ist für mich unverständlich.

    AMSP_AEGIS_MODE=0 wurde mir auch vom Support gesagt, hilft aber nicht.
    Hat es euch geholfen?

    • Agostino Vignola sagt:

      Es hat nicht geholfen! :-) Hatte gestern wieder einen Freeze! Hab dies an TrendMicro gesendet: Lieber …

      Wir überlegen derzeit, ob ein Produktwechsel notwendig ist. Es ist bedauerlich, dass TrendMicro das Problem nicht lösen kann, und es zieht sich nun schon seit Wochen, wenn nicht Monaten, hin. Unsere Kunden zeigen bisher Verständnis, aber wie lange noch?

      Bitte informiert uns über den aktuellen Stand der Dinge. Wir benötigen mehr Informationen!

      • Manuel sagt:

        Danke für die Rückmeldung. Ich hatte gestern eine Fernwartung mit dem Support und es wurde ein weiterer Versuch unternommen AEGIS abzuschalten mit Umbenennung von .sys Dateien. Wir werden sehen…

        Hat jemand schon versucht auf den neuen Vision One Agent umzustellen?

  31. Mario Heiß sagt:

    Hallo zusammen,

    Teilweise hat es bei uns geholfen, aber teilweise auch nicht. Gestern und heute wieder 2 Einfriervorgänge, einer um ca. 11:10 Uhr, der zweite um 17:40 Uhr und gestern um 14:10 Uhr und 17:30 Uhr.
    Teste jetzt an einem System die Deinstallation.

    • Mario Heiß sagt:

      Kleiner Nachtrag: Die Deinstallation hat definitiv das System stabilisiert. Nun wartet Trendmicro in dem Support Fall auf eine Rückmeldung und die Zusendung von Absturzprotokollen. Hierfür müssten wir die Software wieder installieren und das System destabilisieren. Geschrieben hatte ich Trendmicro bereits, dass wir die Software erst wieder installieren werden, sobald wir wissen, dass diese auch stabil läuft.

  32. Manuel sagt:

    Hallo zusammen,
    bei mir half der Workaround nichts, gestern ist wieder alles gestanden, allerdings zu einer anderen Uhrzeit. 18:15 -18:45, leider arbeitet mein Kunde da auch noch ;-)

    Angeblich gibt es einen Hotfix seit gestern, der heute ausgerollt wird.
    Letzter Versuch, danach wird gewechselt…

  33. Alexander Aichinger sagt:

    Wir hatten wieder Freezes heute… bis jetzt hat nichts geholfen. Der erste Kunde wechselt morgen…. :(

  34. Messerschmidt sagt:

    In zeitlichen Zusammenhang dazu ist bei uns aktuell die DWM.exe im Fokus.
    Ist zwar immer nur als Info im Syslog, jedoch immer nur in zeitlicher Nähe zur Freeze Zeit.

  35. Messerschmidt sagt:

    Hallo,

    seitdem ich weitere Merkwürdigkeiten dazu entdeckt habe, sprechen wir aktuell nicht mehr von "freeze", sondern nur noch von "Schrödingers Katze/Server".
    Die betroffenen virtuellen Server haben zwar ein freeze-Bild auf RDP und auch Console, sind jedoch weiterhin übers LAN mit Ping und anderen Varianten erreichbar (also nicht ganz tot). Fast immer braucht man nur ca 20-30 Minuten warten, und der Terminalsserver ist mit allen Sitzungen wieder am funktionieren. Und dies sogar auch ohne Neuanmeldung. RDP Verbindung und Console gehen einfach wieder.
    Gestern allerdings noch mehr "Schrödingers Katze/Server" Zutaten bemerkt. In der Zeit des "freeze" erkennt man auf dem betroffenen Terminalserver über die administrative Freigabe der LAN Verbindung "\\Terminalserver\C$" das fehlen vieler Ordner wie zB "C:\Users" und "C:\Windows".
    Somit ist klar – keine Windows Ordner – keine Funktionen.
    Sobald nach den ca 20-30 Minuten warten die Ordner plötzlich wieder auftauchen funktiert der Terminalserver auch sofort und problemlos und ohne Reboot inkl. aller Sitzungen weiter als wäre nichts gewesen. Selbst alles nicht gespeichertes ging nicht verloren. Wie aber lässt eine Virenscanner temporär Ordner verschwinden?

    Vielen Dank für alle Gedanken dazu

  36. Manuel sagt:

    Ich kann das Verhalten bestätigen.

    Ich habe die RDS auf den VisionOne Agent (auch von TrendMicro) umgestellt.
    Seit 1 Woche keine Probleme mehr bei den Kunden…

    Habe aber noch immer ein Ticket offen, bisher konnte der Support wirklich nichts zur Lösung beitragen und der Verlauf des Tickets und der Kompetenz muss (nett ausgedrückt) leider als negativ bewertet werden.

  37. Andreas Schneider sagt:

    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?

    • Manuel Srienz sagt:

      also ich habe nun seit 1 3/4 Wochen den Schutz getauscht und bei keinem Kunden mehr einen Ausfall gehabt, vorher hatte ich täglich mehrere verärgerte Kunden. Meiner Meinung nach 100% der Worry Free Agent…

  38. Markus Haberstroh sagt:

    bei einigen Kunden hat geholfen C:\Windows\System32\wbem\WmiPrvSE.exe den sicheren Windows Programmen hinzuzufügen, die hatten aber eher Performanceprobleme am RDS

Schreibe einen Kommentar zu Manuel Srienz Antwort abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert