Forum / Remote Desktop Manager Mac - Support

Slow & Random Issues

  • Create an Issue
  • Cancel

Hello,

We are having an issue with the Ribbon and Classic UI which the performance is slow. The issue is that the program randomly lags for seconds at a time. The Classic UI has increased the performance by a good bit but we are still having issues. We are using MySQL for our database storage which is on a Dedicated Server with 500 MB down and up. The internet on our local machines where the issue arises is 300 down and 10 up.

The other issue we're running into is that we are unable to remote into Windows Server 2008 machines. Log provided below.

image


[09:01:53:990] [49125:027a5000] [INFO][com.freerdp.client.mac] -[MRDPIPCClient initLoggingWithFilter:filePath:fileName:] 124 - Log initialized headless
[09:01:53:991] [49125:027a5000] [DEBUG][com.freerdp.client.mac] -[MRDPIPCClient configureInternal] 97 - configureInternal
[09:01:53:124] [49125:028ab000] [INFO][com.freerdp.client.common.cmdline] freerdp_client_load_static_channel_addin 2492 - loading channel rdpdr
[09:01:53:124] [49125:028ab000] [INFO][com.freerdp.client.common.cmdline] freerdp_client_load_static_channel_addin 2492 - loading channel rdpsnd
[09:01:53:124] [49125:028ab000] [DEBUG][com.freerdp.channels.cliprdr.client] cliprdr_VirtualChannelEntry 1365 - VirtualChannelEntry
[09:01:53:124] [49125:028ab000] [INFO][com.freerdp.client.common.cmdline] freerdp_client_load_static_channel_addin 2492 - loading channel cliprdr
[09:01:53:125] [49125:028ab000] [DEBUG][com.freerdp.core.nego] nego_set_negotiation_enabled 1193 - Enabling security layer negotiation: TRUE
[09:01:53:125] [49125:028ab000] [DEBUG][com.freerdp.core.nego] nego_set_restricted_admin_mode_required 1205 - Enabling restricted admin mode: FALSE
[09:01:53:125] [49125:028ab000] [DEBUG][com.freerdp.core.nego] nego_enable_rdp 1227 - Enabling RDP security: TRUE
[09:01:53:125] [49125:028ab000] [DEBUG][com.freerdp.core.nego] nego_enable_tls 1239 - Enabling TLS security: FALSE
[09:01:53:125] [49125:028ab000] [DEBUG][com.freerdp.core.nego] nego_enable_nla 1251 - Enabling NLA security: FALSE
[09:01:53:125] [49125:028ab000] [DEBUG][com.freerdp.core.nego] nego_enable_ext 1263 - Enabling NLA extended security: FALSE
[09:01:53:125] [49125:028ab000] [DEBUG][com.freerdp.core.nego] nego_connect 154 - state: NEGO_STATE_RDP
[09:01:53:125] [49125:028ab000] [DEBUG][com.freerdp.core.nego] nego_attempt_rdp 506 - Attempting RDP security
[09:01:53:361] [49125:028ab000] [DEBUG][com.freerdp.client.mac] -[MRDPIPCClient validateX509Certificate:] 577 - validateX509Certificate
[09:01:53:389] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rdg] rdg_process_out_channel_response 355 - Out Channel authorization required
[09:01:53:418] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_virtual_connection_transition_to_state 700 - VIRTUAL_CONNECTION_STATE_INITIAL
[09:01:53:510] [49125:028ab000] [DEBUG][com.freerdp.client.mac] -[MRDPIPCClient validateX509Certificate:] 577 - validateX509Certificate
[09:01:54:512] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_in_channel_transition_to_state 420 - CLIENT_IN_CHANNEL_STATE_CONNECTED
[09:01:54:512] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_in_channel_transition_to_state 420 - CLIENT_IN_CHANNEL_STATE_SECURITY
[09:01:54:612] [49125:028ab000] [DEBUG][com.freerdp.client.mac] -[MRDPIPCClient validateX509Certificate:] 577 - validateX509Certificate
[09:01:54:615] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_out_channel_transition_to_state 566 - CLIENT_OUT_CHANNEL_STATE_CONNECTED
[09:01:54:615] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_out_channel_transition_to_state 566 - CLIENT_OUT_CHANNEL_STATE_SECURITY
[09:01:54:615] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_in_channel_transition_to_state 420 - CLIENT_IN_CHANNEL_STATE_NEGOTIATED
[09:01:54:615] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rts] rts_send_CONN_B1_pdu 503 - Sending CONN/B1 RTS PDU
[09:01:54:615] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_in_channel_transition_to_state 420 - CLIENT_IN_CHANNEL_STATE_OPENED
[09:01:54:643] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_out_channel_transition_to_state 566 - CLIENT_OUT_CHANNEL_STATE_NEGOTIATED
[09:01:54:643] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rts] rts_send_CONN_A1_pdu 447 - Sending CONN/A1 RTS PDU
[09:01:54:643] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_out_channel_transition_to_state 566 - CLIENT_OUT_CHANNEL_STATE_OPENED
[09:01:54:643] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_virtual_connection_transition_to_state 700 - VIRTUAL_CONNECTION_STATE_OUT_CHANNEL_WAIT
[09:01:54:669] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_virtual_connection_transition_to_state 700 - VIRTUAL_CONNECTION_STATE_WAIT_A3W
[09:01:54:919] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rts] rts_recv_CONN_A3_pdu 477 - Receiving CONN/A3 RTS PDU: ConnectionTimeout: 120000
[09:01:54:919] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_virtual_connection_transition_to_state 700 - VIRTUAL_CONNECTION_STATE_WAIT_C2
[09:01:54:919] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rts] rts_recv_CONN_C2_pdu 545 - Receiving CONN/C2 RTS PDU: ConnectionTimeout: 120000 ReceiveWindowSize: 65536
[09:01:54:919] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_virtual_connection_transition_to_state 700 - VIRTUAL_CONNECTION_STATE_OPENED
[09:01:54:919] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_client_transition_to_state 173 - RPC_CLIENT_STATE_ESTABLISHED
[09:01:54:919] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_send_bind_pdu 123 - Sending Bind PDU
[09:01:54:919] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_client_transition_to_state 173 - RPC_CLIENT_STATE_WAIT_SECURE_BIND_ACK
[09:01:54:944] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_recv_bind_ack_pdu 318 - Receiving BindAck PDU
[09:01:54:944] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_send_rpc_auth_3_pdu 355 - Sending RpcAuth3 PDU
[09:01:54:944] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.rpc] rpc_client_transition_to_state 173 - RPC_CLIENT_STATE_CONTEXT_NEGOTIATED
[09:01:54:944] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.tsg] TsProxyCreateTunnelWriteRequest 190 - TsProxyCreateTunnelWriteRequest
[09:01:54:944] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.tsg] tsg_transition_to_state 1296 - TSG_STATE_INITIAL
[09:01:54:992] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.tsg] TsProxyCreateTunnelReadResponse 331 - TsProxyCreateTunnelReadResponse
[09:01:54:992] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.tsg] tsg_transition_to_state 1296 - TSG_STATE_CONNECTED
[09:01:54:992] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.tsg] TsProxyAuthorizeTunnelWriteRequest 645 - TsProxyAuthorizeTunnelWriteRequest
[09:01:54:025] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.tsg] TsProxyAuthorizeTunnelReadResponse 704 - TsProxyAuthorizeTunnelReadResponse
[09:01:54:025] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.tsg] tsg_transition_to_state 1296 - TSG_STATE_AUTHORIZED
[09:01:54:025] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.tsg] TsProxyMakeTunnelCallWriteRequest 819 - TsProxyMakeTunnelCallWriteRequest
[09:01:54:025] [49125:028ab000] [DEBUG][com.freerdp.core.gateway.tsg] TsProxyCreateChannelWriteRequest 1014 - TsProxyCreateChannelWriteRequest
[09:01:54:049] [49125:028ab000] [ERROR][com.freerdp.core.gateway.rpc] rpc_recv_fault_pdu 321 - RPC Fault PDU:
[09:01:54:049] [49125:028ab000] [ERROR][com.freerdp.core.gateway.rpc] rpc_recv_fault_pdu 328 - status: RPC_S_INVALID_TAG (0x000006C5)
[09:01:54:049] [49125:028ab000] [ERROR][com.freerdp.core.gateway.tsg] tsg_connect 1760 - tsg_check failure
[09:01:54:049] [49125:028ab000] [ERROR][com.freerdp.core.nego] nego_connect 160 - Protocol Security Negotiation Failure
[09:01:54:049] [49125:028ab000] [ERROR][com.freerdp.core] freerdp_set_last_error 698 - freerdp_set_last_error ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x2000C]
[09:01:54:050] [49125:028ab000] [ERROR][com.freerdp.core.connection] rdp_client_connect 276 - Error: protocol security negotiation or connection failure
[09:01:54:050] [49125:028ab000] [DEBUG][com.freerdp.client.mac] -[MRDPIPCClient viewDidConnect:] 415 - viewDidConnect
[09:01:55:557] [49125:8c548340] [DEBUG][com.freerdp.client.mac] -[MRDPClient invalidatePasteboardTimer]_block_invoke 176 - timer stop
[09:01:55:557] [49125:027a5000] [DEBUG][com.freerdp.client.mac] -[MRDPClient releaseResources] 156 - Failed to unmap shared memory object: Invalid argument (22)

