Since the introduction of the Devolutions Agent, Jump no longer works reliably. Half the time RDM will not recognize that Devolutions Agent is running on the jump host:
Or it will throw an error about the "Now Protoworker not running", restarting RDM will fix this, temporarily.
We would like to use RDM and RDM Jump as the standard method our IT team uses to connect to servers. However, it needs to work reliably. We never had an issue with the legacy RDM Jump but that's being deprecated. How can we get to a similar experience with Devolutions Agent?
bd95cc3b-9068-4743-bb59-f468ed036ff1.png
Hi Christian
Such issues are important to address and that is a high priority for me. We've had many stability improvements over 2026.2 and into 2026.3. Could you let me know, please, the version of RDM you have both locally and on the Jump host, and the version of Devolutions Agent you're using?
Thanks and kind regards,
Richard Markievicz
Hello,
We are experiencing the same issue.
We have been using the Jump Host feature for a long time, and it has worked reliably about 95% of the time.
We switched to the Devolutions Agent when the first deprecation warnings appeared.
Today, we updated to the latest available versions: Devolutions Agent 2.3.0 and RDM 2026.3.9.0.
Since the update, the feature has been completely broken across our environment.
We have reproduced the issue on multiple computers, with multiple coworkers, and through multiple jump hosts.
Hello @AdRaRa
Sorry to hear that. For what it's worth, I did check for fundamental issues here with RDM 2026.3.9 on both client and Jump host, and latest Devolutions Agent but I couldn't reproduce a problem.
You said it's "completely broken" but I'm afraid I need more information to understand. Your issue sounds different to Christian.
When RDP'd to a server with the Agent installed, what does the Devolutions Agent > Agent Status menu tell you for the connection? Is the Agent seen as available, or not? If it's available, is it just Jump connections that are not working? Do you see any error message, either interactively or in Help > Application Logs on the client-side RDM?
Thanks and kind regards,
Richard Markievicz
Hello Richard,
Thank you for your quick response.
I would be happy to provide as much information as possible, but so far I am not exactly sure where to look or which logs would be most useful.
Please let me know what information you need and where I can find it.
On the jump host, both the Devolutions Agent and its service are running. However, when attempting to connect through it, the connection eventually times out and fails with the same message shown in the screenshot from the first post.
On the client side, we are seeing the following message in the application log:
System.TimeoutException: The operation has timed out.
at Devolutions.NowClient.NowClient.ConnectImpl(NowChannelTransport channel)
at Devolutions.NowClient.NowClient.Connect(INowTransport transportImpl)
at Devolutions.RemoteDesktopManager.Business.NowAgent.NowAgent.Connect(Guid instanceId, NowAgentEvents events, CancellationToken cancellationToken)
If there are any additional logs, debug settings, or diagnostic steps you would like me to collect, I will gladly provide them.
Best regards,
AdRaRa
Hi @Richard Markiewicz
RDM version 2026.3.9.0 is running on the jump host and on my workplace. Agent version 2026.3.0 is running on the jump host.
Regards,
Christian
Hello
What would concretely help me find and fix the issue(s) faster would be diagnostics:
That would help me greatly. Please let me know if you have some questions and thank you for your patience
Kind regards,
Richard Markievicz
Hello
Thanks @AdRaRa for sending over the logs. I can see that the RDP virtual channel opens, but RDM does not begin connecting its local end of the transport until approximately 13 seconds after initiating the Agent connection. On the Jump host, the session helper stops waiting for protocol negotiation after 5 seconds so it has already closed the channel by the time the client connects. And the final error message on the client RDM is a consequence of that. So, we are failing to rendezvous the client with the Agent but it's successful for me with the same RDM and Agent versions, which tells me it's not a universal incompatibility.
I am guessing there is a timing related issue and possibly it's the same as @cmagno who seems to see it intermittently.
Can I ask first of all if the RDP side in general appears to be behaving normally versus previous versions? i.e. You double click your jump session, and first the outer connection to the Jump host is launched. Is it normal? The RDP session opens and connects relatively instantaneously, no hang or other strangeness that wasn't present before the update? RDM 2026.3 has had some teething issue with RDP for some customers, and the Agent pieces are closely tied to RDP (they depend on it for transport).
Otherwise, I'd really appreciate if you can capture a dotnet-trace.
Get-Process RemoteDesktopManager | Select-Object Id, Path
& "$env:USERPROFILE\Downloads\dotnet-trace.exe" collect --process-id 12345 --duration 00:00:00:45 --clrevents threading+contention+waithandle+stack --clreventlevel verbose --providers Microsoft-DotNETCore-SampleProfiler --output "$env:USERPROFILE\Downloads\rdm-jump.nettrace"
Please, let me know if something isn't clear or you have further questions
Kind regards,
Richard Markievicz
Hello @AdRaRa
Thanks for your message. Can you please try going to File > Settings > Performance, and under "Entry Images" uncheck "Show favicon cache".
Then, save the changes and relaunch RDM. Is the situation improved?
Thanks and kind regards,
Richard Markievicz
Hello @cmagno
Thanks for your message. The logs reveal nothing to me; they don't even demonstrate a connection (jump or otherwise) being executed.
To try and short circuit this, would you be interested in having a support session so we can out our eyes on the issue rather than going back and forth in the forum?
Please let me know otherwise I can suggest next steps here
Thanks and kind regards,
Richard Markievicz