Remote Desktop Manager crashes often when used in conjunction with UltraVNC

Remote Desktop Manager crashes often when used in conjunction with UltraVNC

avatar

When using RDM along with UltraVNC (with encryption enabled in case that matters) I've been finding that RDM crashes very often. It will often lock up and require killing the app with Task Manager when either closing a tab using UVNC, and/or when UVNC disconnects for any reason (the remote system it's connected to is shutting down, the user is logging off of the remote system, etc). This doesn't happen every time, but it does happen every 4-6 times a machine is connected to and disconnected for any reason.

I'm using the latest versions of UVNC and RDM available (UVNC 1.4.3.6 and RDM 2025.1.30.0), however this has been a problem for quite a while, so it's not a new bug.

If I were to guess, I'd say RDM is hanging up waiting for some sort of response from the UVNC client, leaving RDM waiting forever until the process is killed.

All Comments (22)

avatar

Hello,

Thank you for reaching out to us regarding this,

Are there any logs regarding this crash under "Help" -> "Application Logs" or perhaps directly in your Window Events Viewer?

Could you test with a portable instance of RDM to see if you encounter the same problem?
https://docs.devolutions.net/rdm/kb/how-to-articles/portable-rdm-installation/

Best regards,

Samuel Dery

avatar

Hello

Further to what my colleague wrote, it's interesting that you say this has been occurring for some time because we recently updated the UltraVNC integration and I had wondered if it was related.

This is something we can look into.

However, to be frank, the UltraVNC integration inside RDM is pretty much on life support at this point. It's not an official integration and is incredibly hard to maintain and fix bugs inside. If possible, I'd like instead to steer you towards our first-party VNC client freevnc. Have you tried freevnc for embedded VNC sessions? If there's an issue or feature gap that prevents you from using it, I would be very interested to hear it as we would prefer to close such things (where we have much greater control) than invest that energy into UltraVNC.

(I'll add a disclaimer that we're also working on integrating our next generation VNC client, ironvnc, inside RDM; although it doesn't quite have feature parity with freevnc yet, Notably it doesn't support DSM encryption which seems to be a use case for you).

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

Best regards,

Richard Markievicz

avatar

I'll give the built in FreeVNC client a try if that's the direction development is going! It's been a couple of years, but I don't think I knew that worked with encryption back when I initially started using RDM. I'll give it a week and report back if there's still crashes along with any logs I can get from either RDM itself or Event Viewer.

avatar

Hello

Please give it a try. Originally freevnc didn't support DSM encryption, but it does now - we added it a few years ago, so when you tried it originally it might not have been an option.

Let me know any questions or issues you have. If there's something blocking you with freevnc, we can take a deeper look at the UltraVNC problem in the meantime.

I'll wait to hear your feedback

Best regards,

Richard Markievicz

avatar

Hi there,

Been watching for a resolution on this one. But the problem still exists, I am having the same issue where after the machine is rebooted and an attempt to VNC to that machine is initiated the application crashes and requires a task manager termination to end RDM. But once RDM is restarted the connection via FreeVNC succeeds, this happens whenever the remote device is rebooted or hasn't had a remote session since a reboot.

RDM version: 2025.2.23.0 64-bit (JIT)


Edit:

Also happening on 2025.2.25.0 64-bit (JIT)

avatar

Hello

I'm sorry for the inconvenience. It's strange that the connection succeeds after restarting RDM.

When you say, "the application crashes and requires a task manager termination to end RDM" - you mean that RDM is frozen, right?

A couple of things that could help me diagnose and fix what's going on here, since I couldn't reproduce it in a quick test on my side:

  • In File > Settings > Entry Types > Sessions > Apple Remote Desktop (ARD) / VNC > Advanced
    • Check the "Enable logging for ARD and VNC" option
    • Provide a path to create a log file (e.g. C:\users\username\desktop\rdm-vnc.log)
    • Save the changes and restart RDM
  • Reproduce the issue
    • If you get a hang (not a crash), before force terminating RDM follow the instructions in this KB article to capture a core dump
    • If you get a crash (not a hang), look for the core dump created by Windows in %localappdata%\CrashDumps
  • Finally, please disable the logging again as it has a non-zero impact on performance


Now, if you could send to me the log file, the core dump (.dmp) and also the RDM application logs (Help > Application Logs) it would be helpful. Note these files may contain sensitive information so, once you have that, please let me know and I can provide a secure way for you to submit the files.

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

Kind regards,

Richard Markievicz

avatar

