Ghost keyboard entries in RDP session

Hello,

Thank you for contacting us on this matter! This is not a behavior that we have experienced or seen reported so far, so we will need to investigate it to determine its cause.

First of all, I would like to know if you create a new session from scratch, and keep its settings as close to default as possible, if the issue still persists.

I would also be curious to know, in a session where this issue is present, if toggling the Magnet button at the bottom-right of RDM's interface changes the behavior.

Best regards,

Hi Gabriel,

The issue occurs whenever I'm using RDM. It can be for a saved RDP entry/session, or it can be a new session from scratch. I've actually had this issue since many RDM versions ago, but it didn't bother me too much and so I just ignored it, until now.

I'll need to play around with the magnet button at the bottom right. Is there a way to disable this permanently? It seems to re-enable itself everytime I start up RDM.

Also, how is the "grab keyboard input" (magnet button) different to the "keyboard hook" setting? What does it actualy do?

Hello,

Thank you for your response!

Regarding the difference between the magnet button and the "Keyboard Hook" option, both are pretty similar in effect but the magnet affects all types of sessions, while the "Keyboard Hook" option is only available in the RDP entry type.

With that said, since you have confirmed that the issue only occurs in the embedded display mode, I'm thinking the issue might be tied to the ActiveX we use for embedded RDP sessions. In order to verify this theory, I have a test I'd like you to do with when you have some time, using RDC Manager, a different program that uses the same ActiveX for its embedded RDP sessions.
You can download the application RDC Manager from the following page
https://kb.devolutions.net/rdm_rdc_manager.html?q=embedded#description
Please try to recreate one of your problematic sessions using RDC Manager and let us know if you have the same issue using it.

Best regards,

Yes, I've used RDCMan and the standard MSTSC before and don't recall having any issues.

The other problem with RDM is that it would sometimes steal focus. I have turned off all the focus related settings already. I think what may have happened is that on my local machine, I'm typing something or pressing key combinations (e.g. Win+R for run) and RDM would steal focus in the background and then have the modifier keys like Win pressed and it gets stuck and held down.

I have turned off the magnet icon at the bottom right and after a few RDM restarts, it has stayed off. I think it is better now, I don't think I've encountered the issue yet so far.

Also, the issue occurs regardless if my RDP session is undocked or embedded.

Hi again,

In order to help me troubleshoot and get to the bottom of the issue, I thought I'd install something like a keyboard overlay to show exactly what keys are pressed (and held down). I'm using this:

https://keypressosd.com/

you can find a free and non-commercial version from the same author here:
https://github.com/marius-sucan/KeyPress-OSD

If you want to use the same config as me, you can just edit the "keypress-osd.ini" and paste the following in:

