Shift and Control keys out of sync with normal keys over RDP

Question

I spend quite a lot of time working on various machines via RDP (usually RDPing to one machine and from there RDPing to other computers outside our LAN) and have an issue where the modifier keys (i.e., Ctrl, Alt, Shift, and Win) sometimes don't take effect as quickly as standard keystrokes.

For example, if I am trying to type "", I could end up getting 2" because the remote machine gets the first press of the 2 key before it gets the Shift modifier. This causes particular problems with password protected fields (as they often require mixed case letters and you can not see what is typed) and with Ctrl+C (where the highlighted section is deleted and replaced with a C).

(And before anyone asks, this is not just bad typing, otherwise the problem would not be restricted to RDP sessions.)

This does not appear to be a hardware issue as it happens on my desktop (running 64-bit Windows 7) and on my laptop (32-bit XP) and on various Remote computers running various operating systems (from XP to Windows 2008 Server)

There are times when the problem is more pronounced, and it may be related to a slow Internet/VPN connection.

Has anyone seen this problem, and (other than always typing very very slowly, i.e., about one character per second) are there any solutions to this issue?

Solution 1

It is the way the RDP client responds to control keys.

To resolve, try going into the options for the Remote Desktop Connection>Local Resources>Keyboard and change to "On This Computer".

Be aware that alt+Tab and similar commands will now run on the local system.

Other workarounds include:

• Don't run your RDP session in full screen
• Press both left and right (eg: both Shift) keys at the same time
• use the On Screen Keyboard on the remote machine

Solution 2

I've found the solution to this where one is using nested instances of Microsoft's Remote Desktop client. Imagine the following situation. You're sitting in front of an OS X machine, and you remote desktop into a Windows 7 laptop. From the Windows laptop you want to remote desktop into another Windows machine (in my case a work box over VPN). The solution to your keyboard mapping woes is: on the Windows laptop, i.e. the destination of the first jump, change the remote desktop hardware settings for the 2nd jump to use the local keyboard, not the connecting one.

Edit

To change the setting:

1. Open de Remote Desktop Client.
2. Do not connect to a remote host, yet.
3. Click button Options.
4. Open tab Local Resources.
5. Choose option "On this computer" in drop-down list de Apply Windows key combinations.

Although this setting does not seem to apply to simple Shift-key combinations, it did solve the problem for me, when working with nested remote desktops.

Of course, it comes at a price: you cannot Alt-Tab through the windows on the remote host, etc.

Solution 3

It's not "free" but some gamepads let you map buttons to key combinations...think out there mouse or numpad with wrist pivots(i think asus makes one). this MIGHT solve you problem....not 100%, but if it sends a combination it could. the slowing down of modifier keys could also be a cheap attempt at not passing on control sequences(if this turns out to be the case i would look in to VNC server/client as it's a busted solution)

Solution 4

Windows 10 users: Use RDP ≤ 10.0.10586.122

There's been a bug ever since Windows 10 version 1607 (Redstone 1, i.e. build 14393) that causes some keys (like Control) to fail to take effect with short keys, causing a very similar issue to what you're mentioning.

Namely, if you try to press Ctrl+V to paste your clipboard, you might end up with a v on the screen if you don't wait a couple hundred milliseconds between keystrokes.

The only solution I know to this problem is to use a Remote Desktop client from an older version of Windows, such as from Windows 10 version 1511 (Threshold 2, i.e. build 10586), which you can do if you make a folder and copy the following files from your old \Windows\System32, with the given SHA-256 checksums, then run mstsc.exe from it:

9122b428324cc1551702481013efa53b4ab33fe4cb3157a51d8d7a47d02df1ed en-US\mstsc.exe.mui
f85a715b0e624daa91d44ae74c3a4a2a7442fb3934b5eaf48ca8585d58feab1c en-US\mstscax.dll.mui
d1217b4912d832961d61cb58252b8234fa7ddef0b7d5cc7af0e82714800aadf7 mstsc.exe
95508cfddf75355eeac49eaf9476ff8e32b1d798d5e25da84cc077078e2c64a5 mstscax.dll

Solution 5

Seems, the update Windows6.1-KB2847932-x64.msu fixes the issue. I have similar problem on my Win7 like @einpoklum: Shift and Control keys out of sync with normal keys over RDP

1. https://support.microsoft.com/en-us/topic/language-switch-fails-in-a-rd-session-and-shortcut-menu-is-not-displayed-in-a-remoteapp-session-in-windows-7-sp1-or-windows-server-2008-r2-sp1-4cf48953-4635-4bbb-e081-e4e4da03fb35 But there isn't download link for this patch.
2. I could download patch here: http://thehotfixshare.net/board/index.php?/files/file/17983-windows61-kb2847932-x64msu/

