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!
The has been a lot of talk about badly written apps breaking the Clipboard chain. We have this happen quite often and I would like to track down which of our apps is causing the problem. Can you suggest any utilities or methods for troubleshooting and finding the "bad app"? Maybe a utility for viewing the Clipboard chain so that when it happens I can see what apps are missing from it and which are still there? If I can find out which app is causing it, I can make a bug report to the app vendor and possibly get a fix. Other than that, I would have to hope that Microsoft will eventuall come up a with a fix (For XP and 2003). It sounds like Vista is having quite a few issues with this also... We will be on 2003 Terminal server for at least another year. We run about 30 Terminal servers and this is a consistant complaint from our Users. It happens randomly and we have yet to find the cause... Seems to be noticed mostly when running office 2003 on terminal server.
Our silly little vista problem with the clipboard is this --- anytime you try and hit the "print screen" button and then go attempt to paste that image into "paint" it says you are not allowed access to the clipboard. End of story.
Every user on earth has been allowed to use this funtion for years and years now, yet somehow we're supposed to think this is not a planned reduction of personal liberty on microsofts doing? Just a mere oversight? I think NOT...
Of all the stupid ways to design clipboard access, Microsoft has come up with a management nightmare again. All that is needed is temporary storage accessable to any application that needs its content. If there is a more convoluted, error-prone solution, Microsoft will unfailingly implement it. No wonder they eliminated the clipboard viewer in Vista and sent us back to the dark ages of pasting to wordpad to confirm the contents of the clipboard! SHEEEEEEESH!!!
Thank goodness for third party clipboard utilities.
While I do appreciate a candid description of what's happening behind the scenes, as an end user I find this infuriating.
I find it completely inexcusable that a dept blog from Microsoft would publish a 'bug' without a fix, and blame it on poorly written software and insinuate that if you upgrade $$ to Vista your problems will lessen. ???
I searched the dominate search engine uncle "Goog" for the answer to my problems and sadly I find that the comments of this post offer more of a solution than the original poster does.
It's a fairly gloomy day for MSFT when the only fix is to restart a buggy process (rdclip.exe) Reminds me of the '3 finger solute' days of win95.
Very usefull and detailed information !
It helps me to resolve all issues with the windows 2k3 clipboard
Thanks. That was an interesting read. But i would have liked to know why was it not designed so that the OS controls notifying all the processes about any update on the clipboard instead of the processes doing it themselves. I mean was there any limitation due to which the original design was done this way??
Why has no one here suggested Terminals? Its a godsend, however it suffers from the same issue as the offical Microsoft RDP client... Check it out google for it their site is at codeplex
Who really cares how it works? It should just friggin work! Makes me want to get a Mac.
Application A talks to APplication B and my blog copies blah blah blah... This is yet another nuance to add to the infinite list.
BTW, I am using Vista and 2008 for the remote server and it still doesn't work!
My problem is that rdpclip.exe just isn't starting on the terminal server session..... But I can't find any info on how to resolve this one anywhere :(
I've had this problem connecting from Windows XP SP2 to both Windows Server 2003 and Windows Server 2008. The workaround I'd found was to toggle the TS config setting for allowing clipboard access, but that also requires logging off/on to start a new RDP session - a big pain. The problem is usually copying from an app in my RDP session back to an app on my local workstation. From this post, I would have thought that copy RDP > paste local would be better (due to the improvements in rdpclip), but it still seems to have issues because killing and restarting rdpclip just fixed the problem for me. The server is Windows 2008 Server, Standard w/o Hyper-V, SP1, 64-bit.
Gotta love a linked list that the API requires the clients to maintain! Well, glad it's been redesigned in the new USER32..
As for the old version with this problem, there is a software workaround for developers... a) record the clipboard sequence number in your WM_DRAWCLIPBOARD handler, b) create a timer in which you call GetClipboardSequenceNumber() and compare to the last number you received in WM_DRAWCLIPBOARD. If those numbers differ, you know you've been dropped from the notification chain (or perhaps some dipshit app has been inserted in front of you and isn't passing along messages), and should re-add yourself. In this way, you can avoid user intervention such as having them restart the application.
Have you considered telling Microsoft? Office is the one that is almost always running when I have problems.
This goes a LONG way to explaining the weirdness I have been seeing on my RDP sessions, great article which makes it easy to understand the problem.
Copy and paste wasn't working from my remote XP system to my local Windows 7 system. All I had to do to fix this problem was run RDPCLIP from the remote system. Thanks for the advice!