Why does my shared clipboard not work? (Part 1)

Why does my shared clipboard not work? (Part 1)

Rate This
  • Comments 63

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!

 

Leave a Comment
  • Please add 2 and 4 and type the answer here:
  • Post
  • PingBack from http://blogs.msterminalservices.org/conger/2006/11/16/microsoft-terminal-services-clipboard-troubleshooting/

  • Thanks for explaining this.  I run several rdp sessions at a time and I lose the use of my clipboard often.  Before I tracked it down to mstsc as the problem, I had several hard resets on my machine as I tried not to kick in the monitor.

    I did find a small utility that would show me what mstsc session was the problem child.  That made things much better.

  • Thanks for the feedback. I hope our Vista improvements make your frustrations disappear! What was the name of this small utility you found?

  • I restarted my TS session, it didn't fix the problem.  I can't copy from a Vista RDP session to a Windows Server 2003 local session.  I can copy from the local session TO Vista, but not copy from remote to local.  I can copy to and from a remote 2003 session on the same machine.  I tried everything you suggested, but nothing has worked, even though Clipboard is selected on my RDP when I connect.  :(

  • Jon, the issue you describe *sounds* like a bug I have been trying to track down, but which we have not been able to repro internally. Can you please use the e-mail link (top-right of the blog) to get in contact with us? I will need to get some data from you and it will be easier to do so using mail.

  • Thanks!  Wow, responded in less than an hour!  :)

  • The Terminal Services Team Blog has a great article on why application based clipboard activity can give you headaches in terminal server. Check out their article, Why does my shared clipboard not work? (Part 1). Why does my shared clipboard

  • I typically have 2-7 RDP sessions open at once for the several servers I administer.

    When copy and pasting between my local PC and the Session, or from session to session. The copy does not always get into the Local PC clipboard, and/or transferred to the RDP session Clipboard.  

    Okay that part I can see the above being the issue. Now how about this twist?

    If I use the keyboard it takes maybe 12-100 times of hitting CTRL-C I >might< get  something in the clipboard. If I right click and select copy 3-4 times I can usually get it.

    My Local PC is running Vista Enterprise Ed (x86), the RDP Sessions are

    mostly Win2003 R2, though Some Win2003 SP2, Win2000

    The Apps I'm copy and pasting from are, IE, Notepad, Command Prompt, MMC

    Its really annoying to have to copy multiple times to get somthing on the

    Clipboard.

  • I have the same exact issue as Scooter133. I manage about 150-300 servers ranging from Win2k to 2k3 sp2 and only on my Vista system does the clipboard not work. May have to open a premier case if I can't find a fix, I have to be able to use the clipboard.

  • Follow up, I seem to have the most problems from Outlook 2007 to the TS Sessions.

  • Unbelievable what you're writing.

    Upgrade to Vista? no comment...

    Will MS gracefully provide fix for other non/Vista systems?

    Thanks in advance

    elixnk MS gold Partner

  • I have a XP (local) system connecting to W2k system (host) and my cut/paste would just stop working. On my host machine, I killed and restart the rdpclip process but what happens after that is  I'm only able to only perform one cut/paster operation. After that, the cut/paste operation seems to be broke again. Any ideas?

    joe...

    jbozen@stfrancis.edu

  • I too am amazed that you've written such a detailed explanation of the bug, yet offered abslutely no pushbutton solution. At lease write a simple utility that just restarts rdpclip.exe every 20 seconds or something. gosh.

  • My experience with my XP client to a Server 2003 box is that I can always paste from the server back to the terminal client in XP. However, I can't usually paste in the other direction.

    If I log out of the session and start it fresh, it usually works for a short while but then pasting stops working.

    There should be a bug fix for this erratic behaviour, surely?

    www.capitaloffice.com.au

  • Its worked for me!.  Thank you very much to know about TS sessions.

Page 1 of 5 (63 items) 12345