RDM for macOS 2026.3: RDP screen corruption on Windows Server 2008 R2 (works in 2026.1.12.4)

Hello,

Since upgrading Remote Desktop Manager for macOS to 2026.3, RDP sessions to one of our Windows Server 2008 R2 hosts show screen corruption within seconds of connecting. Version 2026.1.12.4 works fine with the same Windows session and the same entry settings, so this looks like a regression in 2026.3.

I reported this symptom before in case #https://forum.devolutions.net/topics/44214/rdp-session-issues-when-after-upgrade-the-new-version#208240. It was resolved at the time, but it is back now.

Versions

- Affected: RDM for macOS 2026.3.2.2 (bundled FreeRDP 3.31.1). The problem started after we upgraded to 2026.3.1.2 on 11 Oct 2026.

- Working: RDM for macOS 2026.1.12.4 (bundled FreeRDP 3.26.0). Before 11 Oct we used 2026.1.11.4, with sessions of several hours and no corruption.

- Not tested: 2026.2.x, including the current LTS 2026.2.5.1.

- Client: macOS 15.4.1 (24E263), Apple M4 Pro (Mac16,8).

- Server: Windows Server 2008 R2 SP1 (RDP 7.1, no RDP graphics pipeline).

- Entry: RDP in an embedded tab. Connection type WAN, network auto-detect off, desktop composition on, font smoothing on, screen sizing set to fit to window.

Test on 28 Oct 2026 (same server, user and Windows session)

- RDM 2026.3.2.2: the screen is corrupted within a few seconds of connecting, on every attempt. Screenshot attached.

- RDM 2026.1.12.4: no corruption.

- Microsoft Remote Desktop 10.9.6: no corruption.

Changes tried in 2026.3.2.2 (none helped)

- Rendering engine: Metal (default), OpenGL and CoreGraphics, both globally and as an entry override.

- Codec level: 8, 7 and 6.

- Security: RDP security only, TLS, and NLA. We also enabled TLS 1.2 for RDP on the server (KB3080079) on 16 Oct. The first session after the server reboot looked fine, but the corruption came back.

Drawing orders

In the FreeRDP debug log from the working 2026.1.12.4 session, the server sends only legacy drawing orders: OpaqueRect, MultiOpaqueRect, MemBlt, Cache Bitmap V2 (compressed) and Frame Marker. I can send the log if it helps.

Questions

1. Is this a known issue in 2026.3, and is a fix planned?

2. Is there a setting in 2026.3 that avoids it in the meantime?

3. If you need a debug log from 2026.3.2.2, how do I turn on logging? This version doesn't seem to write one by default.

Best regards,