Clock2 yrs

Hi Joey,

What is your version of RDM?

To investigate this, I'll need to know what I'm looking for. Could you describe in as much details what forms the lag takes form? Is the application freezing? The UI being unresponsive? Is it entirely random? Is it happening after clicking on something? If yes, what? After closing a window? How many sessions are opened, if any, when the lag happens? The most details you give me, the better.

As for the issue connecting to Windows 2008 server. I've been looking around for the error on your log and found and issue answered by one of my colleague a few years back. Here it is: https://forum.devolutions.net/topic16305-os-x--unable-to-establish-rdp--error-.aspx?page=1#post91499

Could you look it up and see if this applies to you. The issue seems quite similar, so is the RDP log. The thread itself is a bit confusing since there seems to be multiple issues talked about for multiple users, but the post I've linked refer to the issue at hand. If this applies, I'd ideally need the same thing that was asked by Benoit at the time. Either access to the server or as much information that can be provided to reproduce the scenario.

Best regards,

Xavier Fortin

signaturesignature

Clock2 yrs

Hello Xavier,

I am using RDM 5.0.0.0 and the lag is the Application Freezing and UI being unresponsive. I have tried using a Local Data Source, thinking that this could potentially be an issue with the connection between our MySQL Server although even my Local Data Source is responding the exact same way with the same amount of lag. It is consistent lag. It is lagging before any RDP sessions are connected.

