RDS Black Screen Linked to Trend Micro WFBS on Windows Server

A growing number of administrators are reporting a perplexing problem: virtualized Windows Server instances running the Remote Desktop Server role suddenly become unresponsive for Remote Desktop users at a consistent time of day—sessions appear attached but the remote desktop shows a black screen and input is unresponsive—only a server reboot restores functionality. Multiple investigations point to Trend Micro Worry‑Free Business Security (WFBS) or its Security Agent as the common factor, and while vendor guidance and community reports provide concrete troubleshooting paths, the situation underlines important operational and security trade‑offs for production RDS environments.

Background​

Trend Micro Worry‑Free Business Security (WFBS) is widely deployed in SMB and midmarket environments to provide antivirus, behavior monitoring and endpoint protection. The product includes a real‑time agent that monitors processes, performs scheduled scans and regularly checks for updates. On Windows Server installations the WFBS agent interacts with Windows core components and with Microsoft Defender Antivirus, creating potential interaction zones where misconfiguration, false positives or resource contention can cause functional disruption.
The problem described by multiple readers and administrators is precise in its symptoms:

• Virtual Windows Server instances (examples reported: Windows Server 2019, Windows Server 2022 and Windows Server 2025) hosting the Remote Desktop Services role begin to exhibit an RDP black screen at a reproducible time of day (reader reports ~14:00 CET).
• Existing sessions remain “connected” in that session state persists, but the client only sees a black background; keyboard and mouse input fail to affect the session.
• New RDP logons fail to reach an interactive desktop.
• No obvious Windows Event Log errors correlate to the freeze moment in many reports; a full server restart is often required to restore service.
• Removing/uninstalling Trend Micro WFBS from affected boxes has produced immediate and lasting resolution in the reported cases—however, removing endpoint protection is a blunt remediation with security consequences.

These symptoms differ from other well‑documented RDP problems introduced by Windows updates earlier in the year; while Microsoft released fixes for update‑induced RDP freezes, the Trend Micro‑linked scenario centers on agent behavior, process blocking and/or resource contention on the host.

---

Why Trend Micro is a prime suspect​

Several aspects of WFBS behavior make it a plausible cause when RDP failures appear across multiple servers at similar times:

• Behavior Monitoring and Trusted Programs: WFBS includes a behavior‑monitoring feature that may flag or intercept process behaviors it considers suspicious. Core RDP and desktop compositor components (for example, dwm.exe, dwm.dll and termsrv.dll) are legitimate Windows components but run with elevated privileges and interact with graphics/desktop subsystems—areas where a behavior monitor can interfere.
• Scheduled scans and updates: WFBS agents can run scheduled scans and component updates. If multiple hosts in a group run scans or an agent update simultaneously (for example, at a scheduled window), this can create CPU and I/O pressure at the same time of day across many VMs—matching the reported “same time of day” pattern.
• Interaction with Microsoft Defender Antivirus: On Windows Server systems, Microsoft Defender does not always automatically disable itself when a third‑party AV is installed. If Defender and WFBS run concurrently (or WFBS’s agent and Defender accidentally overlap), resource contention or double‑scanning can cause severe performance degradation or crashes.
• Documented vendor knowledge base entries: Trend Micro’s product documentation and support articles include guidance for RDP issues tied to blocking of specific RDP components and recommend exclusions for dwm.exe, dwm.dll and termsrv.dll, as well as guidance about disabling or managing Microsoft Defender when running WFBS on servers.

These technical behaviors align tightly with the symptoms: a process or module scanned or blocked at a certain clock time, behavior monitoring interfering with the desktop compositor, or scheduled updates/scans inducing resource starvation that leaves sessions visually attached but non‑responsive.

---

What to check first — triage checklist​

When facing a production RDS freeze that looks like the behavior above, follow a fast triage sequence before taking disruptive actions.

• Confirm the commonalities:
• Are the affected servers running the same WFBS/Security Agent version?
• Are they grouped under the same WFBS policy or managed by the same console?
• Do reported incidents happen at similar clock times across hosts?
• Check for concurrent Windows updates or known Windows RDP issues:
• Verify whether recent Microsoft cumulative updates or known RDP‑related patches were applied recently; some Microsoft updates have historically caused separate RDP freeze issues.
• Gather immediate diagnostics (before reboot if possible):
• Remote into host console (if possible) or use hypervisor console to confirm server responsiveness beyond RDP.
• Open Task Manager or Performance Monitor to look for CPU spikes, memory exhaustion, high disk I/O or high context switches.
• Check for stuck processes: look for Trend Micro processes (agent/service names), dwm.exe, termsrv.exe and their CPU/IO behavior.
• Collect Event Viewer logs (System, Application, Security) around the time of freeze.
• If feasible, capture a kernel/user memory dump or a Process Explorer snapshot for analysis.
• Capture Trend Micro logs:
• WFBS and Security Agent logs commonly include real‑time scan events, quarantine events and behavior monitoring alerts. These logs may show blocked or quarantined files or process hooks coincident with the freeze.
• Check for scheduled scans/updates:
• Review the WFBS console for scheduled scans, scheduled updates and Active Agent settings.

