Crashing When Logging Out Of RDP

Does it work if you close the tab directly?

Yes that works fine as well. When i goto start-logoff is when it hangs

What remote Windows is it?

Server 2003 and 2008 R2, doesnt seem to matter. I will add it was working great for a while and stopped.

Could you try it with RDM 64 bit just for a test.

That seems to work.

Hi,
we have just the same problem on one client with RDM 9.1.0.0 installed.
best regards

Reloaded my PC the other day, worked for about a week and now back to the same thing. I had switched to the 64 bit as well.

This is really strange. Perhaps it's related to a Windows update.

This is happening to me as well. I've done a fresh install of Windows 8.1 Enterprise multiple times, and it works great for a couple days.

I have about 400 connections I work with, and all are Windows Server 2008 R2 and Windows Server 2012 R2. Closing the tabs is no problem if I want to leave the session open, but the second I "properly" logoff a machine, that's when it hangs.

I've noticed that RDP to Server 2012 sessions are absolute memory hogs. They take up like 300MB of RAM...what's up with that? Something in the RDP Protocol itself? Anyhow, this has been absolutely horrible for me. When it happens, I usually find myself reconnecting to at least 10 or so RDP Embedded sessions.

I'm happy to debug or provide any form of logging to help get this fixed.

Hi
You're right and RDP 8 use a lot of memory. This could explain why you get some problem with the 32 bit version of RDM. You could expand the memory usage:

http://help.remotedesktopmanager.com/troubleshooting_largememoryawa.htm

You can also reduce memory usage by setting the default RDP Cache to "Thin client" or "Small cache". You can control this at each individual RDP session or system wide (File -> Options -> Types -> RDP)

http://help.remotedesktopmanager.com/index.html?file_options_sessiontype_rdp.htm

What are the implications of using Thin or Small cache over full? The link doesn't say.

Hi,
You can find the definition here:

http://msdn.microsoft.com/en-us/library/jj152030(v=vs.85).aspx

Well, I switched to the x64 client, and then also setup Thin Client. I just closed out of 1 of only 8 RDP Sessions opened, and sure enough, full lock-up.

I honestly thought it was my machine, but as it happens on 2 different machines of mine at this point, and there are other posts about it, I am starting to think it's an RDM issue.

I use other RDP Management tools that do not seem to have the same issue (Granted they SUCK compared to RDM :) )

Were you closing an Windows 2012 R2 connection? Did you have a gateway opened? Does it happen when you only have one connection to you logoff?

We really need to find a pattern to reproduce it.

No Gateway. It can be any OS. 2008 R2, 2012, 2012 R2. I'm using the standard Windows logoff method.

I can tell you that for sure it seems to be most prominent when there are multiple connections opened. Also, I'm 100% remote to all these devices, and I access them over SSL VPN Tunnels in all my datacenters.

I am happy to setup any debugging you need and run it indefinitely so we can get some data to work with if it will help.

Here is an email that I've got from a user last week:

--------------
I then tried tethering my laptop to my phone so I could bypass the corporate proxy, and server 2012 sessions exited gracefully.

