RDP through Devolutions Gateway fails in Launcher 2026.3

Hello Ottos IT team,

Thank you for the detailed report.

Yes, the Launcher uses RDP API hooking for external mstsc sessions. Launcher 2026.3.15.0 starts mstsc through the same code as Remote Desktop Manager, and hooking is on by default. Through the Gateway, hooking gives mstsc the target server's name for TLS and Kerberos validation. Without it, mstsc only knows the Gateway's address.

The Launcher has no settings page for it, so it is set with the EnableRDPHooking policy, and the Launcher honors it. It reads the same policy key as Remote Desktop Manager, HKLM first and then HKCU, and the policy overrides the local setting. A REG_DWORD of 0 turns hooking off and any other number turns it on. A REG_SZ turns it on only when it is exactly 1, so a REG_SZ of True turns it off. Hooking is also off when MsRdpEx.dll cannot be loaded, and when the Launcher runs under emulation on Windows on ARM.

https://docs.devolutions.net/rdm/knowledge-base/knowledge-base-articles/microsoft-rdp-api-hooking/

"Force using IP address for RDP connections" is not required. Our documentation calls it a workaround for the Kerberos name mismatch that API hooking fixes, and recommends turning it off once hooking is enabled. It can have the side effect you suspected. Without hooking, a session connects to the Gateway's IP address. By default Windows does not try Kerberos for an IP address and uses another enabled protocol such as NTLM, unless your clients allow Kerberos for IP addresses. Your two successful tests do not show which was used.

We have no known issue recorded for this in 2026.3. Since the same entry works in Remote Desktop Manager, the next step is to see whether hooking is active in the Launcher on the failing machines. I need two things from one of them.

1. Any EnableRDPHooking value under these keys, with its type (REG_DWORD or REG_SZ) and data.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Devolutions\RemoteDesktopManager
HKEY_CURRENT_USER\SOFTWARE\Policies\Devolutions\RemoteDesktopManager
HKEY_LOCAL_MACHINE\SOFTWARE\DevolutionsLauncher
HKEY_CURRENT_USER\SOFTWARE\DevolutionsLauncher

2. The Launcher's application log, right after a failed connection, from Help, then Troubleshooting, then Application logs. If it opens a Report tab, click Save as. If it opens plain text, click Open to find the log file, and do not click Clear log, which deletes it. An error loading MsRdpEx.dll is recorded in either view, and an empty view is worth knowing too.

Please also tell me whether the failing machines are ARM devices, and attach both to a reply on this topic.

Best regards,

Michel

Hello Michel,

thank you for the detailed explanation. Here are the results from our side.

1. Registry (EnableRDPHooking)
We checked two machines (both Windows 11, build 10.0.26200.9711, AMD x64 devices, so not ARM):
- Machine A: the Launcher fails with our RDP entry.
- Machine B: Remote Desktop Manager works with the same entry.

On both machines the value EnableRDPHooking is not set (reg query returns "value not found") under all four keys:
- HKLM\SOFTWARE\Policies\Devolutions\RemoteDesktopManager
- HKCU\SOFTWARE\Policies\Devolutions\RemoteDesktopManager
- HKLM\SOFTWARE\DevolutionsLauncher
- HKCU\SOFTWARE\DevolutionsLauncher

So no policy differs between the machines. In Remote Desktop Manager the "Enable API hooking" option is set to "Default".

2. Launcher log
We cannot find "Help > Troubleshooting > Application logs" in Launcher 2026.3.15.0. [Entries we see under Help: ...] Where is the Launcher log stored, or how can we open it? Could you also tell us whether there is a log or debug option for the MsRdpEx hooking in the Launcher?

3. More details
- All machines on which the Launcher is used are affected. Machines using Remote Desktop Manager are not. [CONFIRM]
- Only one target server fails. Other RDP entries through the same gateway work in the Launcher. [CONFIRM]
- A workaround: with "Force using IP address for RDP connections" enabled on one of our two gateways, the sessions in the Launcher worked immediately (tested twice). This option is set per gateway. We know it should not be needed with hooking.
- We will also check whether MsRdpEx.dll is loaded into mstsc.exe with "tasklist /m MsRdpEx.dll" while the error window is open, and compare it with an external session started from Remote Desktop Manager. Result: [mstsc.exe loaded / not loaded in the Launcher session; loaded in the RDM session].

Please let us know what else you need.

Best regards

Hello Ottos IT team,

Thank you for checking both machines. With no EnableRDPHooking value under the four keys, and x64 devices, the policy and Windows on ARM are ruled out. Whether the Launcher starts mstsc with hooking on Machine A is still open.

For a Launcher installed in Program Files, the application log is by default in %LocalAppData%\Devolutions\Launcher, named Launcher.log.db, or Launcher.log if it logs to a text file, unless another log or configuration folder was set. If it is not there, tell me how the Launcher was installed. In 2026.3.15.0 the Launcher shows Application logs under Help, in Troubleshooting. If not, please send a screenshot of your Help.

The Launcher has no setting in its interface to turn on the MsRdpEx log. Your tasklist check shows whether mstsc.exe loaded MsRdpEx.dll in the Launcher session. A loaded DLL alone does not prove the hook worked.

I need four things from Machine A.

1. The output of this command, with the Launcher's error window open, and again during a Remote Desktop Manager session.

tasklist /m MsRdpEx.dll

2. A copy of the Launcher's log file, taken right after a failed attempt.

3. Whether every machine running the Launcher fails, and whether only one target server fails. Both were still marked to confirm, and your first post counted a second server. If only one fails, I will look at that server next.

4. If Remote Desktop Manager is installed on Machine A, whether the same entry works from it there.

Please attach these to a reply on this topic.

Best regards,

Michel