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!
Great Article. Thanks a lot.
I have been working on Clipboard monitoring application and I am facing problem of clipboard chain broken. Sometimes it happens that some application registered into the clipboard chain and terminated without unregistered which leaves all other applications in clipboard chain without having clipboard change events.
Could you please help on my below questions. It would be really helpful for me.
1. How many clipboard chain will be there and how it differs from application X to application Y?
2. Sometime it happens that some application X getting clipboard event changes but not other application Y. How this could be possible?
3. If some how clipboard chain broken then is there any way to take all application into that chain back to working clipboard chain?
Please let me know if you need any other details.
People keep referring to killing RDPCLIP as a "fix". It is not a fix - it is a work-around. When no one needs to even think about this (or blog about it) because it "just works", then the issue is "fixed"
As stated by others above, I don't care how it works. Copy/Paste has been a part of Windows since when, day 1? Now it doesn't work properly. Fix it. End of story.
Microsoft - I'm not sure how else to put it, but I'd rather see all of the known issues fixed in your currently released products before you release any NEW products.
C:\> taskkill /fi "username eq %USERNAME%" /im rdpclip.exe & rdpclip
Only Microsoft could make such a huge mess of such a simple concept.
I have enough trouble with buggy clipboard behaviour even when not using RDP.
Get a grip on reality Microsoft.
Features for features sake is an infantile approach. It has to WORK RELIABLY.
>> "Another reason to upgrade to the best Windows version ever!" (Vista)
Cough, cough, Splutter!...
I hope the authors latest batch of Prozac is better than his 2006 batch...
Seriously, I have to deal with this bug 5 or 6 times per day. Why is the fix (not the work-around) taking so long?
As far as I am aware Microsoft are not releasing an update for this. People will just have to live with it or upgrade.
It is quite funny that Microsoft blames badly written software, considering that the only 4 applications that I am running every time the problem occurs are Internet Explorer, Excel, Outlook and SQL Server Management Console.
Anyone else seeing a trend here?
Having said that, Excel is often the cause of this problem.
I hear what you're saying, but using non-Microsoft software is no excuse for a Microsoft piece of software not to work correctly. We all know that the bad-vendor-driver excuse for some BSODs didn't fly, and for the most part, that issue has been fixed.
Too often we're told that we need to uninstall/reinstall (be it drivers, applications or Windows itself), reboot, or upgrade to fix a problem. I think what we're all forgetting is that enough people don't accept the above as solutions - by voicing their displeasure to Microsoft - Microsoft will be forced to fix the issue.
Microsoft - any updates? This problem is still occurring.
People keep referring to killing RDPCLIP and I really have no idea how to go about doing that. If anyone would be nice enough to explain it to me I'd really apreciate it. I really need to be able to cut and paste from my remote access screen and it suddenly stopped working after using it for 4 months.
Any help would be greatly apreciated.
thank you for your time
Start Task Manager on the remote machine, find the process called rdpclip.exe, right-click it and press "End process".
Then, still in Task Manager, go to File -> New Task and enter "rdpclip" and press OK.
Has helped me fix it, too, but as the others said, the whole thing is ridiculous. And no-one has yet mentioned the fun you can have with the clipboard when working with Citrix seamless apps!
hi guys., In my case: we have windows server 2008 and connecting to the terminal services using ie..
and after trying all the solutions posted here.
this one solution worked for us and you could actually use the local drives
on the server
edit the file using notepad(run as admin)
Select File > Open and browse to the following file:
C:\program files\windows small business server\bin\webapp\remote\tsweb.aspx
Search for this line:
MsRdpClient.AdvancedSettings2.RedirectDrives = FALSE
Change the line to:
MsRdpClient.AdvancedSettings2.RedirectDrives = TRUE
Save the file
Log back into the remote web workplace.
Script to kill and restart rdpclip -
On Error Resume Next
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_Process",,48)
For Each objItem in colItems
if (ucase(objItem.Caption) = "RDPCLIP.EXE" ) then
Set objShell = WScript.CreateObject( "WScript.Shell" )
No help here.... just a sales pitch!
I've been doing a lot of editing on Server 2008 from a Windows 7 RDC. I find I have to constantly kill and restart RDPCLIP. Killing rdpclip.exe and not restarting makes the clipboard work on the remote server, restarting it lets me transfer to the local machine but it soon becomes non responsive again. The problem does not occur between a server 2003 and XP box I have to use for another client. I'd say the problem is far worse now and needs fixing.
Here's an easy way to restart a remote rdpclip process:
make a .bat file on the remote computer. call it whatever you want.
edit the bat file and add the following
"taskkill /im rdpclip.exe
Save the .bat file. And run it each time you need to fix rdpclip.