RDM Jump and Devolutions Agent

RDM Jump and Devolutions Agent

avatar

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

All Comments (9)

avatar

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

avatar

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.

avatar

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

avatar

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

avatar

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

avatar

Hello

What would concretely help me find and fix the issue(s) faster would be diagnostics:

  • On the RDM client side, go to Help > Troubleshooting > Performance Profiling
    • Set the Level to "131" and leave the window open
  • Reproduce the "Devolutions Agent is not available on the jump host" issue
  • Send me the output from the profiler window by PM. You could export it to a file, .zip it and attach it to a PM, that's probably the best workflow
  • At the same time, if you are able, please send the corresponding logs from the Agent side. You can .zip both of these folders and attach them also if possible:
    • %programdata%\Devolutions\Agent
    • %appdata%\Devolutions\Session


That would help me greatly. Please let me know if you have some questions and thank you for your patience

Kind regards,

Richard Markievicz

avatar

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.

  • Download Microsoft's x64 dotnet-trace.exe in your browser and save it to Downloads
  • Close RDM completely, reopen it and let it start up
  • Open PowerShell as the same user and find RDM's process ID


Get-Process RemoteDesktopManager | Select-Object Id, Path


  • Launch the trace, replacing the 12345 with the RDM process ID from the previous step. It will run for 45 seconds.


& "$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"


  • Immediately perform a failing jump attempt
  • Leave PowerShell open until it says "Trace completed"
  • Note the local time and time zone, and send it to me along with the output rdm-jump.nettrace file from your Downloads folder
  • Please, treat the nettrace as sensitive information - zip it and attach to a PM, don't post in the public forum


Please, let me know if something isn't clear or you have further questions

Kind regards,

Richard Markievicz

avatar

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

avatar

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