I often RDP to my Windows 7 Enterprise (32-bit) work desktop from home through an IPSec VPN; I also connect to from work from other Windows 7 and Windows XP computers.

While I am at work, I have no issues with RDP... specifically, the connectivity would be:

  • Windows7 (data center terminal) -> Windows7 (work desktop)
  • WindowsXP (lab terminal) -> Windows7 (work desktop)

However when I'm at home, I use my Vista Home Premium (64-bit) machine to connect to my same Windows 7 Enterprise (32-bit) work desktop and experience the following symptoms:

  • Parts of application window tiles "stick" when I minimize the window through the RDP session, until I move the mouse across the stuck RDP desktop tile or highlight it by dragging across the desktop
  • Scrolling with the mouse scroll wheel looks jittery and the screen doesn't paint smoothly via RDP
  • Within RDP to my work desktop, using vim inside putty or superputty is almost impossible, since I have to manually shift the putty window for keystrokes to show up. This is my biggest gripe, since I use vim as an IDE and all my development is on a linux machine I ssh to via putty.
  • Oddly, the issues are not as bad when I type directly into a router or linux ssh session (without firing up vim inside the putty ssh window). However, my green putty cursor sometimes "sticks" a ghost cursor on the line if I arrow key back to fix an error on that line

I should note that none of those symptoms exist when I RDP from a machine at work; these problems only exist when I RDP from my home MS Vista system.

CPU utilization of my Vista system at home is almost nothing... I routinely run ping plotters from my Vista PC to my Windows 7 work desktop when I VPN from home, but I don't see packet loss or jitter going to the system...

Ping_plotter from home

My Question: How can I stop the issues listed above when I RDP to my Windows 7 desktop from my home MS Vista system?

MS Vista System Specs

  • OS: Vista Home Premium (64-bit), SP2 [latest patches]
  • CPU: Core2 E8400 @ 3.00Ghz
  • Memory: 4GB
  • Graphics: NVidia GeForce GT 520 (Driver
  • RDPv7 (via KB969084, with persistent bitmap caching turned off)

I tried applying these GeForce settings specifically to C:\Windows\System32\mstsc.exe, but it did not help...

  • Anisotropic filtering: Off
  • Antialiasing - FXAA: Off
  • Antialiasing - Gamma correction: Off
  • Antialiasing - Mode: Override any application setting
  • Texture Filtering - Anisotropic sample optimization: Off
  • Texture filtering - Negative LOD bias: Allow
  • Texture filtering - Quality: High quality
  • Texture filtering - Trilinear optimization: Off
  • Threaded optimization: Off
  • Texture filtering - Anisotropic filter optimization: Off
  • Vertical sync: Off

Edit: This appears to be related to a bug with some newer nVidia drivers as mentioned here. The solution appears to be to use windowed mode on the client (instead of fullscreen) or downgrade to an older version of the driver.

Previous suggestions for completeness:

  • On the initial RDP connection window if you click Options then click the Experience tab you can choose a representative network speed to automatically adjust quality settings. I would suggest you select the Low-speed broadband or Modem (56Kbps) option. If your issues are due to insufficient bandwidth then this should help, but it's also possible that the reduced complexity could help with graphical corruption caused by other issues.
  • Try unticking the Persistent bitmap caching checkbox in case the bitmap cache is corrupt.
  • Check that you have the latest RDP client (v7) which should have been installed by this update http://support.microsoft.com/kb/969084/en-us
  • Temporarily disable any antivirus/firewall software

RDP doesn't use any graphics settings you listed (antialiasing, anisotropic filtering and so on). At least on the "client" machine (Windows Vista). RDP in fact can not transfer the graphics data in this way over the internet. (Because of the many technical features and limitations of application compatibility.) Such technology nowadays not exist at all or at least for common public use.

One of the main task of RDP is just to copy screen image from your "server" (Windows 7), transfer it through connection, and show it on your client (Vista). Like cyclic press of remote "print screen" key and paste into client "MS Paint".

To resolve that task many other algorithms and technologies is used. Neither of standard client machine tasks for graphic processor (textures, antialiasing, post production, etc.)

RDP problems lays in other plane. Most likely, the incompatibility or other errors in between RDP-client (64-bit) and the RDP-server (32-bit) of software that you use.

Try to use other software. I always use TeamViewer for myself. Its free for personal use. And it can be configured to use and connect by IP only (over VPN connection). Just enter IP of your W7 computer in Partner ID field and try to connect.

  • Actually, RDP doesn’t quite transfer graphic data. It works on a higher level, making it more responsive.
    – kinokijuf
    Feb 1 '13 at 11:55
  • Yes, I know almost anything about internal work of RDP. But I think this specific details will not help solve the problem of this question. So I gave a simple and easy example in my answer. However RDP transfers graphic data (I don't say that raw pixels is only one type of "graphics data"). Do you think some kind of additional information can improve my answer?
    – Dima Zorin
    Feb 1 '13 at 16:06
  • I must use RDP, it is the corporate standard... I have always used a 64 bit RDP client connecting to my 32 bit windows desktop... the problems just appeared a couple of months ago
    – This
    Feb 2 '13 at 10:38
  • Teamviewer has been increasingly hostile towards defining "fair use/commercial use" to push license sales. Try AnyDesk. If the established connection is a "direct connection" (any static IP server will likely qualify) , you should be able to connect 1 user for several hours with no problem. No install method works best on servers IMO
    – Jon Grah
    Sep 22 '19 at 14:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.