Document everything; these artifacts are crucial when engaging Trend Micro support or escalating internally. Avoid rebooting until necessary if you can safely collect diagnostics.

---

Practical mitigations and step‑by‑step guidance​

The immediate aim is to restore predictable RDS availability while preserving endpoint security. Use the following steps in sequence from least to most intrusive.

1) Apply non‑disruptive WFBS configuration changes​

• In the WFBS console, add exclusions for the key RDP and desktop components on Windows servers:
• C:\Windows\System32\dwm.exe
• C:\Windows\System32\dwm.dll
• C:\Windows\System32\termsrv.dll
• Add these entries to both:
• The Trusted Program List, and
• The Behavior Monitoring exclusion (or Behavior Monitoring list).
• Wait for agent policy propagation and verify the agent received updates; then test RDP behavior across a maintenance window.

Rationale: Trusted Program and Behavior Monitoring exclusions stop the agent from intercepting or blocking these components while leaving the rest of the agent active.

2) Review scheduled scans and updates​

• Confirm if a scheduled scan or scheduled update correlates to the freeze time.
• If a scheduled scan is running at the reported freeze window:
• Reschedule scans to an off‑peak maintenance window.
• Stagger agent update/check times (agents check for updates hourly or every two hours by default) so multiple VMs do not update/sync simultaneously.
• If using a managed console, adjust group policy to avoid synchronized active tasks across a farm.

Rationale: Resource contention caused by simultaneous scans/updates is a common, easily remedied cause for periodic freezes.

3) Check Microsoft Defender co‑existence and server mode​

• On servers, verify the state of Microsoft Defender Antivirus.
• If Defender and WFBS are both running, consider putting Defender into passive mode or disabling it on servers where a third‑party AV is the primary protection.
• Use Group Policy or the documented PowerShell/feature uninstall options to manage Defender on server SKUs if required.
• If Defender remains enabled due to Defender for Endpoint onboarding or tamper protection, coordinate with security ops before modifying Defender settings.

Rationale: Simultaneous real‑time engines can conflict or double‑scan; Trend Micro guidance recommends disabling Defender for servers running WFBS if you observe performance issues.

4) Update agents and server OS​

• Ensure WFBS agents and the WFBS management console are at the vendor‑recommended versions (install the latest Security Agent build and engine/pattern updates).
• Keep Windows Server up to date with Microsoft patches; install any vendor patches that address RDP behavior if applicable.

Rationale: Vendors regularly fix agent bugs and update engine logic to avoid false positives or functional interference.

5) Controlled rollback or temporary uninstall (last resort)​

• If the above mitigations don’t stop the freeze and you need immediate recovery on production servers:
• Schedule a maintenance window.
• Remove or disable the WFBS agent on a test or small set of affected servers first to confirm whether the agent removal resolves the issue.
• If uninstall resolves the issue, do not leave the servers unprotected. Instead, plan a short, controlled mitigation:
• Apply host‑level network restrictions: limit exposure to required management networks.
• Use firewall rules and jump hosts to control access.
• Reinstall a corrected or older stable agent version, or wait for vendor patch.
• Document the rollback and notify security teams in advance.

Rationale: Uninstalling the AV can restore service but creates security risk. Use it only as a last resort and for the smallest scope possible.

---

Forensic steps and logs to collect when the freeze recurs​

If the issue reappears after you adjust configuration, gather the following for vendor support and root‑cause analysis:

• Trend Micro Security Agent logs, quarantine logs, and behavior monitoring logs for the timeframe immediately prior to the freeze.
• Windows Event Logs (System/Application) covering the incident interval.
• Performance Monitor traces capturing CPU, disk I/O, and memory utilization sampled at 1–5 second resolution during the incident.
• A Process Explorer dump or Process Monitor trace focusing on process creation, module loads and file I/O for dwm.exe, termsrv.exe and Trend Micro processes.
• A memory dump if the host is fully unresponsive and hypervisor‑level access is available.
• The exact WFBS/Security Agent version string and the WFBS management server version; also list the pattern/engine versions.

Provide these packaged diagnostics to Trend Micro support along with the exact Windows Server build and installed Microsoft KB numbers.

---

Analysis: likely root causes and risk assessment​

Based on vendor documentation and widespread community reports, the following root causes are plausible and should guide remediation prioritization:

• Behavioral blocking of RDP/desktop components: The WFBS behavior monitor may identify normal RDS or desktop compositor behavior as suspicious and interfere with rendering. Excluding core components (dwm/termsrv) commonly fixes these symptoms.
• Synchronized scheduled tasks causing resource exhaustion: If many agents run scans or apply updates at the same instant, CPU and disk I/O spikes can make RDP sessions appear frozen while session state endures.
• Agent/Defender conflict: On some server configurations Microsoft Defender and third‑party agents can coexist in ways that degrade performance. Trend Micro documentation explicitly calls out performance/crash issues when both run on servers unless Defender is disabled or set to passive mode.
• False positive/quarantine of system components: An over‑aggressive pattern or engine update can quarantine or block required RDP DLLs; this would manifest as immediate loss of interactive desktop or black screens.
• A separate Windows update or OS bug: It remains important to rule out Microsoft‑introduced RDP defects (which have occurred historically). Confirm that the problem is time‑correlated with agent activity and not with Windows update installs or a known OS bug.