[SavedSettings]
FirstRun=0
ReleaseDate=2021 / 01 / 22
Version=4.66.2
AutoCheckUpdates=1
ConstantAutoDetect=0
DetectComplexKeyCombos=1
LargeUIfontValue=13
NoRestartLangChange=1
NoWelcomePopupInfo=1
OptimizeForPerformance=0
PrefsLargeFonts=0
SafeModeExec=0
SilentDetection=0
useKeyNamesCache=1
UseMUInames=0
[ClipboardManager]
ClipMonitor=1
ClippyIgnoreHideOSD=0
DoNotPasteClippy=0
EnableClipManager=0
MaximumTextClips=10
MaxRTFtextClipLen=7000
RTFtextClips=1
[TypingMode]
AlternativeJumps=0
AltTypeEndAction=2
AltTypeHighlightCaret=0
AltHook2keysUser=1
AutoDisableTypeMode=0
autoCaptureLines=0
DisplayTimeTypingUser=2
DisableLineBreaks=0
DoNotBindAltGrDeadKeys=0
DoNotBindDeadKeys=0
EnableAltGr=0
EnforceSluggishSynch=0
EnterErasesLine=1
EraseTextWinChange=0
ExpandWords=0
ForceAlwaysUWP=0
NoExpandAfterTuser=4
MaxExternTxtLen=4950
MediateNavKeys=0
MediateEscKey=0
OSDsynchShortcuts=0
PgUDasHE=0
QuickSnippetsShortcuts=0
ReturnToTypingUser=3
SendJumpKeys=0
SendTextsByClipbrd=0
ShiftDisableCaps=0
ShowDeadKeys=0
TypingDelaysScaleUser=7
UpDownAsHE=0
UpDownAsLR=0
TypingModeUserOption=1
ExoticScriptsSupport=0
CacheOSDupdates=1
UWPsendDelayKeys=4
[OSDprefs]
keyNamesLang=English
AutoScaleFont=0
OSDclickThrough=1
attachOSDtoWindow=0
attachOSDatBottom=1
AttachToolbarOSD=1
DisableOSDandTooltips=0
DifferModifiers=1
HideAnnoyingKeys=1
ShowKeyCount=1
ShowKeyCountFired=1
ShowMouseButton=1
ShowPreview=0
ShowPrevKey=1
showKeysHistory=1
ShowPrevKeyDelay=300
ShowSingleKey=1
ShowSingleModifierKey=1
CapsColorHighlight=88AAff
CurrentDPI=96
DisplayTimeUser=2
DragOSDmode=0
noToolbarTooltips=0
FontName=Arial
FontBolded=1
FontItalica=0
FontSize=16
FontQuality=1
MinFontSize=14
CaretWidthUser=0
GUIposition=1
GuiXa=42
GuiXb=700
GuiYa=560
GuiYb=500
HideToolbarWithOSD=0
HideTextCaretsUser=0
HiPrecisionTxtCalc=0
JumpHover=0
MaxGuiWidth=500
MouseOSDbehavior=1
NeverDisplayOSD=0
OSDalignment1=3
OSDalignment2=1
OSDsizingFactorH=50
OSDbgrColor=131209
OSDopacity=150
OSDacrylicEffect=0
OSDroundCorners=0
OSDshowLEDs=1
OSDtextColor=FFFEFA
OutputOSDtoToolTip=0
SelectionBgrStyle=1
ShowLangCode=1
ShowToolbar=0
ShowToolbarCollapsed=0
ToolbarOpacity=230
ToolbarBgrColor=222222
ToolBarBtnWidth=40
TLBRverticalAlign=0
TypingColorHighlight=12E217
KeysHistoryBelow=0
UserToolbarX=200
UserToolbarY=60
plusOneTlbrActionL=1
plusOneTlbrActionR=1
[Sounds]
AudioAlerts=0
BeepFiringKeys=1
BeepSentry=0
BeepsVolume=30
CapslockBeeper=0
DeadKeyBeeper=1
DTMFbeepers=0
DynamicVolume=0
KeyBeeper=0
ModBeeper=0
MouseBeeper=0
PrioritizeBeepers=0
SilentMode=0
SentryNoAudios=0
ToggleKeysBeeper=0
DistinctGroupsBeeper=0
WhenBGRsounds=1
multiChannelPlayback=0
[Mouse]
ClickEnhanceOnRelease=1
StyleClickEnhance=1
defaultStyleClickEnhan=2
FluidSpotLight=1
MouseVclickScaleUser=10
ShowMouseHalo=0
ShowMouseHaloSpot=0
ShowMouseIdle=0
ShowCaretHalo=0
MouseHaloAlpha=90
MouseHaloColor=EEDD00
MouseSpotColor=332200
MouseHaloRadius=75
MouseSpotRadius=175
MouseIdleAfter=10
MouseIdleAlpha=70
MouseIdleColor=333333
MouseIdleRadius=130
MouseIdleFlash=1
HideMhalosMcurHidden=1
MouseRippleMaxSize=140
MouseRippleThickness=10
MouseRippleFrequency=3
MouseClickOpacity=160
MouseWbtnColor=888888
MouseLbtnColor=ff2211
MouseRbtnColor=4499ff
MouseMbtnColor=33cc33
CaretHaloAlpha=128
CaretHaloColor=BBAA99
CaretHaloHeight=30
CaretHaloWidth=25
CaretHaloFlash=1
CaretHaloThick=0
CaretHaloShape=2
MouseKeys=0
MouseNumpadSpeed1=1
MouseNumpadAccel1=5
MouseNumpadTopSpeed1=35
MouseWheelSpeed=7
MouseCapsSpeed=2
MouseKeysHalo=1
MouseKeysWrap=0
MouseKeysHaloColor=22EE11
MouseKeysHaloRadius=45
NoClickVisualsMhidden=0
[Hotkeys]
GlobalKBDhotkeys=0
GlobalKBDsNoIntercept=0
KBDaltTypeMode=+#Insert
KBDnewTXTexpand=#vkdc
KBDshowEntireText=(Disabled)
KBDpasteOSDcnt1=^!Insert
KBDpasteOSDcnt2=^#Insert
KBDsynchApp1=#Insert
KBDsynchApp2=!#Insert
KBDsynchApp3=#Home
KBDsuspend=(Disabled)
KBDTglNeverOSD=^+!F8
KBDReload=^+!F12
KBDclippyMenu=(Disabled)
SnippetsShortcutsRow=1
SnippetsShortcutsMods=^#(Restore)
KBDcustom1=^+!F7
KBDpersonalAct1=3
KBDcustom2=^+!F9
KBDpersonalAct2=6
KBDcustom3=^+!F10
KBDpersonalAct3=5
KBDcustom4=^+!F11
KBDpersonalAct4=11