My suspicion here is that because I am using a HTTP proxy which is TCP only, the mstsc client is trying to make a UDP connection outbound for some reason when the session terminates therefore fails (even though I didn't have it opened in firewall anyway, so I would have expected this symptom regardless of proxy but ??). I ultimately feel this is a bug in the MSTSC client, because I would imagine it detects availability of that UDP port when a session is started, and knows it's not there, but for some reason on disconnect wants to hit it anyway to terminate the session...

Hi,
I've found this topic also:

http://itknowledgeexchange.techtarget.com/vista-enterprise-desktop/more-windows-8-weirdness-fixing-flaky-rdp/

So I'm not entirely sure how this applies, though I could be wrong. I really don't have any sort of proxy scenario myself.

So for starters, I wasn't aware that the MSTSC client even used UDP. It's supposed to be 100% TCP driven. Even then, if it did use UDP for some weird end of session mechanism, I have no restrictions of any kind over my SSL VPNs on the profiles I use. That is interesting though.

One of the things I was thinking was that it could have something to do with the Datasources. I actually stopped using SQL 2012 and switched back to XML because I could put my XML in my Google Drive folders on all my machines and ensure all my profiles stayed 100% in sync so that whether I was in my datacenter, or on my laptop or desktop, I had real time access to the most current profiles. Anyhow, I'm not sure if the profiles have any play in this, but I felt it was worth laying out there.

Wow, that's a pretty cool article. Obviously there is some UDP functionality after all. Still, this issue is different. I have zero connection issues. Running the x64 RDM I can launch about 30 or so RDP sessions and they chug along just fine. The problem is simply a logoff. It locks up the RDM Client in both x86 and x64 versions.

Is there no debug tracing that we can just let run for a few hours/days/weeks? Without raw data, it's pure speculation on my end. It's to the point for me where I have to restart RDM at least 2-3 times in a 10 hour work day.

Could you try the classic UI just to elimitate any UI Framework issue?

Absolutely. I'll run that for a while. Thanks for all the help on this!

EDIT: Wow...what a difference in the look. I forgot what this looked like!
edited by jimcjulsonjr on 3/28/2014

What Anti-Virus do you use?

I don't use one on either machine.

FYI...

Full 24 hours or so with no issues running in the Classic UI. In fact, the speed is just outstanding. It's a definite trade-off for the nice plush look, but man is it so much faster! Lets see if I can keep it from crashing.

Keep me posted. If it still work with the classic UI, I will send you our internal build with RDM 9.5. The UI Framework is updated and we use .NET 4.0

Definitely will do. I'm getting spoiled from the speed of the Classic UI now :)

So is the existing and modern UI actually using .NET 2.0? I've never actually noticed that!

What is faster exactly?

The first thing I noticed was simply launching RDP sessions. They are night and day better. The modern UI can take an average of right around 2-4 seconds depending on the total number of RDP Sessions I opened existing. Also, when I open an entire group of like 10 servers up, they all connect lightening fast.

So, in the interest of noting that my system isn't likely the issue (as it also happens on other machines) my primary system has the following specs :

Intel Core i7 Extreme 950 @ 3.4Ghz
16GB of RAM
SATA 6Gbps SSD

Basically, my system is pretty high end so performance shouldn't be a factor .

I hope none of what I'm saying comes across as negative about the product. Couldn't be happier with RDM Enterprise. Got my whole company hooked on it :)

Don't worry. I was asking to know exactly where I could profile and speed up the performance in the Modern UI.

Another thing I noticed is anything to do with editing an existing entry. It's not "slow" per say, but it's not fast either. In the Modern UI, there's just enough lag when editing the properties of a given entry, it will delay before coming up. In the Classic, it's instant no matter what I have opened up.

Still going strong. Not 1 crash since switching to the Classic UI. It's been just over 2 days at this point.

I worked on this last week end and I've made some small tweak that could help. We will see in the next build if we could be as stable as the classic UI.

Hi

Not sure where this got to but thought I would add my 5 cents worth. I have never had any issue with RDM until I moved to Win 8.1 ent about two weeks ago. Clean install fully patched. I then found that my remote sessions would crash every time I logged off. Strangely I found this only happened when logging off Server 2012 or 2012R2 sessions. Anything earlier than that was OK.

I have tried every suggestion in this thread but nothing worked for me. Also tried disabling UDP via registry hack and installing the latest beta version of RDM with no change in behaviour.

I then started to look at the RDP settings for the 2012 and 2012R2 connections. I worked my way through every setting and have found that unticking "Load Plug-ins in embedded mode" on the "Experience" tab seems to have resolved the issue. I'm not sure how that option works but found that if I opened a 2012 session in an external window I could log off without problem so the problem seems to be related to embedded sessions.

Hi David,
Do you load any plugin like thin print or another one?

I may have the same issue (from another forum thread). Wonder if they may be related?

So since the last update, I've been running in the new modern UI with absolutely zero problems. No more crashes or hangs when logging off of Server 2012 or 2012 R2 sessions.

No we don't have any plug-ins.

I used RDM all day yesterday without any crash so it seems to be working. Thought I would have a bit more of a look around today and found that one of the dll's that are listed in the crash is called tsftp.dll. I found that file sitting in "users\username\appdata\roaming\rdp6". This directory is created by a terminal server alternative called TS Plus for its own custom RDP connector. We have used this a few times for testing and a couple of clients use it. I deleted the directory as it is recreated on the fly when you run the TS Plus RDP connector. I reticked the "load plug-ins embedded" option and can log off with out issue now. It seems that somehow that dll, which I assume is the TS Plus universal printing job transfer enabler is somehow picked up when making a connection and causes the crash when disconnecting but only on server 2012.

I will keep testing but looks like that was the culprit all along.