I recorded a video of me using RDM so that you can see exactly what I am referring to. I can send the video to you, just let me know how and where to send it.

As for the thread, I took a look at that thread and before making this post I have gone through almost every post in the forums and tried every option. I am willing to have you remote into the machine with me so that you are able to look into this with me.

Please let me know which direction you want to go.

Clock2 yrs

Hi Joey,

If the file size allows it, you can send it to me directly to my email: xfortin@devolutions.net

Have you also tried the RDP Engine V5? I won't guarantee this will solve the issue, but it uses a much more recent version of FreeRDP. If it doesn't work, regenerate the RDP Log with the Engine V5 and send it to me.

Are you the one who set up this server? Or can you get in touch with the administrator? If we know how the server is configured we might be able to configure one on our side, which would make fixing the issue much easier.

As for the remote session, thanks for the offer. But as of know, I wouldn't know what I'm looking for. I'm no expert in the wide array of features and settings available through RDP servers, such as Load Balanding and TMG server (which appears to be the issue here, if I followed correctly in the previous thread). Which is why the most information you can provide, the better we can investigate this.

Best regards,

Xavier Fortin

signaturesignature

Clock2 yrs

Xavier, I have experienced declining performance in v5.0.0.0 as well. Right now it's so slow and unresponsive that I can't use it and must use Microsoft Remote Desktop instead.

V5 is much worse than V4, but V4 doesn't always connect.

In fact, when trying to connect to Azure Windows Server 2016 machines, it doesn't connect at all.

I will try to get you debug files etc., but I wanted to let you know that it got really bad in v5.0.0.0.

EDIT: Oh, and incidentally, I'm also running High Sierra 10.13.3

/Jesper

Clock2 yrs

Hi Jesper,

Your performances issue are only with Remote Desktop sessions? This is weird. Could you try disabling sandboxing and tell me if this is better?

There were changes to the Inter-process communication components in the V5, but it should have only been a technical matter and shouldn't have impacted performances. Disabling sandboxing could provide some insight.

Best regards,

Xavier Fortin

signaturesignature

Clock2 yrs