Anyway, I have this installed on both my local machine and on the remote machine that I am RDP'd to.

What I noticed is that when I'm typing in the remote session, the OSD in the remote session would show what I'm typing (expected behaviour). However, the OSD on my local machine would occassionally show the modifier keys (control, shift, capslock, etc) that I've pressed, despite that I'm typing in the remote session.

Likewise, if I'm typing on my local machine, sometimes the OSD in the remote session would pick up key inputs, even though I did not focus the window into the remote session.

So in other words, my keypress inputs are being registered both locally and remotely. Keyboard hook setting is set to remote computer and the magnet icon is disabled.

I think what is happening is that when I'm on my local machine and I press a modifier key combination (e.g. WIN+R), the Win key is somehow registered into the remote session and is pressed down, but never released. So when I start typing in the remote session, it triggers a combination of Win + XYZ key.


I'm not sure why this is happening.

Hello,

Thank you for the information you provided!

I am currently our of ideas as to what could be causing this issue and how it could be resolved, so I have contacted my colleagues in the engineering team for their insight on this case.

I will keep you posted when I have more information to share.

Best regards,

Hello,

Following a quick conversation with our engineering team, they also suspect that the issue could be tied to the ActiveX used for embedded RDP sessions. For this reason, they would like to verify if using a different RDP application in RDM changes the behavior, or if it persists.

You can change the RDP application by entering the properties of your RDP session, going to the Advanced tab and changing the "RDP Version" option to "RDP (FreeRDP Latest).


As with any changes made in the properties of an entry, make sure to restart the session after making the changes, as they won't be applied to an already running session.

Also, although you mentioned not remembering the behavior occurring with RDC Manager, we would still be curious, if you have some time to test, to confirm if the issue only occurs within RDM.

You can download the application RDC Manager from the following page :
https://kb.devolutions.net/rdm_rdc_manager.html?q=embedded#description

Best regards,

Thanks for the suggestion.

I've tried both FreeRDP (Latest) and FreeRDP (7.0). When I open the saved RDP entry, it would show a black screen and the entire RDM app just terminates itself without showing any error messages.

I am now starting to wonder whether the issue is caused by the feature "Windows Key on the Remote Computer". I use this featurebecause I need to use key combinations like WIN+R or Win+E, etc. It also makes me wonder how this feature differs to the "Keyboard Hook" setting?



UPDATE 1:

I seem to know how to replicate the issue now, it's not consistent but I can reproduce it about 90% of the time.

On my local machine, if I run Win+E to bring up file explorer and then move my mouse cursor to an undocked RDP session (but do not click into it), then I do a CTRL+W (while still in my local session) to close file explorer and then click my mouse into my undocked RDP session, the Win key will be pressed and held down, without me actually pressing the Win key in the remote session. On the local session, the Win key is not pressed and held down.

Basically, the remote session somehow picked up an input of the Win key from my local session, despite that the Win key was registered many steps ago.


UPDATE 2:

