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!
1. Is Microsoft planning to release Vista RDP6 client for XP like it released the XP RDP for other OSes?
2. What about the RDP6 Web Client?
3. For XP, please dont break Remote Assistance when Vista RDP client is installed.
Question, this may not be related to this issue, but how did Userdump affect the clipboard in the past?
(2) The RDP 6.0 redistributable will update mstscax.dll. There will be no separate msrdp.ocx file for RDP 6.0.
(3) Our test team is making sure it will all still work!
Can you please explain your question more clearly? What is "userdump" and how have you noticed it affecting the clipboard in the past?
This is the utility I am referring to:
The User Mode Process Dumper (userdump) dumps any running Win32 processes memory image on the fly, without attaching a debugger, or terminating target processes.
A while back, maybe a year ago or so, running Userdump on a terminal server would effectively disable the clipboard functionality all together.
Here is another reference -->
I'm not sure if it was related to ICA or RDP, all the document says is "Virtual channels".
Its a moot point now, I was just curious to know how or if it affected rdpclip.
Thank you and Happy Thanksgiving!
From the Citrix comments about userdump, it appears as though when it ran it broke some virtual channel functionality. Since clipboard redirection uses virtual channels, this would explain why clipboard redirection stopped working.
My friend can mstsc to a remote pc and copy during a session (ex: text file) and paste to his local machine. Do you know why I would not be able to?
Elton Saul said:
> (2) The RDP 6.0 redistributable will update mstscax.dll. There will be no separate msrdp.ocx file for RDP 6.0.
I run a server that distributes an activeX that wraps msrdp.ocx (RDP5) inside an encryption layer, which allows clients to do RDP5 over SSL.
Any suggestions as to what i need to develop/modify in order to support RDP6 ? (as there's no v6 version of the msrdp activeX component ?
Thanks a lot,
I am running Vista and I'm using visionapp to rdp to machines. I still run into this issue constantly. Is this possibly on the w2k3 server end? I thought it was visonapp at first but I have the same issue with rdp manager as well.
Joe, if server-to-client copy and paste does not work, then the issue is most likely on the server-side. Is this what you are experiencing?
If you are having problems with client-to-server copy and paste, and you are running multiple clients side-by-side, then it is likely you hit a timing bug which I fixed in the client last year - the fix will be in the Vista SP1/LHS RDP client.
Does it mean that RDPCLIP may not get the correct data types of the latest content?
Just one simple question...
If microsoft knows why this is not working, why don't fix it defenitively??! it's realy a frustrating issue when you are overloaded in work and try to copy a simple line of text and it doesn 't work...
I can't wait for Vista SP1 just for that reason :)
Microsoft technitians surely know aboutit, however the management guys dont even know what a clipboard is so why should they pay someone to fix it ? Besides they need all their ressources to push oh so fancy Vista that bring one more ton of stuff that nobody needs
sad but true
JoePing (going maaaaad because of that problem which is wasting my and other peoples lifetime)
I wanted to know if there is any sort of buffer limitation with RDPClip or Clipboard in terms of the amount of data it can hold or transfer at a single go?
The clipboard goes on the desktop heap, which is fairly small. If I'm interpretting the page I linked at the bottom of this comment correctly, it's about 3MB on 32-bit systems, and 20MB on 64-bit systems. Keep in mind that this heap is used for lots of other things as well, so you won't be able to use all that space.
If you're copying files on the clipboard, the complete contents don't go on the clipboard, so you can easily copy more than 20MB work of files at the same time.