I'm not sure if I'm adding any technical data here, but I can also say that since upgrading to 5.0.0.0 my RDM console seems to freeze and generate 100% CPU on High Sierra. While this was happening I also noticed a weird 'clump, clump, clump' sound coming from my Mac very faintly - definitely not mechanical, something coming through the audio until I force quit RDM.

I have been using Microsoft Remote Desktop 8.0.27325 for the Mac whilst testing some connections through an RDS Gateway in Azure and was wondering whether it's possible to use this engine rather than the FreeRDP which you mention above? Unlike Jesper (above) I have been able to connect to Azure instances if I enable NLA in the advanced tick box.


Steve

Clock2 yrs

Hi Steve,

Your high CPU usage worries me. I'm unable to reproduce it though. Is this also an issue that appeared in RDM 5.0.0.0? Is it only when running RDP sessions?

You can always open your sessions externally which will launch Microsoft Remote Desktop app. Though we don't feed the password this way.

Best regards,

Xavier Fortin

signaturesignature

Clock2 yrs

Xavier Fortin wrote:

Your high CPU usage worries me. I'm unable to reproduce it though.

Thanks - I'll try to reproduce it myself, although I have a feeling that using Devolutions Online Drive may be adding a complication - as normally my Mac is very fast and the responsiveness of Remote Desktop Manager since the upgrade doesn't seem to match.

Clock2 yrs

2 different behaviors, but not change with Sandbox on or off:

- If using v5, it says "Unable to connect to host XXX!" although it may connect after 10-15 tries.
- If using v4, it gives a black screen (previously reported issue,) but after 3-5 tries, it finally logs on and draws the screen.

No debug file is generated in either case worth anything. Sounds like the FreeRDP stuff is faulty as Steve mentions above.

Anything else you'd like me to try?

/Jesper

Clock2 yrs

Hi Jesper,

It happens on all sessions? And (for the V5 issues) it wasn't an issue before this most recent release? We'll look into reproducing it.

I'll release a version this week that will fixes a couple of reported issues. Maybe it'll fix your issue, though this does not appear to be the exact same behavior. You could also try this one: https://www.dropbox.com/s/5ls1k6vjxgmawj1/Devolutions.RemoteDesktopManager.Mac.5.0.0.1518117124.dmg?dl=0

Though it still contains another bug that has been fixed since building it.

Best regards,

Xavier Fortin

signaturesignature

Clock2 yrs

I will try it out. Here are a few more notes on the V5 version:

- With Windows Server 2008, it connects almost every time.
- With Windows Server 2012, it connects on a third of the tries.
- With Windows Server 2016, it rarely connects.

At least with V4, I get some connects on 2016, but mostly the black screen, then close the window and try again.

/Jesper

Clock2 yrs

Xavier, I tried the build, and it actually has just a few misconnects now on Windows Server 2016. I can't comment on Joey's original post on performance, but something got fixed, that's for sure.

It still has a few misconnects as stated, but much better, so whatever you fiddled with, you are certainly going in the right direction...

/Jesper

Clock2 yrs

Hi Jesper,

This is surprising. I wasn't actually particularly optimist with this. Most of what was changed in that version were the way the security negotiation settings were set. I wouldn't have expected them to cause such an erratic behavior no matter how they were set.

Maybe fiddling with the NLA and TLS settings in the still faulty RDP sessions might help? I'd wait for the release of the 5.1.0.0 before testing this though, we still have a bug related to those settings in the version I've sent you.

Best regards,

Xavier Fortin

signaturesignature

Clock2 yrs

OK, downloaded 5.1.0.0 and it's working sort of OK, not great, but better than 5.0.0.0. You said to fiddle with NLA and TLS: Currently the settings are "Connect and don't warn me" and both NLA and TLS enabled.

Thoughts on how to "fiddle" with them?

Clock2 yrs

Hi Jesper,

Just trying different combination, though, as I mentioned, I'd find this surprising to be the issue.

There was a bug in 5.0.0.0 where the engine V5 was always attempting two combination of settings (NLA: On + TLS: Off and NLA: Off + TLS: On), and that, regardless of what was actually set in the sessions. This was what caused sessions no longer working for other users, and is pretty much the only changes related to RDP Engine V5 between the 5.0.0.0 and 5.1.0.0.

We're still struggling to reproduce the misconnect issue. Do all your sessions misconnect sometimes? Or some of them? We're still trying to isolate what could be the cause.

Best regards,

Xavier Fortin

signaturesignature

Clock2 yrs