+13
Planned

Windows key stuck on host client

Dylan 1 year ago updated by vcayenne 4 weeks ago 17

Our users occasionally report that the Windows key is stuck on the host computer after using it in a remote control session. Windows will act like the key is still being held even outside a remote control session. Pressing the Windows key a few times solves the 'stuck' key.

Problem can occur after using the Windows key in a remote session to launch Explorer (Win + E) for example.

This problem started to occur after upgrading to 19.0.23665.7058

Host computers are running Windows 10 1809 October 2018 Update x64

ConnectWise Control Version:
20.4
Server Affected:
Host Client Affected:
Guest Client Affected:
+1

This is a huge pain in the rear, please fix.  

+1

I have this issue after working in an RDP session and then switching Windows 10 Virtual Desktops Using the WIN + CTRL + Left or Right Arrow.

It only started happening with the last ConnectWise Control update, it's super frustrating for example if I type letter D all my open windows become minimized equivalent to pressing WIN key + D

The problem still persists after upgrading to 19.1.24050.7079

This issue still exists on 19.1.24050.7079 Windows Build 1803. If I can upgrade to Build 1903 I will report if the issue still exists here.


Hi Arussel, thanks for chiming in.

I'm currently on build 1903 and can confirm the issue still occurs.

+1

As Dylan mentioned issue still occurs on Build 1903. I called support yesterday and submitted a ticket. It ended in them informing me that this is a known bug and their Dev. Team is allegedly investigating the issue.

For those of you who are experiencing this issue because you utilize Windows Virtual/Multiple desktop feature. There are other third party multiple desktop applications that can be used in the mean time (Which can utilize hotkey combinations that do not require the Win Key). I have only tested VirtuaWin. Its not the best but it is very light weight. 

Is this still being worked on?  

+1

I'm having a similar issue only the Control key thinks it is stuck. I dont experience any symptoms as the host but the user can not type, even in the chat box. If they do type and happen to type a letter that has a command associated with it (like P for Print) it becomes problematic.

Is this still being addressed? Is this related?

I can confirm that this is still occurring I'm on 1903. 

Still having this issue 1909

Well I'm happy I'm not alone, this has been happening for well over a year.  Would absolutely love to get this fixed.  It happens to me everyday.

I have been dealing with this for a year as well. Using multiple desktops is crucial to having the landscape necessary to do my job effectively and this is a major pain in the rear. I have several technicians who also experience this as they utilize this W10 feature as well. Curious if anyone has tried not changing desktops during an active session and if that avoids the issue. I am trying to get a work around out to my team.

Thanks!

I've found no work around, I even tried rebuilding my PC and no go.  This started happening to me when the upgrade came out that put the bar at the top that reads " Ctrl-Alt-Del is available to be sent to this device  Send Ctrl-Alt-Del  Dismiss" 

I wonder if we were able to disable that if this stuck key issue would go away.  I don't think that bar is necessary.  The toolbar can be used to do that.

Is everyone having this issue using the on premise install?

the issue lies in the ability to use multiple desktops in W10. When you have a session open and then Ctrl + Windows + left(right) to change desktops is when the issue occurs. I am testing whether I get the same issue if I do not change desktops while actively using a session. Will update later. 

In our case, it's the Shift key that sometimes gets stuck and at other times it happens with the Ctrl key.

This is also a problem for control from a Mac as use of the Mac's Command key is interpreted as the Windows key being pressed and staying "Stuck". I wish either for a fix or that there was an indicator of the current Windows key state. It's risky pressing keys when the Windows key is stuck on in a session and you don't know it. Especially when in the course of troubleshooting a client's problem, you're tasked with reproducing specific steps to evidence a problem. Or trying to avoid disrupting their current setup while performing a necessary driver install, for example.