OK, I'm faily certain the culprit is to do with the "Windows Key on the Remote Computer" feature/setting. I use a lot of Win+KEY combinations and I noticed that everytime I trigger a combination on my local session and then left mouse click into the remote session, it will keep the Windows key stuck. If I disable the "Windows Key on the Remote Computer" setting in RDM, the issue goes away.

However, I do need "Windows Key on the Remote Computer" to be enabled. I was hoping to find some sort of workaround, but there isn't even a keyboard shortcut to enable or disable this feature in RDM. Not to mention that if you're using an undocked RDP session, you can't easily disable or enable the feature from the title bar. If this could be added as an option along with "Reconnect", "Work Area Screen", etc, then it would be somewhat easier to enable/disable. Instead, we have to go into the main RDM window to enable/disable it.

This is the undocked session title bar options that I was referring to. The "Windows Key on the Remote Computer" should be added here as well.





Anyway, could you please check if there's some sort of bug with this setting? It's like RDM somehow steals focus of the Windows key input on the local session.

The weird thing is that on my local session, the keypress of the Win key was not the last key event. Remember, I pressed Win+E and then I do a CTRL+W. So the last key event is the 'W' key, or the "CTRL+W" combination. However, RDM somehow picked up the Win keypress.

Just to make sure the issue is not caused by other apps, I have clsoed all the running apps on my local machine except for RDM. I can replicate the issue by enabling and disabling the "Windows Key on the Remote Computer" feature.

I also found this post here, which may or may not be relevant:
https://forum.devolutions.net/topics/34722/windows-key-on-remote-computer-not-working



Update 3:

I've tried FreeRDP again and I can connect to my RDP session now, but it's not very good and needs a lot of improvement. If you create a RDP entrye and configure it to use FreeRDP (latest) and undock to a monitor, then when you launch the session it will say "unable to find host". No, it's not a NETBIOS or network issue, nor is it a RDP configuration issue. If you modify the RDP entry to run as embedded and not undocked, then the session can launch just fine. So clearly, FreeRDP doesn't seem to be compatible if you launch it undocked. HOWEVER, if you launch the RDP session as embedded and then you manually undock, it works fine.

2nd issue with FreeRDP. If you have "Smart Reconnect" configured in your saved RDP entry, then lauching the session will cause RDM to freeze and crash and no error mesage will be thrown.

Alsoe, in a FreeRDP undocked session, the "reconnect" option will reconnect but not adjust the display resolution, whereas in an ActiveX RDP session it will do that just fine.

In a FreeRDP undocked session, you don't get any title bar options like Reconnect, Work Area Screen, etc. Whereas for ActiveX, these options are available. I'm referring to the screenshot from above.

The other problem that I found is that there is a lot of lag when it comes to typing in a FreeRDP session. I will type something and the text will register slowly. In fact, the entire FreeRDP session display is laggy and this becomes apparent when you span the undocked RDP window across 2 monitors and use a high resolution of something like 3838x1018.

I also found that the clipboard doesn't work in a FreeRDP session.

Aside from those issues specific to FreeRDP, I have noticed that my original issue seems to have disappeared in a FreeRDP session. I mentioned in a previous post that I'm using a keyboard OSD tool to display keypresses in both the local session and the remote session. Let's say my mouse is focused on my local session. If I'm typing something in my local session, the keyboard OSD tool running in the ActiveX RDP session would intermittently show the keypresses, as if I'm typing into the remote session.

Now, let's say we have the same scenario where I'm typing in my local session, but I have a FreeRDP session running in the background instead. In this case, the keyboard OSD tool running in the RDP session would not show any keypresses outside of the session. The tool would only show keypresses in the RDP session itself. This is good and this is the expected behaviour.


UPDATE 4:

I installed a fresh new copy of Windows 10 and a fresh new copy of RDM (latest beta). I did not configure RDM with any settings at all. I'm using the vanilla setting and simply created an ActiveX RDP entry, specified the username and password and that's it. The only setting I have enabled is the "Windows key on the remote computer". I was able to replicate the issue related to the ghost keypress of the Win key. So something is bugged with this particular setting.



UPDATE 5:

