The TS shared clipboard allows you to copy and paste data between local and remote sessions. When it works its really simple and seamless, but what about when it doesn’t? Diagnosing clipboard problems can be hard and frustrating!
The majority of clipboard problems fall into the category of clipboard viewer chain related issues. What is the clipboard viewer chain? Essentially it is a collection of applications which are interested in being notified of updates to the local clipboard. Applications which have registered to be a part of the viewer chain receive a notification whenever the clipboard has been updated. However, there is a major caveat! The clipboard viewer chain is application-controlled. This means that applications in the chain are responsible for:
o Passing on notification messages to the next viewer in the chain
o Removing other applications from the chain
Passing on clipboard update notification messages
Assume there are no applications in the viewer chain. Application A joins the chain and it appears as follows:
Application B then registers to join the chain. When it does so, it gets told who was previously at the front of the chain, and it is responsible for storing this information. The chain is now:
-> B -> A
Let’s have C and D join as well (in that order). The chain is now:
-> D -> C -> B -> A
Now, assume some text is copied to the clipboard. The system looks at who is at the front of the viewer chain and notifies them of the clipboard update. In this case it is D. D does what it needs to and then looks up who is next in the chain by referring to some information it has stored away somewhere. This is where problems can arise. If D is a badly written application (they do exist), then it might not have stored who was previously at the front of the chain when it joined (or maybe there is a bug and it gets the wrong information), and as a result C will not be notified of the update. Hence, we have a broken viewer chain – C, B and A are not told that the clipboard was updated.
Removing applications from the viewer chain
Assume that the viewer chain looks as follows:
B decides that it is time to leave the chain. So, it tells the system that it wants to be removed from the chain. The system then sends a message to the window at the front of the chain which says something like:
“Remove B from the chain. A should take B’s place in the chain.”
Since D is at the front of the chain, it checks to see if B follows it in the chain. If not, it passes the message on to C. C sees that B follows it in the chain, so it updates its internal structures and now records A as following it in the chain. The chain is now:
-> D -> C -> A
Of course, this removal process is prone to failure. Say D did not pass the deletion message on. The chain remains as:
But, when C tries to send the clipboard update notification to B what will happen? If B has exited then A will not get the notification. If B has not exited it might choose to ignore the notification as it has no obligation to pass it on since it is not part of the chain. Hence, we have a broken chain and A will most likely not be notified of clipboard updates.
Now, imagine that B decides to rejoin the chain. Then we will have:
-> B -> D -> C -> B -> A
This is actually:
-> B -> D -> C
In other words, we have a loop in the viewer chain. Not only will A not be notified of updates, but the update notification will spin between B, D and C continuously!
What does all of this have to do with the TS shared clipboard?
Okay, so we have discussed some theory, but what does it have to do with the TS shared clipboard? Everything!
In the local session the TS client is in the clipboard viewer chain and in the remote session the RDPCLIP virtual channel application is in the viewer chain. When a clipboard update happens in the local session, the TS client is notified and informs RDPCLIP of the changes so it can propagate them to the remote session. Similarly, when a clipboard update happens in the remote session, RDPCLIP is notified and informs the TS client of the changes.
Now, say that the local clipboard viewer chain is broken so that the TS client is not notified of clipboard updates. That means that clipboard changes will not be sent to the remote session, resulting in a user being unable to paste data into the remote session as the clipboard there is not updated with the latest formats. Similarly, if the clipboard viewer chain in the remote session is broken so that RDPCLIP does not get update notifications, then clipboard changes will not be propagated to the local session and a user will be unable to paste data from the remote session.
What is the solution to a broken viewer chain? If remote to local session copy and paste does not work, you can try to kill rdpclip.exe and then restart it. You can use Task Manager to kill the process and then at any command prompt just type “rdpclip”. When it starts up, RDPCLIP should reinsert itself into the chain. If local to remote session copy and paste is broken, you should close the TS client and then reconnect to the session, since the client inserts itself into the viewer chain when it starts up.
What about loops in the viewer chain? If you notice either the TS client or RDPCLIP consistently using a lot of CPU cycles, then it could possibly be due to a loop in the chain. First try to kill and restart RDPCLIP. It may be part of a circular viewer chain and as a result constantly sending the client “clipboard updated” packets, causing itself and the client to work overtime. If this does not solve the problem, try to close the client and reconnect to the session.
Windows Vista and Longhorn Server to the rescue
In Vista and Longhorn Server (LHS) our friends in USER32 added some new system APIs which implement a system-controlled viewer chain. No longer do applications have to contend with managing the chain! The system now maintains a list of applications which want to be notified of updates to the clipboard, and when the clipboard is updated, the system goes and tells each one that the clipboard contents have changed.
Since the new clipboard APIs are only available on Vista and above, you have to be running the TS client on Vista and connecting to a Vista (or Windows Server Codenamed Longhorn) machine to get the full benefits of the new behavior. If you are connecting to a Vista machine from an XP box, then the local clipboard viewer chain is still subject to breakage, while the remote clipboard viewer chain (of which RDPCLIP is a part) will be more reliable and remain intact. Hence your remote-to-local copy and paste operations should always work, while the local-to-remote could still break (due to the local clipboard chain being application-controlled).
If you have a shared clipboard problem, see if the following troubleshooting guide helps:
Remote-to-local copy and paste broken.
RDPCLIP is not in the clipboard viewer chain.
Kill and restart RDPCLIP.
Local-to-remote copy and paste broken.
TS client is not in the clipboard viewer chain.
Close the TS client and reconnect to the session.
RDPCLIP or the TS client is using excessive CPU.
There is a loop in the local or remote clipboard viewer chain.
Kill and restart RDPCLIP. If this does not fix the problem, close the TS client and reconnect to the session.
Remember, that on Windows Vista and above, the clipboard viewer chain system component is radically improved. Another reason to upgrade to the best Windows version ever!
Using XP to connect to a Windows 2003 Server I never had a problem with the clipboard. Using 2 new PCs with Vista I never have been able to transfer a file via copy/paste. Killing and restarting rdpclip had no effect. Still broken for me...
What is the root cause of this problem?
I have XP Connecting to XP and all sorts of clipboard problems, including errors in Excel, but, in all cases, Restarting RDPClip.exe works find for me. In some cases I just re-initiate the connection, (the old connection drops) and often works find.
I have to do it many times a day. Why only between certain machines while others have no problems?
FYI: For all you out there that use RDP on a regular basis and have this issue often I’d suggest using the 'Remote Desktops' MMC provided with the Domain Admin Tools as I haven’t had the Clipboard issue when using it where as I do when I use the RDP client.
Note: This is only personnel experience and I hope you have the same results.
Thank you Robert for taking the time to post.
I was able to find a download for it here http://www.microsoft.com/downloads/details.aspx?FamilyID=c16ae515-c8f4-47ef-a1e4-a8dcbacff8e3&displaylang=en
I extracted the MSI then launched it.
After that I went into MMC and added the remote desktop snap-in.
Is there a way to get the MMC to work more like the RDP client? I'm not administering a server, I'm using a remote workstation.
I want Full Screen! I don't want to re-learn how to use windows again (windows-D will get you to a desktop in RDP, but not in MMC)
I am in tears, I have a handful of servers that cut and paste correctly to my XP laptop, but my most heavily used server, 2K3 does not cut and paste to any of the remote clients.
It can cut and paste to itself and same with my laptop, but not between this server and my laptop.
My clipboard is not shared on only one server - Win2K3....all my other servers, this is no issue, but I have to copy ckt ID's and I can't here, very time consuming and confusing.
I didn't have this issue until I upgraded to Windows Vista 64-bit edition.
I manage dozens of servers, so I use Remote Desktop VERY HEAVILY, and need to copy information back and forth a LOT to do my work. I cannot disconnect and reconnect every time this happens.
Is there a more permanent fix for this? Perhaps a patch?
I had this problem as well so I created a quick (.NET 2.0) utility to restart a process and installed on the servers I RD to.
Now it's one click vs. manually killing and restarting rdpclip to resolve immediate copy-paste issues w/ RD.
You're welcome to use it. You need v2.0 of the .NET framework to run it:
1) save zip locally
2) unblock zip (in properties of the zip file)
3) extract exe to wherever
4) create a shortcut for the exe
5) edit the Target of the exe shortcut to read "C:\<wherever>\RestartProcess.exe" "rdpclip"
6) put the shortcut somewhere accessible (QuickLaunch bar is a good place)
STANDARD DISCLAIMER: No guarantees. Use this utility at your own risk.
I put up a small tool on my site that fixes the issue. You can find it here: http://remkoweijnen.nl/blog/2007/10/25/rdp-clipboard-fix/
I haven't been up to much recently. Whatever. I've pretty much been doing nothing worth mentioning. What can I say?
I am running Windows Vista and using RDP to connect to Windows XP. I have not been running with Vista for long, but in the last couple of days I've found that local to remote pasting is failing.
For a while, restarting RDP client fixed the problem but after the first paste I did it would break again. Now even restarting RDP client does not help. None of the above steps fixes this issue.
I have a feeling a restart of Vista will bring me back, but it's a shame as this has been my first negative experience of Vista (only been running with it for a few weeks).
David, have you tried the Vista SP1 release candidate? We fixed some shared clipboard bugs in both the client and server for that release.
Remko Weijnen tool works. Link above.
Is there a fix or a part 2?
Part 2 is here: http://blogs.msdn.com/ts/archive/2006/11/20/why-does-my-shared-clipboard-not-work-part-2.aspx