RDM macOS Freezes When Copying Content from RDP Sessions

Hello

That sounds strange. Would you mind enabling session logs (described here); then when the issue occurs next time you can send me the log either by PM (as a zipped attachment) or to service@devolutions.net (mention this thread in the message). Afterwards you can turn the session logs back off again. Once you send it I will take a look.

Thanks and kind regards,

Hello

That sounds strange. Would you mind enabling session logs (described here); then when the issue occurs next time you can send me the log either by PM (as a zipped attachment) or to service@devolutions.net (mention this thread in the message). Afterwards you can turn the session logs back off again. Once you send it I will take a look.

Thanks and kind regards,

@Richard Markiewicz
Please find the zip attachment. Thank you!

Hello

Thanks for that, there's a clear issue here but I'm not sure the precise cause yet.

Can you confirm - this happens in the case you copy a file or folder on the local (macOS) system, right?

Kind regards,

Hi,

This issue primarily occurs when copying text within the RDP session. When copying text from a file, the macOS spinning wheel appears, causing the entire application to freeze temporarily.

Hello

Something strange is going on here. I found precisely in your logs where the freeze happens.

For background, you need to understand how the RDP clipboard works. When you copy something on the server, the server tells the client "here is the types of data I have in my clipboard". It doesn't send the actual data, that would be too heavy for every copy that might not need a corresponding paste on the client side. So, now the client knows what kinds of data are in the clipboard but doesn't have the actual data yet. Now, on client side, if you paste somewhere, the system picks the most suitable type of data that's advertised on the clipboard, and only now do we ask the server "send us the data for that type!". Ok, so now the client needs to wait for the server to actually send the data. At this point we must block the UI thread because macOS pasteboard has to happen on the main thread. We wait for the data - usually pretty quick, can be slow depending on what the server does or what the data is; but we have a maximum wait of 30 seconds in our code.

When I see the freeze case in your log, here is what I see:

18:33:39:290 - Server announces unicode text available on the clipboard
18:33:39:322 - macOS side requests the text data
18:34:09:327 - 30 seconds past; the server never sent the data. macOS side immediately request the data again
18:34:39:375 - 30 seconds past; the server never sent the data. macOS side immediately request the data again
18:35:09:405 - 30 seconds past; now all three queued responses arrive in a burst
18:35:10:459 - second and third responses arrive

Do you see why it's strange from the timestamp? You copied on the server, but then the client asked for the data 30ms later. I can't believe you switched back to macOS and initiated a paste in just 30ms! So, something running on your Mac is proactively reading new data from the clipboard as soon as it's copied. Furthermore, if it's not available, it retries two more times. I can't say what that might be - perhaps a clipboard monitor/history application or maybe something else that does clipboard virtualization like VMWare, something like that? Note that this same pattern is happening in the cases you copy on the server and it doesn't freeze - it's just that the server is providing the data very quickly. Every time you copy in RDP, something on your Mac immediately tries to read the clipboard within 15-30 milliseconds.

So the next part of the problem is, why is it taking so long to get the data in the freezing case? In this case that's on the server - it's just not answering in a timely way, although the data does eventually arrive. What are the application(s) you are copying from? Are you copying really big chunks of data, perhaps with images and other heavy content? Are the files in question sitting on slow I/O (network drive, maybe)?

In summary: something on your local machine is aggressively trying to read all the data that gets put into the clipboard. If the RDP server cannot serve that data quickly enough (30 seconds timeout), whatever that is retries a further 2 times, causing an additional 60 seconds timeout. In those timeout periods we're frozen, but it's unavoidable because clipboard interaction is UI thread bound.

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

Hello again

One thing occurred to me: this could be related to the Universal Clipboard feature in macOS. You said it's a new setup - maybe you didn't have that enabled before, and you do now?

It's in (System) Settings > General > Airdrop and Continuity > Continuity.> "Allow Handoff between this Mac and your iCloud devices".

If you have it enabled, please try turning it off and tell me if the issue persists. If it works around the problem, we might be able to fix that on our side. Note that without that, we could still hang for up to 30 seconds if the server can't deliver the clipboard data in a timely fashion, but that would only be when you actually paste the information on the client.

Let me know if you have some questions

Kind regards,

Hi Richard,

Thank you for your deep analysis of the logs, I have tried disabling the "Allow Handoff between this Mac and your iCloud devices" option and the issue still persists.

I can confirm that clipboard data is being read immediately on the macOS side without user paste interaction. I’m investigating background applications and security/virtualization agents that may be aggressively reading the pasteboard. I will share findings once the process is identified.

Hello

Yes, please share your findings because it's useful data if anyone else hits this problem.

That being said - I think we can do better here. My idea is that, if the pasteboard is ready extremely quickly after copying on the server (say, within 100ms, faster than a human could initiate a paste on the client side) we should reduce the timeout to wait for the data accordingly. We can assume that something is trying to take the pasteboard contents in an automated fashion and not wait the full 30 seconds; maybe just half a second or so. There would still be a short freeze but it would be much more usable. What do you think?

Kind regards,