Hang on closing RDP session

avatar

Hi there,

I've been seeing an issue for the last several months where sometimes when closing an RDP session by clicking the X icon next to the session name RDM will completely hang requiring the process be killed to recover. A simple wait chain analysis via Resource Monitor (attached) seems to indicate that two threads in RDM are the culprit. Both threads seem to be calling functions inside mstscax.dll which does make sense in context. In particular, one thread seems to be hanging on mstscax!PAL_System_SingleCondWait. I have a minidump and full dump of the RDM process (64-bit) when the issue occurs which I'm happy to upload to an appropriate location if this assists in the troubleshooting. I'm currently running RDM v9.2.5.0, though have updated several times in the past hoping this issue would be resolved in a future update. The few newer versions released since I last updated don't appear to have any changes in them relevant to this issue. If there's any further information I can provide to assist please let me know!


Cheers,
-SDL

Analyze Wait Chain.PNG

All Comments (42)

avatar

Hi,
Thank you very much for the dump. It seems to be a race condition issue. I might have an idea on how we could resolve this but this is not an easy one.

David Hervieux

avatar

Thanks David! It's pretty frustrating when it happens as it completely hangs RDM so the only recourse is to kill the whole process. On the plus side, RDM's restore state feature helps a fair bit with getting back to where I was.

Let me know if you need me to upload the mini or full dump somewhere (just private message me with an FTP or Dropbox link or similar).

avatar

Hi David,

Just wanted to check-in to understand what the plan is wrt. this issue? Is a fix being developed for inclusion in a future release and is there any timeframe? It's a pretty frustrating issue and so I'm admittedly eager to get it resolved.


Cheers,
-SDL

avatar

We recently found with another user an issue similar with external RDP plugin. Could you try to uncheck the Load plugin in embedded mode located in the Experience tab.

David Hervieux

avatar

This sounds similar to an issue we are seeing. Sometimes when logging out of a RDP session the tab will stay open, even though we have successfully logged out of the server. the tab cannot be closed by clicking the "X". Sometimes this will cause RDM to hang and require the process to be killed manually.

avatar

Just adding that I've yet to see the issue again since setting all of my RDP connections to "Load plug-ins in embedded mode". I wouldn't say I'm 100% certain that the issue is resolved yet, but signs are definitely positive, which is great!

Just thought I might add as well in case it's relevant that in all cases I'm running on Windows 7 SP1 x64 (fully patched) with the RDP 8.1 update (KB2923545); Remote Desktop Connection client is subsequently v6.3.9600.

avatar

Unfortunately I'm still seeing the issue even with the suggested configuration change. Curiously, I seem to see the issue far more when I'm on a certain network, but I suspect the real case is that on said network I'm often accessing other systems over RDP via a VPN. Perhaps this scenario is particularly conducive to manifesting the issue due to timing issues? At any rate, the problem definitely still exists. Can we get an update on what's next as far as a fix is concerned?

Thanks in advance!

avatar

Sorry to pester but this is really becoming a huge pain. I also noticed yesterday that the problem definitely also occurs even when disconnecting from systems that are not being accessed over a VPN. Just now I had RDM freeze while closing an RDP session to a system on the local network.

avatar

Hi,
Do you have any RDP pluging installed like ThinPrint? Do you use the latest beta? The test you could try is to switch to Classic UI to see if it could be related to our UI.

David Hervieux

avatar

Hi David,

No, nothing like ThinPrint installed, and I can't think of anything else that would qualify as an RDP plugin that's on my system.

I'm not using the latest beta, currently still on v9.2.5.0; I'm happy to upgrade, but only if you think there's an actual chance it would fix anything? You have quite a rapid release schedule (which is great!) so keeping up-to-date is a lot of effort (and I was running very close to the latest version when I opened this thread).

Funnily enough, I actually already am using the Classic UI. I swapped to it at someone's suggestion on the forum a while ago while resolving a separate issue and must never have swapped back. Is there any data I can send you to assist with getting this resolved? I'm happy to send crash dumps or other data for detailed analysis of the thread that seems to cause the issue if it is helpful.


Regards,
-SDL

avatar

Hi,
We have one possible fix in the latest beta and it was related to the focus. Perhaps caused an hang. I think it could be good to install the latest beta.

David Hervieux

avatar

Hi David,

I've downloaded and installed RDM v9.4.9.0 which I believe is the latest beta? Will let you know how it goes.


Cheers,
-SDL

avatar

Incidentally, having updated to the beta, I thought I'd revert back to the Modern UI (as it is much nicer) and immediately started experiencing my old issue again as documented in the thread: http://forum.devolutions.net/messages.aspx?TopicID=2457

I really love RDM as it's ridiculously powerful and feature-rich, but these two issues are a huge bugbear, so if we could get to the bottom of these it would be much appreciated. Again, I'm more than happy to assist with providing whatever debug or diagnostic data is required.

For now, I've reverted back to the Classic UI (from v7.x!).
edited by sdl on 7/9/2014

avatar

Just for a test, could you try RDM on another machine to see if this happen as well? I would like to find a pattern because we are unable to reproduce it.

