Has anyone noticed or can reproduce the following scenario?

Open a RDP session from one system to another (XP to XP) using the standard Windows RDP client over a VPN connection. Then from the second/connected system open RD Tabs and attempt to connect to another system which doesn't support RDP (NT4). If the connection attempt takes a more than a couple seconds to respond, you may notice the entire Windows interface of second/connected system is sluggish or at times unresponsive until the attempt is canceled or fails with an error like...
Unknown disconnection code 3334 - Because of a protocol error...

I haven't done any additional testing to confirm or otherwise reproduce what affect other versions of Windows, network connectivity, RDP clients, etc. have with the interface's response time.

Being that is a quite isolated incident, I'm more curious what is going on at time during a RD Tabs connection attempt that could possibly cause the interface over another RDP session to drag.


Thanks for any feedback,

Tony Pedretti
La Grange IL USA

While RD Tabs is connecting, not much is happening at all. There's a timer running that updates parts of the UI, the main thread is actually idle, running only to answer repaint events, and the RDP connection is happening on a different COM control (presumably another thread), but that part is handled by Microsoft. The timeout threshhold for connecting is set by the Microsoft code. After disconnecting has begun, there is a moment where RD Tabs has to wait for the COM control to clean up. If this takes too long, RD Tabs may get stuck because the tab owning the COM control can block until the COM control finishes (I have to do this since COM doesn't respond to .Net garbage collection, so it has to "hold on" before it can clean up resources). Anyway, that's the only situation I can think of where RD Tabs blocks. However, even this will only make the RD Tabs UI unresponsive, not any other part of Windows, especially another remote session.

That is a very strange specific error.

If I had to guess, I would guess that since RD Tabs uses the same library as the Microsoft RDC, they are probably sharing resources "behind the scenes" so maybe that's where the problem is popping up.

Does this happen when you use two instances of Microsoft's RDC? Or two instances of RD Tabs?

Not sure what's going on. I don't have a NT box to test with either...

May I ask why you need to run the Microsoft RDC and RD Tabs simultaneously? If you need to run a session on a differnet monitor, you can always detach it and drag the window to the other screen! 🙂

Combination of force of habit and convenience.
I VPN from home into work and then RDP my XP box there full screen which I then use to RD Tabs to connect to various systems. Its preferable for me being that the work box has all the admin tools setup on it and is connected at LAN speeds to the other systems.
Next time I'm connected I'll try using RD Tabs on both boxes.

Doesn't have to a NT4 box guess some host where it takes more than a few seconds to get a response back to RD Tabs.

Interesting guess. I would have thought that if it was a sharing resources issue it would persist after a connection is made. 🙂

So the problem is when RD Tabs is running on a remote computer that you connected to from MS's RDC? I may have misunderstood your question.

It's possible there may be some inefficient drawing code in the version of RD Tabs you are using that might be slowing it down. Have you tried the 2.1.9 Release Candidate yet?

Honestly, I haven't ever tried running RD Tabs from a desktop that I'm connecting to from RD Tabs. It'd be interesting to packet sniff that and see if message are getting lagged somehow.

I was able to reproduce quite briefly while using 2.1.10 x86 on both legs.
Wireshark and Process Monitor may come out if I can get it to hang for more than a couple seconds while connecting.

Thinking about why I continue to use Microsoft's RDP client at home, aside from habit, is the Alt-Tab keyboard combo doesn't get sent to the remote when in full screen mode with RD Tabs. Its a good function when you're using the remote side like the local desktop.
Didn't seem to find a toggle for this in the menu or help file. Am I missing something?

Thanks again!

In the Remote Desktop Connection Properties, go to the Resources tab and select "Send to remote computer" for Windows Key Combinations. I believe that sends alt+tab to the remote desktop in addition to Win+E (et al). If it does NOT send Alt-Tab to the remote desktop, please let me know as I'm positive that it used to work and if it no longer does, that probably means something has been changed in the 6.0/6.1 RDP API (several other things have changed) and it's probably a feature I can add in with relative ease. (Additional tip: to change a setting in ALL connections, modify the setting in the Default Connection Properties and/or "batch edit" your favorites).

As for the hanging, the RDP control (Microsoft's bag) does have some inefficiencies which I have documented, but usually lags are under one or two seconds, so it's not a huge bother on most modern systems (just slightly annoying). If you find something solid and reproducable (especially with the help of Wireshark/Anything-by-Sysinternals) I will CERTAINLY look into it as I'm sure there will be a wealth of information I can use! Additionally, if we can narrow this down to a specific part of RD Tabs, I can send you a diagnostic build with additional information for me to look at as a developer.

Keep in touch, I like to fix obscure bugs. ;-)