Hi Richard,

Thanks for the reply. I have the files will need to send securely.

Reuben

avatar

Hello reubenulan,

I’ve sent an email to your address containing a secure link for uploading the file. Kindly let us know when you will be able to send the files.

Best regards,

Carl Marien

avatar
Hello reubenulan,

I’ve sent an email to your address containing a secure link for uploading the file. Kindly let us know when you will be able to send the files.

Best regards,


@Carl Marien
Hi Carl,

Files uploaded.

Reuben

avatar

Hello

Thanks for sending that through. This definitely looks like a bug on our side, but I don't quite have all the information I need to address it.

Can you let me know the server environment for one of the machines where you have this issue? i.e. The server operating system, VNC server and VNC server version?

In the crash dump you sent; it looks like the connection was opened from a playlist of the "last opened connections" window you get when relaunching RDM after closing it with sessions active. Is that relevant, or is the problem simply as described in your original post regardless of how it's launched?

Thanks and kind regards,

Richard Markievicz

avatar

Hi Richard,

The connection is always initiated from a Windows machine (Win 11 Pro), the remote machines are 2x Windows machines (Win11 and Win Server 2022) don't have any issue with those using the RDP protocol and 3x Linux machines (1x Ubuntu Machine and 2x Raspbians), these Linux machines have the problem using FreeVNC.

The issue occurs from both using the side bar and the playlist from previous connections when RDM was shutdown with active connections.

Reuben

avatar

Hello

On the Linux/Raspi machines, what's the VNC server you use? And the version? Or is it different between the machines?

Thanks and kind regards,

Richard Markievicz

avatar

The Linux machines are using RealVNC, server version 7.13.1.37.

Reuben

avatar

Hi Reuben

Thanks for the info. Can you confirm that you get this problem on both your Ubuntu and Raspberry Pis?

The reason I ask: I can't reproduce the issue with any of my similar environments; I installed RealVNC 7.x on an Ubuntu machine and couldn't reproduce it there either. However the log files you sent through seem to show WayVNC as the server; which would make sense on a recent Raspian version as they now use Wayland and WayVNC as the default VNC server.

I'm trying to narrow the issue down...

Thanks and kind regards,

Richard Markievicz

avatar

Ok, found the wayVNC version the raspian uses: 0.9.1-1

EDIT:

I've just tested with just the Ubuntu and that doesn't seem to have the issue. Just the raspians, had to not use the playlist to check, but can confirm that it's just the wayVNC's that hangs RDM on first session.

Reuben

avatar

I'm the OP. I just wanted to post an update that my issue was resolved by switching the VNC viewer to the built in FreeVNC client. Still using UltraVNC as the server.

avatar
I'm the OP. I just wanted to post an update that my issue was resolved by switching the VNC viewer to the built in FreeVNC client. Still using UltraVNC as the server.


@thesmj

Good you found a resolution, apologies for the hijack.

Reuben

avatar

Hello

@thesmj Thanks for letting us know! I'm glad it's working well for you

@reuben Ok, thanks a lot for confirmation.

I want to let you know that I am working on this, but currently stalled on reproducing the issue. I suspect it's something specific about WayVNC; we've had some other bugs exposed by WayVNC in the past, once I can recreate the problem I expect it will be an easy fix. The problem has been setting up an equivalent environment for testing, but we are working on that.

Thanks a lot for your patience

Kind regards,

Richard Markievicz

avatar

Hi Richard,

Thanks for the update.

So I've been testing this and spun up additional pi cm5's using WayVNC.

Each of them have been added to the same VLAN and can ping each other as well as the Windows machine running RDM.

Using RealVNC on the Windows machine upon initial session after a cm5 reboot, the connection works. Using RDM, the connection hangs and eventually crashes RDM for every pi cm5, but after restarting RDM, re-initiating the session succeeds.

Reuben

avatar

Hi Reuben

Thanks for the update. I've found the bug here and a fix will be forthcoming. I'll let you know once it's ready.

Sorry for the inconvenience. This is because of the WayVNC sends screen size changes. The VNC/RFB spec actually doesn't define that well, so what they are doing is not incorrect, just something I hadn't seen before.

Kind regards,

Richard Markievicz

avatar

Thanks Richard, much appreciated.

avatar

Hello Reuben

Thanks for your patience. This should be resolved in RDM 2025.2.28. Once that's released (it shouldn't be very long) and you've updated, please let me know if you experience further issues or have more comments or questions.

Kind regards,

Richard Markievicz