David Hervieux

avatar

Which issue in particular? In either case, both documented issues happen on my desktop and laptop system. They both run Windows 7 x64 SP1 (w/ all the latest updates from Microsoft Update). They have similar but not identical software installed (and of course, the hardware is completely different, and so the installed drivers are as well).

avatar

Thank you. I will continue to search for a pattern.

David Hervieux

avatar

Hi David,

Unfortunately I've now seemingly got a bigger problem. I updated to the v9.4.9.0 beta as suggested, which went fine on my desktop (and also entailed a database update, which also seemed to work fine), however, I've now updated it on my laptop to the same version but can't connect to the data source. I can run the "Test Server" and "Test Database" functions against it without issue (both return success) but on actually trying to connect I receive an "Error message dialogue" reporting that the "file is encrypted or is not a database" with a .NET exception in the Details section. I've already submitted the error report with my email address (the same as my forum profile).

Can you advise? This is obviously a much larger issue as I do rely on RDM for working on numerous networks both on-site and remotely.

The actual .NET exception stack trace:
SQLiteException - file is encrypted or is not a database
file is encrypted or is not a database

at System.Data.SQLite.SQLite3.Prepare(SQLiteConnection cnn, String strSql, SQLiteStatement previous, UInt32 timeoutMS, String& strRemain)
at System.Data.SQLite.SQLiteCommand.BuildNextCommand()
at System.Data.SQLite.SQLiteDataReader.NextResult()
at System.Data.SQLite.SQLiteDataReader..ctor(SQLiteCommand cmd, CommandBehavior behave)
at System.Data.SQLite.SQLiteCommand.ExecuteReader(CommandBehavior behavior)
at System.Data.SQLite.SQLiteCommand.ExecuteScalar(CommandBehavior behavior)
at Devolutions.RemoteDesktopManager.Business.SQLiteHelper.ExecuteScalar[T](String connectionString, String sql, SQLiteParameter[] parameters, Boolean rethrow)
at Devolutions.RemoteDesktopManager.Managers.OfflineManager.ExecuteScalar[T](BaseConnectionDataSource dataSource, String connectionString, String sql, SQLiteParameter[] parameters, Boolean rethrow)
at Devolutions.RemoteDesktopManager.Managers.OfflineManager.Upgrade(BaseConnectionDataSource dataSource)
at Devolutions.RemoteDesktopManager.Managers.OfflineManager.Initialize(BaseConnectionDataSource dataSource, Boolean force)
at Devolutions.RemoteDesktopManager.Managers.OfflineManager.GetDataSourceSettings(BaseConnectionDataSource dataSource)
at Devolutions.RemoteDesktopManager.Managers.ConnectionManager.PreLoadFromOffline(BaseConnectionDataSource connectionDataSource)
at Devolutions.RemoteDesktopManager.Managers.ConnectionManager.LoadConnections(BaseConnectionDataSource connectionDataSource)
at Devolutions.RemoteDesktopManager.Managers.ConnectionManager.RefreshConnections()
at Devolutions.RemoteDesktopManager.Forms.FrmMainBase.RefreshAllConnectionView(Boolean saveState, Boolean checkOnline)
at Devolutions.RemoteDesktopManager.Forms.FrmMainBase.RefreshView(Boolean checkOnline)
at Devolutions.RemoteDesktopManager.Managers.ConnectionManager.set_DataSource(BaseConnectionDataSource value)
at Devolutions.RemoteDesktopManager.Frames.FreConnectionDataSource.cbDataSources_EditValueChanged(Object sender, EventArgs e)
at DevExpress.XtraEditors.TextEdit.OnEditValueChanged()
at DevExpress.XtraEditors.PopupBaseAutoSearchEdit.OnEditValueChanged()
at DevExpress.XtraEditors.BaseEdit.OnEditValueChanging(ChangingEventArgs e)
at DevExpress.XtraEditors.ComboBoxEdit.set_EditValue(Object value)
at Devolutions.RemoteDesktopManager.Frames.FreConnectionDataSource.RefreshDataSources()
at Devolutions.RemoteDesktopManager.Managers.ActionManager.EditDataSource()
at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

I'm not entirely sure if the SQLite references are symptomatic of a deeper problem or normal as the data source is a Microsoft SQL Server database.


Thanks,
-SDL

avatar

Hi,
I missed a part in the stack trace. It seems to be incompatible with the offline file. Could you install the application in another folder like C:\RDM to make sure that there is no old files left. You could also delete the offline file located in %LocalAppData%\Devolutions\RemoteDesktopManager

David Hervieux

avatar

Yep, perfect. Deleting the old offline database cache seems to have done it. Presumably it only updates on the system that performs the initial database update. I suspect this is a bug that needs to be corrected in a later beta release?

Now just two issues to go! :)

avatar

Ok,
I have a test for you. Could you switch back to the ribbon UI BUT select menu only. I want to see if it's the ribbon that steal the focus.

David Hervieux

avatar

Unfortunately, the issue is still present when using the "Default (Menu)" UI.

