At 2:00 PM Central European Time, remote desktop sessions across multiple Windows Server farms abruptly freeze. The screen goes black, input stops, and a server reboot becomes the only fix. IT administrators at several organizations traced the culprit to a single piece of software: Trend Micro Worry-Free Business Security (WFBS). The findings, originally reported on BornCity and corroborated by a growing community of sysadmins, paint a clear picture of an endpoint security agent clashing with core Remote Desktop Services components.

The Predictable Crash: Symptoms and Scope

The issue manifests with surgical precision. Virtualized Windows Server instances—spanning Server 2019, 2022, and the recently released Server 2025—hosting the Remote Desktop Services role suddenly become unresponsive. Active RDP sessions remain technically connected, but users stare at a black screen. New login attempts hang at a blank desktop. Server performance monitoring reveals no preceding spike; no related events appear in the Windows Event Log at the moment of failure. Only a hard reboot restores service.

Multiple organizations described identical timelines: the freezes occurred around 2:00 PM CET, suggesting a scheduled trigger. The common thread? All affected servers ran Trend Micro Worry-Free Business Security, a popular endpoint protection suite in small and mid-sized businesses. When administrators removed WFBS from test servers, the freezes stopped immediately and did not recur.

Why Trend Micro WFBS is the Prime Suspect

WFBS bundles real-time antivirus, behavior monitoring, and scheduled scanning into a single agent. That agent hooks deeply into the operating system to intercept process activity, file I/O, and network operations. Several behaviors make WFBS a plausible—and now confirmed—cause of RDP blackouts:

  • Behavior Monitoring False Positives: WFBS’s behavioral engine may misinterpret normal RDP and desktop compositor actions as malicious. Critical Windows components like dwm.exe (Desktop Window Manager), dwm.dll, and termsrv.dll (Terminal Server) run with elevated privileges and interact closely with the graphics subsystem, making them prime targets for overzealous interception.
  • Synchronized Scheduled Scans: WFBS agents often run full scans or update checks at a fixed daily time. If an entire RDS farm is configured with the same schedule, every host experiences a simultaneous burst of CPU and disk I/O, starving essential services and freezing user sessions.
  • Conflict with Microsoft Defender: On Windows Server, Microsoft Defender antivirus does not always disable itself when a third-party AV is present. Coexistence can lead to double-scanning, resource contention, and crashes. Trend Micro’s own documentation warns of performance issues when Defender and WFBS run concurrently.
  • Quarantine of System Files: An over-aggressive signature update may quarantine or block a critical RDP DLL, instantly breaking interactive desktop functionality.

These vectors align perfectly with the repeated, clock-synced nature of the outages.

Immediate Triage: What to Check Before You Reboot

When an RDS freeze strikes, avoid immediate rebooting if you can collect diagnostic artifacts. Use a hypervisor console or out-of-band management to access the server without RDP, then run through this checklist:

  1. Confirm the pattern: Are all failing servers on the same WFBS policy? Do they freeze at the same time every day?
  2. Inspect running processes: Open Task Manager or Process Explorer. Look for dwm.exe, termsrv.exe, and any Trend Micro processes (TmListen.exe, Ntrtscan.exe, etc.) that might be consuming 100% of a CPU core or exhibiting stuck I/O.
  3. Check resource utilization: Use Performance Monitor or resmon to look for sudden spikes in disk queue length or context switches that could indicate a scan storm.
  4. Collect logs: Export System, Application, and Security event logs covering the hour before and after the freeze. Even if no error appears at the exact moment, surrounding events may provide clues.
  5. Capture Trend Micro logs: WFBS logs real-time scan events, quarantine actions, and behavior monitoring alerts. Locate the agent logs (commonly under %ProgramData%\Trend Micro\Security Agent\Logs) and secure a copy.
  6. Take a memory dump: If the server is fully unresponsive but accessible via the hypervisor, capture a complete memory dump for vendor analysis.

Document every step; these artifacts are essential for a meaningful support ticket.

Practical Mitigations: A Step-by-Step Guide

Administrators need to restore RDS availability without leaving servers unprotected. The following actions progress from least to most intrusive.

1. Add Trusted Program and Behavior Monitoring Exclusions

In the WFBS management console, navigate to agent policy and add exclusions for the core RDP components:

  • C:\Windows\System32\dwm.exe
  • C:\Windows\System32\dwm.dll
  • C:\Windows\System32\termsrv.dll

Place these entries in both the Trusted Program List and any Behavior Monitoring exclusion lists. This prevents the agent from scanning or hooking these processes while keeping all other protection active. After policy propagation, test RDP connectivity during the previously affected window.

