Clipboard from Windows to Mac not reliable

Hello,

Thank you for reaching out to us regarding this,

Would you be able to attempt to reproduce the issue with the Clipboard Diagnostic tool open? Since the issue occurs inconsistently, perhaps something is interfering with the clipboard.

You can follow this knowledge base article for this:
https://docs.devolutions.net/rdm/kb/troubleshooting-articles/clipboard-diagnostic/

Let me know,

Best regards,

Hi Samuel, thanks for reply. Sorry it took me long to get back to this.

I just tried to use the Clipboard Diagnostic tool, but I'm confused about how to use it. Looking at https://docs.devolutions.net/rdm/kb/troubleshooting-articles/clipboard-diagnostic/, I'm confused by the fact that only credentials are mentioned. I just want to copy some text from Edge to another application running remotely.
How do I know what to blocklist? I don't know which applications might be interfering, if any.
I'm trying to copy something from Edge. I try to add this to AllowListed, with Description = Edge and Process name Contains Edge. When I click OK, no entry is added to AllowListed.

How should I proceed to reproduce the issue and gather more diagnostic information?

At the moment, each time I'm copying new text from my Windows PC to copy to the remote Mac, I have to restart Remote Desktop Manager and reconnect to the host. Then I copy the same text again and it gets transferred correctly. This works only once, then I have to restart RDM again. Very annoying.

Hi David

This sounds like a bug on our side. I'm going to take a look at this and see if I can find an issue, or at least come back to you with some more specific troubleshooting steps (it's not a problem that's been reported elsewhere).

Do you know if the session type you created in RDM is a regular VNC session, or ARD (Apple Remote Desktop)?

Thanks for your patience

Kind regards,

Hi Richard,

Thanks for looking into this. I use ARD for this connection. I have tried VNC once as an alternative for this particular machine, but as far as I remember this didn't solve the clipboard issue.

My current workaround is that I exit RDM each time I have new text to copy across, re-establish the connection to the Mac, copy the text from Windows and then paste on the Mac. The RDM restart seems necessary, just closing the Mac connection and starting it again is not enough.

Please let me know if I can provide any additional diagnostics to aid a solution for this.

Kind regards,
David

Hello

I've taken a good look at this and I've not been able to locate the issue. I can't reproduce on my side and from studying the code - which is quite straightforward in this case - there's no obvious bug that stands out (which, of course, doesn't mean the bug doesn't exist; just that I can't spot it).

I do understand this is a frustrating problem.

It's likely I'll have to add some extra diagnostics here to try and pinpoint exactly what's going wrong (although your detailed error report does narrow it down some of the way).

First, I have to ask - are you using any kind of third party clipboard manager or clipboard history tool? On either the Windows host or the remote Mac?

And second, just to confirm - this is a vanilla setup - i.e. you're connecting from your Windows desktop or laptop to a physical Mac located on a local or remote network? It's worth checking because we do see strange setups (even myself, will RDP into my Windows workstation and then use RDM to connect back to a macOS VM running on my local machine - that kind of loopback setup is bad for the clipboard integration).

Thanks, and kind regards

Hello Richard, thanks for delving deeper.

No, I'm not using and third-party clipboard manager or similar.

Yes, I have a vanilla setup with RDM running on my Windows desktop and a Mac Mini on my local network. RDM has an ARD connection using FreeVNC as embedded application.

Again, I'm more than happy to help to find more diagnostics as required.

Hi David

Ok, I've taken another look at this. From my side the code is quite simple. Like I wrote, your issue report helps narrow down where the issue might be, but it doesn't explain things.

I did notice a couple of places that needed improvement but I don't think those places are related to the usage you describe. We can hope however that it does fix things for you.

Other than that, I've added some log output to the different steps of the process that, if it doesn't reveal the problem, will certainly give a better clue.

Those improvements will be on the next 2025.2 release. The next beta version of 2025.2 will be 2025.2.8, probably within a week or so; otherwise the proper release of 2025.2 is slated for the first week of June. I'm sorry I can't get those changes in your hands any sooner than that.

Once you have an updated version, you can first verify that the problem still exists; and if it does:

• Go to Help > Performance Profiling
• Switch to the "Debug only" tab
• Set the "Profiler Level" to "1"
• Leaving the profiler window open, reproduce the problem
• Then send me the profiler output - either by PM on the forum, or to service@devolutions.net mentioning this forum thread

Thanks for your patience and I'm sorry for the inconvenience

Kind regards,

Hi Richard,

I'm currently on version 2025.2.13.1 64-bit (JIT). The clipboard issue still occurs initially. Then I tollowed the steps you provided.

The current situation is that the clipboard seems to work reliably when I'm using Debug Profiler Level 1. When I set Debug Profiler to Level 0, the clipboard issue returns.

The good news is that I'm at least able to work normally with the workaround in place. The bad news is that I cannot gather Profiler logs that will allow us to understand that is going on.

Is there anything I can try to get to the bottom of this?

Kind regards,
David

Hi David

Ok, that's unfortunate and frustrating. I am pleased that you're somewhat unblocked by this workaround, but I'd like to get to the bottom of it.

The fact that it works ok with the logging enabled - and that you are able to reproduce this easily, but yours is the only report I have - implies that there is a timing sensitive race condition in the code.

The way it works internally is: when you copy some data up to the server, we have to set a flag that says to ignore the next clipboard update coming from the server. Why? Because copying up to the server updates the server clipboard, which sends a change notification back to the client. If we don't ignore the next server update, we'd get stuck in a loop and the clipboard is broken.

Now, if we were to set that flag but it happened after we got the server clipboard update, it could explain things. But what I don't understand is how that would break the clipboard for subsequent connections (i.e. I'd expect a disconnect / reconnect to the server to "reset" things).

I'm going to pull on that thread a little bit and make some adjustments on our side. Unfortunately it seems like this is something we'll have to iterate over a little bit. I'll post back here once I've got a version with further changes in it. In the meantime, sorry for the inconvenience and thank you for your patience.

Kind regards,

Hello

Thanks for your patience. I've made some adjustments here that should affect the timing of clipboard operations. I can't say if it will fix the problem or not, so once 2025.2.18 is released please try again and let me know the outcome. The release tempo is a little slower in the summer months but I'd expect that to be within a couple of weeks.

In the meantime, don't hesitate with other questions or comments.

Thanks and kind regards,

Hello Richard,

Thanks for your persistence. I'm looking forward to trying out 2025.2.18 once it is released. I'll provide feedback after that.

Have a good weekend!

Kind regards,
David