Embedded RDP sessions drop with "not enough virtual memory" (GFX 0x8007000E) after Windows 11 25H2 update – works with RDP version 6.1/7.0
Embedded RDP sessions drop with "not enough virtual memory" (GFX 0x8007000E) after Windows 11 25H2 update – works with RDP version 6.1/7.0
Hello,
Since a Windows 11 cumulative update installed on 2026-10-13, embedded RDP sessions in Remote Desktop Manager disconnect 15–30 seconds after connecting with the error:
"This computer can't connect to the remote computer. Your computer doesn't have enough virtual memory available..."
The machine has 32 GB of RAM (about 15 GB free) and an automatically managed page file, so this is not an actual memory shortage.
ENVIRONMENT
- Windows 11 Enterprise 25H2, OS build 26200.9168
- mstscax.dll 10.0.26100.8875
- Remote Desktop Manager 2023.3.35.0, also reproduced after upgrading to 2026.3.13.0
- Hybrid GPU laptop (Intel UHD + NVIDIA RTX 3060), 3 monitors (one via DisplayLink)
- Target: RDP connections through a BeyondTrust Password Safe RDP proxy (Direct Connect, custom port, server redirection). The server negotiates RDP graphics protocol version 0x80105 (AVC not available).
EVIDENCE (Microsoft-Windows-TerminalServices-RDPClient/Operational)
Every failing session, with RemoteDesktopManager.exe as the host process, shows:
- Event 1403: "The client is using software memory for the frame buffer"
- Event 1401: graphics protocol version 0x80105
- Then, 15–30 s later:
- Event 1404: RDP graphics decoding problem, component {472E83D9-4E73-4EBF-B10D-F35CBAD57D09}, function 44, error 0x8007000E
- Event 226: RDPClient_GFX GfxStateDecodingRdpGfxPdu -> GfxStateError on GfxEventDecodingS2CPduFailed (0x8007000E)
- Event 1026: disconnected, reason 3336
The same connection opened with mstsc.exe (the same .rdp file, or RDM in "External" display mode) uses a hardware frame buffer (event 1402) and stays stable. Across all sessions since the update, every RDM embedded session used a software frame buffer, and every mstsc session used a hardware frame buffer.
WHAT DID NOT HELP
- Settings > Performance > Hardware acceleration = DirectX
- Unchecking "Enable software rendering mode" (Avalonia)
- Forcing the high-performance GPU for RemoteDesktopManager.exe in Windows graphics settings
- Fixed resolution, 16-bit color, lower connection speed and other experience settings
- FreeRDP engine: fails to connect to any host in our environment
WORKAROUND FOUND
Entry > Advanced > RDP version = "RDP (6.1)" or "RDP (7.0)": embedded sessions are stable.
Any version 8.0 or higher: the session drops as described above.
QUESTIONS
1. Is this a known issue with the embedded RDP ActiveX control on recent Windows 11 24H2/25H2 builds?
2. Why does the embedded control always fall back to a software frame buffer when mstsc.exe uses a hardware one on the same machine, and is there a setting to change this?
3. Is a fix planned, so we can go back to the default RDP version and keep features such as dynamic resolution?
Thank you.
All Comments (2)
@thiagoforrequi
Hello,
Thank you for your patience while we reviewed this with our development team.
Based on their first review, RDM chooses the frame buffer mode for the embedded RDP control.
In the current version, the embedded control uses software mode, and there is no setting to change it.
This is a technical limit of how the control is embedded in RDM today.
mstsc.exe uses DirectX when it is available, which explains the hardware frame buffer you see with it.
RDP 6.1 and 7.0 stay stable because they never use the RDP graphics pipeline, where the error occurs.
For now, the recommended workaround is the External display mode, which runs the session in mstsc.exe.
Setting the RDP version to 6.1 or 7.0 also works, but you lose features such as dynamic resolution.
We are still investigating why this started on October 13.
The build you listed, 26200.9168, is older than the Windows updates released since late August.
So the change on that date may not be a Windows cumulative update.
Could you check what was installed that day?
- Run winver and send us the full build number.
- In Settings > Windows Update > Update history, list the quality and driver updates from October 13.
- Please also check for an Intel, NVIDIA or DisplayLink driver update around that date.
It may come from Windows Update or from the vendor's own tool.
This will help us find the trigger and reproduce it on our side.
Best regards,
Alexis Beauparlant
Hello,
Thank you for your patience while our team looked into the issue you reported.
I'm happy to let you know that the latest version of Remote Desktop Manager (2026.3.16.0) includes a fix for this problem. You can download it from our website here:
https://devolutions.net/remote-desktop-manager/download/
Once you have installed the update, could you please test it in your environment and confirm that everything now works as expected? If the issue persists or if you notice anything unusual related to the same original problem, just reply to this message with a few details, and we will be glad to look into it further.
Thank you for your collaboration.
Best regards,
Maxim Robert