2. Reschedule and Stagger Agent Tasks

Identify any scheduled scan or update task that runs near 2:00 PM CET. Either shift it to an off-peak maintenance window or, better yet, randomize the start times across the RDS farm. Many agents check for updates hourly by default; spread these checks by configuring a randomized delay or using different update schedules per server group.

3. Manage Microsoft Defender Coexistence

On Windows Server, use PowerShell to check Defender’s state:

Get-MpComputerStatus | Select-Object AMRunningMode

If Defender is active alongside WFBS, configure it for passive mode if you use Defender for Endpoint, or disable it entirely via Group Policy if WFBS is the primary AV. Coordinate with security teams before disabling Defender, as tamper protection or organizational policy may override local changes.

4. Update WFBS Agent and Windows Server

Trend Micro regularly releases agent updates that address false positives and performance bottlenecks. Verify that your WFBS agents are on the latest version and that the console and pattern files are up to date. Simultaneously, ensure Windows Server has the latest cumulative updates, as Microsoft has previously released patches for RDP-related hangs. The combination of current AV and OS versions often eliminates compatibility gaps.

5. Controlled Agent Uninstall—As a Last Resort

If users are unable to work and other mitigations fail, schedule a maintenance window and remove the WFBS agent from a small subset of affected servers. If the freezes stop immediately, you have final confirmation of the agent’s role. However, do not leave servers unprotected. Implement compensating controls: restrict network access to management interfaces only, enable host-based firewall rules, and use jump servers for remote administration. Plan to reinstall a corrected agent version or the official vendor fix as soon as it becomes available.

A Vendor Fix on the Horizon?

An addendum to the original BornCity report mentions that Trend Micro has released a specific fix. The version string 6.7.4065/14.3.1342 is cited as a possible resolution. While the source asks “Does Trend Micro version 6.7.4065/14.3.1342 fix the freezes?” the implication is that a targeted update is available. Administrators should contact Trend Micro support to obtain this hotfix or a later build and test it in a pilot group before broad deployment.

Forensics: What to Send to Trend Micro Support

If the problem persists after applying the above mitigations, open a priority case with Trend Micro and provide:

  • The exact WFBS Security Agent and Console version, plus engine/pattern versions.
  • Agent logs, behavior monitoring logs, and quarantine logs from the freeze window.
  • Windows Event Logs (System, Application) exported as .evtx files.
  • Performance Monitor data collected at 1–5 second intervals during the incident.
  • A Process Monitor trace or Process Explorer dump filtered to dwm.exe, termsrv.exe, and Trend Micro processes.
  • If possible, a full memory dump of the frozen server.

This package allows the vendor to pinpoint whether behavior monitoring, a scheduled task, or a signature update triggered the blackout.

Long-Term Architecture Adjustments

For organizations that rely heavily on RDS and cannot tolerate such disruptions, consider architectural changes that reduce in‑guest endpoint protection risk:

  • Strengthen hypervisor and network security. If the virtual host and surrounding network are tightly controlled, the need for intrusive guest agents diminishes. Isolate RDS servers behind a secure gateway and enforce strict access controls.
  • Switch to EDR solutions with passive modes. Some Endpoint Detection and Response products can operate in a detection‑only mode, sending telemetry to a central console without actively blocking or scanning system components. This avoids the hooking conflicts that plague behavior monitors.
  • Schedule scans outside business hours. Create a separate WFBS policy for RDS hosts that runs all scans and updates between midnight and 4:00 AM, staggered across the farm.
  • Implement synthetic RDP monitoring. Set up an automated script that attempts an RDP connection every few minutes, verifies that a desktop renders correctly, and performs a simple input test. Alert on failures to catch freezes before users report them.

Risk Assessment and Operational Discipline

Adding exclusions for dwm.exe, dwm.dll, and termsrv.dll slightly reduces the security agent’s coverage. Treat these exceptions as formal risk acceptances: document them, seek security team approval, and review them quarterly. Disabling Microsoft Defender on a server may be acceptable if WFBS is centrally managed and kept current, but check compliance requirements first. The overarching lesson is that endpoint protection agents are never truly transparent—they operate in kernel space and can cripple sensitive subsystems like Remote Desktop Services. Change control must encompass AV policy updates, engine upgrades, and pattern releases with the same rigor as operating system patches.

The Trend Micro WFBS‑induced RDP blackout is a solvable problem. A methodical approach—triage, exclusion, rescheduling, and vendor engagement—restores stability while maintaining a strong security posture. Administrators should test the emerging fix version 6.7.4065/14.3.1342 at the earliest opportunity, and the community’s rapid identification of the root cause underscores the power of shared sysadmin experience.