p.s. additional links with problem: http://www.davidbond.net/2012/10/rdp-shift-key-gets-stuck.html https://vldmscripts.blogspot.com/2016/03/shift-rdp-fix-shift-key-stuck-in-rdp.html

View more solutions

Comments

[einpoklum]

I very often experience this - both lack of synch, and a control key getting 'stuck' - specifically, Shift. Then I started getting CAPITALIZED TEXT TYPED IN or issuing commands I did not wish to issue.

[einpoklum]

I would user a bounty on this question if I had more reputation on SU... would be very glad if you decided it's worth risking the 50 points.

[Luiz Angelo]

I use RDP a lot and never experienced that. What utilities do you have running on your systems? Does it have something like AutoHotKey? What version of RDP? Does it always happens? Have you trying using the machine locally just to be sure it is not something RDP-related?

[Luiz Angelo]

Do you have IntelliType installed? answers.microsoft.com/en-us/windows/forum/…

[costa]

It's 2021 and I still have the same issue...

[urza.cc]

It's almost 2022 and I still have this issue

[sgmoore]

Don't think this will help unless the gamepad has keys for every single key-combination, eg a key for 'a', another for 'A', another for Ctrl-A, another for Alt-A etc. Also I've used VNC in the past, always tried to replace it with RD or Logmein where possible.

[RobotHumans]

true enough, I didn't know if you were stalling on a single key combo or a bunch of them

[sgmoore]

Tried that, but it did not help. (It did mean that the alt-tab did not work on the remote computer, so the setting was in effect)

[sgmoore]

Where exactly do you change the 'remote desktop hardware settings'?

[einpoklum]

I don't think the OP asked about nested RDP sessions.

[einpoklum]

I second @sgmoore's report: Restricting key combinations to the local computer does not avoid this problem.

[einpoklum]

This doesn't work - see the comments on this answer

[einpoklum]

1. Will Try and see if the problem manifests; what's the intiuition for such a measure having an effect? 2. If IntelliType does not appear in the Programs list (for uninistallation), might it still be installed? 3. My Windows 7 is fully-patched.

[harrymc]

2. Probably not.

[einpoklum]

I'm not immediately seeing the problem manifest, but as it doesn't always occur immediately we'll go into extended trial... why do you think running the RDP client as Administrator helps? Especially for a user who is an Administrator?

[harrymc]

A security feature since Vista : Everyone runs under a restricted account, only "Run as Administrator" is unrestricted.

[einpoklum]

Unfortunately, this did not work - although it seems the frequency of the 'sticky shift' phenomenon decreases when RunAs'ing as Administrator. Or perhaps I'm just not performing enough repetitions of the experiment. Anyway, no cigar.

[harrymc]

More attempts on the cigar : (1) Disable TCP Auto Tuning, (2) Reduce color depth / resolution / background, (3) Disable any keyboard product such as AutoHotKey.

[einpoklum]

1. Will try this at work later this week. 2. Already did that. 3. My server machine certainly doesn't have that, I'll check whether I have this kind of junk on the client. Anyway, from the looks of it you'll get the bounty for effort.

[harrymc]

Let me know how it goes.

[einpoklum]

Haven't had time to test this, but you get the bounty anyway. No sense in wasting ~15 of my entire reputation for nothing.

[V-R]

The RDP Keyboard "On This Computer" setting was the only thing that successfully resolved the annoying issue for me. To replace the alt-Tab on the target machine, I'm using switcheroo.io, which is an open-source project on GitHub. I find it even better than the original Win7 alt-Tab dialog.

[Gennady G]

Does it override the ALT-TAB key or it still switches on home machine?

[Christian]

stop suggesting Apply Windows Key to remote. Its the first thing we all try. Its right there in the menu settings not hard to miss. This is a deeper rooted problem.

[Sandra]

re:@einpoklum OP does appear to be asking about nested sessions - from the Q: "(usually RDPing to one machine and from there RDPing to other computers outside our LAN) "

[boes]

This exactly describes my problem and the solution works perfectly!

[Toto]

While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review

[Vitaly Vitoff]

@Toto What is wrong with my answer? I don't understand. > it is better to include the essential parts of the answer here and provide the link for reference. What are the essential parts? What is the link for reference? p.s. and yeahh this seems very friendly: Toto reviewed this 1 hour ago: Recommend Deletion