Why does my shared clipboard not work? (Part 1)
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:
-> A
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:
-> D -> C -> B -> A
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:
-> D -> C -> B -> A
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:
+---------+
V |
-> 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).
Summary
If you have a shared clipboard problem, see if the following troubleshooting guide helps:
|
Symptom |
Possible Cause |
Possible Solution |
|
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!