I'm now using the Remote Desktop from the Microsoft Store (not the legacy version, the new one with the red/orange icon). I'm not getting any ghost keypress issues here and I can still use Win+KEY combination. However, I much prefer to use RDM and would prefer someone take a look at the "Windows Key on the Remote Computer" setting and fix it properly.

Any update on this one please?

Hello,
Thank you for the multiple updates. It does not seem to be an easy bug to fix. It seems to be related to the ActiveX. I will analyze your results and try to work on that this week.

Regards

I think the best way for you guys to test is to use the Keyboard OSD tool that I mentioned in my previous post. This will show you the keypress registered in either your local or remote session (depending on where you're running the tool from). Use the config I shared to quickly get started.

The test is very simple and straightfoward. Open a RDP session with the "Windows key on the remote computer" setting enabled. Click your mouse in your local session and then click into the remote session. You should find that the Keyboard OSD tool will show a "Tab" keypress (despite that you didn't press Tab on your keyboard). Either that, or it will show LWin (left Windows key). If you do the same test using another Remote Desktop app, you won't get this issue. If you disable the "Windows key on the remote computer" option in RDM, you won't get this issue.




UPDATE:

I just tested MSTSC. I can still see the "TAB" key shown by Keyboard OSD whenever I click into the RDP session. But I can't seem to replicate the ghost key issue.

I'm also testing RDCMan right now and I get the same Keyboard OSD popup for the Tab key, but no ghost key issue so far. It seems like it's just RDM that's causing this issue.


I've been a long time using of RDM and would love to keep using it. I've had this issue since many years ago, regardless of what machine I'm on and what Windows version I am on. I've just ignored the issue throughout the years but now that I can replicate it consistently and know it is to do with RDM, I'd really like to get to the bottom and fix it once and for all...

Any update please?

I have been using RDCMan for over a week now and haven't had any of the ghost keypress issue that I discussed. The issue, as I have explained above already, is definitely caused by RDM. I love RDM and have been using it for years, but this is a huge breaking bug for me. I don't want to have to type something and have to deal with random windows or shortcuts opening because there is a pressed key in the background.

Hello,
I'm still trying to find a workaround. This problem is well know and does not just affect RDM.

https://support.royalapps.com/support/solutions/articles/17000027818-control-windows-or-alt-keys-stuck
https://control.product.connectwise.com/en/communities/6/topics/2375-windows-key-stuck-on-host-client

That being said, I try to find the root cause that triggered the issue in our application. Could you try to toggle the value of AllowBackgroundInput in your RDP properties? I also just read again the whole threat but I want to confirm, Do you reproduce the issue if you are not undocked?

Regards

Thanks for sharing those links, interesting read. Looks like the issue has been ongoing for some time and the lastest update is as recent as last month...

This issue has been happening in RDM since years ago, I don't remember exactly what version though...

How do I edit allowBackgroundInput? I checked default.rdp in Documents and don't see this property. I also checked the RDP entry in RDM and also in the RDM option, but I don't see this either. I've Googled a bit and can find references to allowBackgroundInput, but they are all scripting related....

If you were referring to this in the screenshot below, then I have already disabled it during my testing...




The issue can be reproduced regardless if I'm using embedded/docked or undocked.

I think, the easiest workaround would be if you guys can improve FreeRDP. I don't have the issue when using FreeRDP, but the performance is terrible and the clipboard doesn't work. If you can improve the performance so that an undocked RDP session can span across 2 monitors with a high resolution, and have the clipboard working, then that would be great.

BTW, I found this and looks like the issue dates all the way back to at least 2007?
https://social.technet.microsoft.com/Forums/en-US/cbaae74e-8311-4a46-a842-31dcdd6878dc/windows-key-quotstuckquot?forum=winserverTS

Hello,
Thank you for your posts. Just to let you know that we have created more 5 different tickets to improve RDM especially the integration of FreeRDP and the toggle of "Windows Key on the Remote Computer" in the title bar. We have developer that will start working on them this week.

Regards

Hi, it has been a while since your last update. Just wondering has there been any progress on this?

Hello,
I'm still struggling to find a workaround and the possible root cause of the problem but at least we have added the Toggle Keyboard menu in the undocked system menu.

Regards