A few years back we came across a bug where a customer was unable to copy data from a remote session to the local session using the TS shared clipboard. They had a script in the remote session that was doing something like:
// Do something...
The second copy did not always succeed. This was proving to be quite frustrating. After some debugging we discovered the cause…
The Windows system clipboard can only be opened by one application at a time. When it is opened by Application A, attempts by Application B to open it will fail. Hence, B cannot copy any data to the clipboard while A has it open (A might have it open for a valid reason, such as enumerating through the data which is available).
Enter the TS shared clipboard. In order to be notified of when the clipboard has been changed, the TS client (which runs in the local session) and RDPCLIP (which runs in the remote session) register to be part of the clipboard viewer chain associated with their session. When the clipboard is updated, they will be notified of the change. Part of responding to that notification requires opening the clipboard and enumerating through the list of available data types (such as text, graphics or files) and then sending them to the peer component (for example, the TS client will send the list of new data types to RDPCLIP).
Now if you look carefully you can see the race condition which exists in the customer bug. The following time line of events explains it:
1. Script in the remote session opens the clipboard.
2. Script in the remote session copies data to the clipboard.
3. Script in the remote session closes the clipboard.
4. RDPCLIP is notified that the clipboard has been updated.
5. RDPCLIP opens the clipboard to enumerate through the data types.
6. RDPCLIP begins to enumerate through the data types.
7. Script in the remote session tries to open the clipboard.
8. RDPCLIP finishes enumerating through the data types.
9. Script in the remote session fails to open the clipboard.
10. RDPCLIP closes the clipboard.
So, what is the solution? Well, in this case we just made the script retry updating the clipboard a few times, sleeping a bit in between each attempt.
However, for Windows Vista (and Longhorn Server) we worked with our friends in the USER32 team and added a new mechanism which allows us to get the list of data types on the clipboard without opening the clipboard. This means that when the clipboard is updated, RDPCLIP (or the TS client) never needs to hold the clipboard open to enumerate the available data types, effectively blowing away this race condition. 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.
I can not copy clipboard content now. Ealier it used to work! I dont know what caused it to stop working.
I remote desktop from my vista Media center laptop to win XP box.
I dont seem to have the rdpclip.exe file which everyone seems to be refering to. I searched in windows folder.
Help... this is very annoying.. I have a file open in text editors on both machines and have to copy paste text via it.
As many of you, I have a similar issue. Though instead of the copy/paste issue between local RDP and TS-sessions, I'm experiencing this issue in a thinclient environment.
In other words, I have a customer, running a Win2003 Terminal Server. To the server we have about 6-7 thinclient installations. And every now and then, the clipboard fails and they are no longer able to cut/copy n paste whitin the TS-session.
Now, I wrote a little CMD-file that kills and restarts the RDPCLIP.EXE process, but according to customer, it didn't help.
Any tips on what I can/should do?
I have an issue with only being able to copy text and graphics. I am trying to locally copy an individual Powerpoint slide and paste it on the remote instance of Powerpoint. What is pasted is an image of the slide, not the slide and its components.
I tried with and without RDPclip running.
I am using Windows Server Standard 2003 SP2 and Windows XP SP2. The version of mstsc.exe is 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
Hi, is there an way to limit the buffer size when copy from local to the remote in an TS seesion to improve security -- Prevent some bug send mass content out ? Is there any tools to do so?
There is no way to limit the size of clipboard data that can be transferred to or from a remote session.
From all these comments, the clipboard issues are common in Windows XP and the frustration too.
I would like to someone can help with a solution other than restart the operating system, which works but eventually when the failing application do the same thing, clipboard will stop working for all applications again.
Is there any patch or rdpclip.exe parameter to get the clipboard working again? At this time I have a suspicions application but I would rather to do something to get this clipboard working again.
I found something that worked for me without installing any non-official fix:
Killing and restarting rdpclip.exe wasn't working however I knew I had to close an application that wasn't working however there was still a process in the task manager active, so I kill it and tried...nothing...then I killed and restarted again rdpclip and finally worked fine.
So when an application fails for you and clipboard start failing, you can take a look into your process and make sure they all are gone, otherwise restarting clipboard will not work.
Hope helps to someone.
I believe here is the piece which we overlooked for this problem. On remote machine open terminal services Configuration in Administrative tools. Under connections in properties( right click ) of RDP-tcp you will see a tab called client connections. Make sure the disable flag on clipboad mapping is NOT checked.
many thanks for that last peicec of information , it was most usefull for me
It took me three hours and endless websites with useless informations, till I found the entry of js here...that solved my clipboard-problem. Thanks
we have an issue where User A in Session A copies text to clipboard, and User B in Session B can past User A's content a second later in his own session or locally or ....
That is a security concern, as we managed to get personell data from a HR ladie pasted into an Admin's batch script editor window. Or some excel rows from myself into a colleague's SQL script.
We think it is related to a combination of VMware Server 1.0.6. running a virtual windows 2003 Server as a TS, but are not sure. We have not had reports of this problem for our physical terminal server so far, but then again explain the above to users and not get blank looks of "what is he talking about"...
Any ideas? I am totally unable to google this "cross session" phenomenon as all my searches only give the "usual" rdp clip issues.