A few extra points wrt. the focus loss (I think I've posted these before but I'll reiterate anyway just to be sure):
When the issue occurs, typically several times a minute, the focus will temporarily be lost with whichever window is directly behind RDM gaining the active focus. The window won't actually "raise" itself so it becomes visible (in the case of RDM being maximised, which it effectively always is in my use case), so you don't see any visible difference in most cases. The focus shift only lasts around a second, but obviously that's hugely disruptive when typing or if you happen to click during that focus shift. Of course, whatever key presses or mouse clicks are "captured" by the application that temporarily gains focus will be interpreted as normal by whichever application received the focus, so you then may have to "undo" these undesired changes. The issue is severe enough that it makes using RDM effectively impossible.

One thing I just thought of that might be related, especially if you're trying to reproduce what I'm seeing, is I just realised that my configuration is perhaps a bit unusual in that I use the "Xmouse" functionality of Windows. You can find more details here: http://en.wikipedia.org/wiki/Xmouse

In my configuration, I have the focus follow my mouse pointer (whichever window is underneath the mouse has the focus) with a 250ms activation delay (the window will only gain focus after my mouse pointer has been in the region for at least 250ms). Further, I also have window "raising" disabled; this means that in the case of windows that aren't maximised, when a window gains focus, it won't bring itself to the front of other windows (ie. it may be overlapped by other windows, while still having the active focus). Clicking on the window will however raise the window, and I see this with RDM, where if I click during the "focus loss" interval the window behind it will raise itself. If this happens, then apart from undoing any potential action that may have occurred in the window as a result of it receiving the mouse click, you also have to restore the RDM window (via Alt+Tab, the Taskbar, etc...).

If you wish to use the exact Xmouse settings I'm using, the following Registry settings can be used. They should be inserted under HKCU\Control Panel\Desktop:
ActiveWndTrkTimeout: 0xfa (REG_DWORD) [This results in a 250ms activation timeout]
UserPreferencesMask:
This one is a bit tricky. You need to perform a logical OR on the first byte of the existing REG_BINARY value. In my case, this means the first byte is 9f. If you have 9e, then 9f is what you want. If you have some other value, you'll want to perform a logical OR on the existing value and then set the first byte to the result to ensure whatever settings you have that are different from mine apart from Xmouse are preserved. The Windows Calculator in hex mode may be of assistance here.

A logoff will be required for the settings to take effect. Or just reboot, whatever's easiest. That should be it, though, there's plenty of documentation on these settings around the web. Hope it helps.
edited by sdl on 7/14/2014

avatar

Hi,
I will verify if I can reproduce it with this mode but I'm not sure I can find a fix if it's the case. We are dependent of a third party.

David Hervieux

avatar

Hi David,

Sorry for slow response; I'm on holiday at the moment. Not sure what you mean re: "dependent of a third party"?

avatar

We use a component created by another company to have ribbons. This means that we don't have the source code.

David Hervieux

avatar

The issue with RDM hanging on closing RDP sessions is still present in Beta v9.4.9.0.

avatar





I'm having the same issue a few times a week.

When it happens it would be nice if you opened my tabs back up in the last display order...

avatar

Is there any update wrt. this? I just renewed my maintenance for another year and it'd be nice if some of the issues I have reported got fixed.

avatar

bump...

we have same problems here,

today i didn't close the rdp-session after click restart server, so rdm locked up when rdp-session ended -> it's very annoying.

Kind Regards
Markus

======================

avatar

I'm not 100% sure, but it seems to help if I change tabs right after logging off the machine. I've been doing that for a few weeks and it has only locked up a couple times when I forgot to switch.

avatar

Going to add a bump as well.

What can we setup to capture the error condition? I live inside RDM, so I'm quite vested in finding something that works. RDM seems to lockup at the worst possible times. :)

Not a lot of information on the net to compare to.

Thanks.

avatar

We haven't found a pattern yet. This is really a tricky one but we are still investigating.

David Hervieux

avatar

Just a quick question for everybody. Is it only when you close a session or logoff a session?

David Hervieux

avatar

I rarely close a session, so I may not be a complete answer. Every time it has happened to me it was a logoff.

avatar

For me, it's logoff on RDP sessions.

The hang occurs after the RDP session is logged off, but before the tab has closed. If the tab doesn't close within 5 seconds, I know RDM is toast.

avatar








Ditto for me!

avatar

This is still happening in 10.0.4.0

avatar

I too am experiencing this problem (locking up RDM after logging off a RDP session), I didn't seem to have it prior to installing 10.0.4.0. I also am getting "Because of a protocol error, this session will be disconnected. Please try connecting to the remote computer again."

If I close RDM I am usually then able to connect to the remote computer.

avatar

@dwaldrop Could you try the beta version?

David Hervieux

avatar

Yes, how do I get it?

avatar

@dwaldrop

You can download the latest beta version here:
http://remotedesktopmanager.com/Home/Download#beta

Best regards,

Jeff Dagenais

avatar

David Hervieux

avatar

Disabling UDP seems to have fixed the issue. Thanks!!