Risk assessment:

• Removing or disabling endpoint protection without compensating controls exposes servers to malware and lateral movement; this is an unacceptable long‑term stance.
• Adding exclusions for system files reduces the agent’s coverage for those components and should be treated as a risk-managed exception with documentation and approval.
• Disabling Defender on servers can be acceptable in enterprise environments when a centrally managed third‑party AV is in place and properly maintained; it must be coordinated with security policy and compliance.

---

Operational recommendations and hardening checklist​

To reduce the chance of recurrence and improve operational resilience, implement the following:

• Centralized exception policy:
• Create a documented WFBS policy group for Remote Desktop hosts with explicit exclusions (dwm.exe/dwm.dll/termsrv.dll) and audit changes.
• Stagger agent schedules:
• Avoid scheduling full‑system scans or large updates across an entire RDS farm at the same minute. Use randomized jitter or staggered windows.
• Patch management:
• Keep WFBS agents and engines on the vendor‑recommended release cadence. Test agent updates in a small pilot group before broad rollout.
• Keep Windows Server up to date and verify whether Windows cumulative updates include RDP‑related fixes; apply in a controlled fashion.
• Monitoring and alerting:
• Implement monitoring that detects a sudden drop in RDP responsiveness (for example, synthetic checks that perform a simple RDP connect, screenshot and basic input test).
• Monitor agent health, agent update activity and scheduled scan windows centrally.
• Change control:
• Treat endpoint protection policy changes as high‑impact changes requiring change records and rollback plans.
• Communications and maintenance windows:
• Align scheduled scans/updates to off‑peak hours and notify affected stakeholders; create a runbook for rapid rollback if a deployed agent update destabilizes hosts.

---

Vendor engagement and escalation​

If the problem persists after exclusions, schedule changes and Defender adjustments, escalate formally:

• Open a support case with Trend Micro, providing:
• Full WFBS console and agent version information.
• Trend Micro logs, event logs and collected forensic traces.
• Clear description of mitigation steps already tried and the reproducible timeframe.
• Request analysis of behavior monitoring events and pattern/engine updates coincident with the freeze.
• If Trend Micro identifies an agent bug, determine the vendor’s recommended remediation (patch, hotfix, rollback) and request an estimated time to a fix if one is not immediately available.
• Coordinate with your change control and security teams to implement vendor guidance, ensuring minimal production disruption.

---

When a quick fix isn't enough: long‑term architecture changes​

If your RDS farm must run third‑party endpoint protection but exhibits repeated instability, consider longer‑term architectural changes:

• Protect host hypervisors and management networks strongly and reduce in‑guest antivirus scope for well‑protected server workloads that are isolated by network controls.
• Use file‑integrity/EDR approaches that place less intrusive hooks into desktop compositor paths, or rely on endpoint detection and response products that operate in passive monitoring mode and escalate for remediation rather than actively intercepting system processes.
• For highly critical RDS workloads, consider hardened “management only” bastions that are not subject to scheduled scans or agent updates during core business hours; apply a layered security plan to compensate for temporarily reduced local protection.

---

Caveats and unverifiable elements​

A few points deserve cautious wording:

• The specific clock time reported by administrators (for example, ~14:00 CET) is a credible correlation to a scheduled agent activity, but it is not proof of causation without log evidence. Scheduled scans, update checks, or other system tasks can align to corporate local time zones differently across infrastructures.
• Uninstalling WFBS and seeing immediate resolution is strong anecdotal evidence that the agent is involved, but it is not definitive proof of a single root cause type. Only thorough log analysis and vendor debugging can identify whether the behavior monitoring module, an update engine, a pattern file, or an interaction with Defender is the root trigger.
• Trend Micro support articles and knowledgebase guidance note RDP component exclusions and Defender coexistence as known areas of friction; however, specific behavior and fixes will vary by product version, agent version and OS build.

---

Conclusion​

The pattern of simultaneous RDP black screens on virtualized Windows Server instances that resolve when Trend Micro Worry‑Free Business Security is removed points squarely to an interaction between the WFBS agent and the Windows RDS/desktop components. The evidence and vendor guidance converge on a handful of practical mitigations: add behavior monitoring and Trusted Program exclusions for dwm and termsrv, reschedule or stagger agent scans and updates, and ensure Microsoft Defender’s state is appropriate for your server environment. Those actions frequently restore stability without sacrificing endpoint protection.
However, the situation also serves as a reminder that endpoint security agents are not invisible: they can and do affect platform functionality, particularly for sensitive subsystems like Remote Desktop Services. The safest approach is a measured one—collect diagnostics, apply minimal, documented exceptions, test agent and OS updates in a pilot ring, and engage vendor support with comprehensive logs where needed. Never leave production servers unprotected as a long‑term workaround: instead, plan a risk‑managed remediation path that balances availability and security.

---

Source: BornCity Windows: Freezes on Remote Desktop Server due to Trend Micro | Born's Tech and Windows World