RDM stops responding

This is indeed odd. We did solve a possible freeze on startup with v2026.1.11.

Next time the app freezes, could you please capture the state via a mini-dump file?

Attention: you must follow the steps outlined here and read the disclaimer.

https://docs.devolutions.net/rdm/kb/troubleshooting-articles/hung-rdm-dump-file-creation/

I downloaded and installed RDM 2026.1.15.0 yesterday evening.
I started using it this morning and it just froze again, after 3 1/2 hours of starting the program.
I followed the instructions and have contacted support.
thank you.

Thanks, I haven’t looked at your files yet, but in the meantime, could you please answer this question?

At the time of the freeze, did you have one or more web entries open? If so, how many? Had they been open for long?

We believe there may be an issue with polling in the WebView2 control, where the polling interval is shorter than what the control can handle, causing it to be overwhelmed until it hangs. This is the theory we arrived at with another client. In the next version, we have an option to adjust the polling interval as a test to see if it makes a difference. Once we pinpoint the exact issue, we can implement a more permanent fix.

Best regards,

I did have a web connection to a local URL open.
I have closed the web site now and will report if the restarted application freezes again.

Case number is 00114855
The RDM application is frozen again. This time, I do not have a web connection open. This froze when I logged off of a server which closed my connection to that server. I have one other connection to a different server.
I did open Task Manager and captured the "wait chain" for Remote Desktop Manager that shows threads in a wait status. Using Process Explorer, I highlighted each of the three threads identified and took screen shots. I also created another mini-dump.
As I mentioned above, I did contact support, they assigned a case number, I'm just waiting to hear how I can get files to you.

Ugh. Ok, it happened again, also when I logged off a server and my connection closed.
I still have (had) one connection open to a different server but since the application is not responding, I cannot access the connection tab.

Hello

I've looked at the files you've provided and there is a smoking gun, but I don't have a definitive underlying reason for the freeze.

Here is what happens: embedded RDP is provided by the Microsoft RDP ActiveX control, which is a component they provide and works as something of a black box. When we tear down an embedded RDP session, first we ask the ActiveX control to "Disconnect". In normal cases (99% of the time) disconnection is almost instant, a second or two at most. Shortly after we tear down the tab and tell the ActiveX to release it's resources.

If the ActiveX is still waiting to disconnect, the call to release resources (which must happen on the UI thread) will block and freeze the application. This is an issue that's come up over and again over the years and we don't understand why it happens, nor can we easily reproduce it. There is an existing workaround in the application that gives the ActiveX an additional 8 seconds to answer the call to disconnect; then the release is deferred for a further two seconds. But if the control is still blocked at that point, the next time we try to callback to the UI thread the application deadlocks.

I've submitted a change to RDM Windows that takes a different strategy. If the 8 second wait to disconnect passes, we'll poll the control for a further 60 seconds (in the background) waiting for it to disconnect. If it disconnects in that time - perfect, everything will proceed as normal. If it still hasn't disconnected, we'll simply leave it - leaking the control and its resources (which can be fairly heavy - at least 6-10 threads and numerous handles). Ultimately I'd argue that's better than a freeze and shouldn't be an issue unless this happens repeatedly, and the RDM process itself is very long-lived. I don't see another solution than moving the RDP embedding out of process, which is a huge task. I do blame issues like this on Microsoft, because although the ActiveX control shares code with mstsc it's a completely different process model, and Microsoft themselves don't use the ActiveX in any of their products; so they don't really hit or address these kinds of problems.

I hope to get that fix merged into RDM Windows and in an imminent update, and we can see if it helps your situation.

In terms of concrete steps you can take right now: often this condition is directly attributed to RDP using the UDP/multitransport channel but I can see from your files that this is not the case. The other things I can think of are high network latency (not sure if that's the case) and misbehaving virtual channels. Virtual Chanels are things like drive redirection: if you're not using things like drive redirection, printer redirection and audio in/out redirection, I'd recommend turning off those that you don't use and see if it helps. It's worth a try. RDPGFX (the RDP 8.1 graphics channel) could also be implicated but that's much harder to disable.

I do apologize for the inconvenience, and thank you for your patience. I hope that my fixes will help and we'll let you know once that's available. Don't hesitate with questions or comments in the meantime.

Thanks and kind regards,

I did have local resources (printers, hard drive) shared, but have since disabled those.
I also set Remote computer sound - Sound hook to "Do not play" instead of the default value.
Looking around at other connection properties, would it make a difference changing the Advanced > Log off mode from "Default" to another value? Or change the RDP version from "Latest" to another value?

Hello

No, that should not make a difference. I'm hoping that the RDP ActiveX is just taking long to disconnect; and the suspects I have in that case are UDP (not used in your environment) and virtual channels (mainly device redirection; although as I said graphics can use the same mechanism and that's harder to switch off). Some of the channels are just generic "virtual channels" so they don't tell me what they are in the mini dump.

It would be an interesting data point if the issue persists after disabling redirections.

A side note - are you using any third party RDP extensions? I don't see any in the mini dump, but such things can sometimes masquerade as system files...

Moving forward as I said, I've made a change here that will be available in 2026.1.16 that I hope should alleviate the problem. Your results will be very interesting once that is released and you have a chance to try it.

Thanks again for your patience, and sorry for the inconvenience

Kind regards,

First off - no apologies are necessary. I truly am grateful for the product and the assistance.
I had to ask ChatGPT about 3rd party RDP extensions. Funnily enough, RDM was mentioned as one.
It also mentioned Citrix, which we do use for connecting to some client sites, and I do have installed and use occasionally when connecting to these clients.
For desktop-to-desktop support, we normally use Windows' Quick Assist or Microsoft Teams.