Ticket #2613 (reopened defect)

Opened 5 years ago

Last modified 7 months ago

Host key (ctrl) sometimes gets stuck down in Windows guest

Reported by: myxiplx Owned by:
Priority: minor Component: other
Version: VirtualBox 2.0.4 Keywords: ctrl host key stuck
Cc: Guest type: Windows
Host type: Linux

Description (last modified by michael) (diff)

Not all the time, but regularly enough to be a nuisance, the host key gets stuck down within the guest after it's been used to free up the mouse. Does VirtualBox always send the "key-up" message to the guest after the host key has been pressed?

I'm running VirtualBox full screen on my second monitor, and often hit ctrl so that I can leave the virtual machine running, but free the mouse so I can continue working on my primary screen.

After doing this, about a quarter of the time, I go back to the guest to find the control key stuck down. It means typing is impossible, and unlocking a machine with your password is a nuisance until you spot what is going on. Tapping the left control key on the keyboard does seem to free it up again.

I also run the VMware Infrastructure Client within this virtual machine, and that requires the use of Ctrl+Alt to free the mouse from its client windows. A couple of times now that has wound up locking the mouse and keyboard within VirtualBox when I come back to it, and it appears to coincide with times the control key has gotten stuck down. I'm reporting this here instead of as a separate bug as I think it's just another symptom of the same problem.

For now I've changed my host key to the Scroll Lock button, that appears to be a useful workaround for now.


keylook.exe Download (18.0 KB) - added by michael 7 months ago.

Change History

comment:1 Changed 2 years ago by arencambre

I'm running into the same problem, 3 years later. :-) Has there been any progress on this?

comment:2 Changed 20 months ago by rrt

I have noticed the same problem with Alt getting stuck down in the guest after using Alt+Tab in seamless mode with keyboard capture switched off, so that the host always gets the keystroke.

Using Ubuntu 12.04 host, Windows 7 guest.

It can be cleared by pressing Alt again in the guest, but it makes seamless mode use unreliable.

comment:3 Changed 20 months ago by rrt

I can confirm the same problem in fullscreen mode (again with keyboard capture switched off).

comment:4 Changed 19 months ago by Bo

This has happened to me since about the 4.1.16 release. I run Ubuntu as my base system and use Windows 7 as the VM. Windows 7 behaves pretty well. The toggling from Windows back to Ubuntu is not as smooth as it used to be and the workspaces now behave oddly in 4.1.22. I wish at had stayed with the earlier variations of release 4. Still, a great product and thanks for the hard work.

comment:5 Changed 19 months ago by BJCubsFan

I have seen this problem using an Arch linux host and a Windows XP guest. The only way I could solve this was to pause and unpause the host machine. After that, the problem went away!

comment:6 Changed 19 months ago by Dtremblay

Same problem here. Host Windows 7 and Guest Windows XP. The key up message seems to get lost somewhere.

comment:7 Changed 16 months ago by rogerdpack

Dunno if it's the same problem, but with Windows 7 + Linux guest, sometimes when I "leave" the guest, the ctrl key for windows thinks it's down when it's not! (often enough to be annoying...) thanks! -r

comment:8 Changed 12 months ago by mosimu

This sounds like Sticky Keys. The following might help:

Open the Control Panel on Windows 7 host > Ease of Access > "Change how your keyboard works" > "Set up Sticky Keys"

Uncheck the option "Lock modifier keys when pressed twice in a row."

When your Ctrl or Alt key is stuck on the host, you should be able to unstick by holding down both Ctrl and Alt at the same time, then releasing. This works because of the other option you see in Control Panel, "Turn off Sticky Keys when two keys are pressed at once."

comment:9 Changed 12 months ago by rrt

It's not StickyKeys, at least in my case (I'm not even using a Windows host).

Last edited 12 months ago by rrt (previous) (diff)

comment:10 Changed 12 months ago by michael

  • Description modified (diff)

If it is not sticky keys on the host then you should be able to make it go away (I am not suggesting that this is a solution to the problem) using the command line command "VBoxManage controlvm keyboardputscancode <code>", where "code" is the hexadecimal scan code value (PS/2 scan code that is) of the key which is stuck. This page<1> has a list of hexadecimal scan codes for all standard keyboard keys.


comment:11 Changed 12 months ago by michael

I have uploaded a test build which contains a fix which may possibly fix this issue.

comment:12 Changed 12 months ago by ccijwlrjqj

I've also noticed the ESC key to be stuck on the Windows host sometimes, after leaving a guest.

To work around it, pressing and releasing (after one another) the ESC, CTRL, and ALT keys on the Windows host works.

comment:13 Changed 12 months ago by Tsso2


It's so bad, I've developed a reflex to hit the windows key twice every time I switch out of the VM. But it's finally fixed! Thank you!

comment:14 Changed 12 months ago by michael

  • Summary changed from Host key (ctrl) sometimes gets stuck down in Windows guest to Host key (ctrl) sometimes gets stuck down in Windows guest -> fixed as of May 2013 in 4.2.x and later

comment:15 Changed 10 months ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

Fix is part of VBox 4.2.14.

comment:16 Changed 10 months ago by rrt

  • Status changed from closed to reopened
  • Resolution fixed deleted

In VirtualBox 4.2.14 on Linux the bug is still present, at least for the Alt key: pressing Alt+Tab to switch from a VirtualBox OS window to a host window frequently leaves Alt in a "down" state in the VirtualBox OS window. (I was unable to test the fix mentioned earlier in the bug as only a link to a Windows build of VirtualBox was provided.)

Last edited 10 months ago by rrt (previous) (diff)

comment:17 Changed 10 months ago by rrt

This bug could usefully be retitled: first, to note that the fix was for Windows hosts only, and secondly, that it was in 4.2.14. I suggest changing: "fixed as of May 2013 in 4.2.x and later" to "fixed for Windows hosts in 4.2.14".

comment:18 Changed 9 months ago by michael

  • Summary changed from Host key (ctrl) sometimes gets stuck down in Windows guest -> fixed as of May 2013 in 4.2.x and later to Host key (ctrl) sometimes gets stuck down in Windows guest

Indeed, you are right. What was fixed was a different bug on Windows hosts, whereas this one explicitly affects Linux hosts. Shame on me.

comment:19 Changed 7 months ago by rogerdpack

I for one am glad the windows bug was fixed (I assumed they'd be part of the same problem/fix, but I guess they weren't?). Anyway so now this ticket is specifically targeted to linux host having the same problem, which is apparently still present. Got it. Thanks for the fix though.

comment:20 Changed 7 months ago by michael

Is anyone currently affected by this issue on a Linux host? If so, is your issue exactly what is described in the ticket summary or something different? And if it is, what input/mouse focus policy are you using on your Linux host?

comment:21 Changed 7 months ago by rrt

I am affected by this issue on a Linux host. My exact problem is as described in comment 2 (i.e. I notice it with the Alt key rather than the Host key, but that's only because I don't use the Host key).

I use click to focus (which seems to be the default these days on most GNU/Linux systems).

comment:22 Changed 7 months ago by michael

I was not able to reproduce this with an Ubuntu 13.04 host and guest. Could you please give precise steps to reproduce with this combination if that is reasonably possible?

comment:23 Changed 7 months ago by rrt

As per comment 2, I'm using Ubuntu host (now 13.04) and Windows 7 guest. Alt gets stuck down in the guest almost every time I Alt+Tab away from the VM window to some other Ubuntu window; to ensure it sticks, make sure Alt is held down for about 0.5s (sometimes if I release it quickly it doesn't stick down in the guest). The effect is easily visible e.g. in Word 2013 in the guest, because the labels that pop up when you press Alt are still visible in the guest VM window after it's lost the focus.

comment:24 Changed 7 months ago by michael

Can you reproduce this with a Linux (Ubuntu?) guest too? I am wondering whether this might be some peculiarity of your Windows guest, as I was unable to reproduce it with an Ubuntu guest, but that sort of behaviour shouldn't depend on the guest system at all. And do you release the keyboard capture before Alt-Tab-ing away from the guest, or do you have it disabled altogether?

comment:25 Changed 7 months ago by rrt

I don't have any Linux guests. However, further experimentation shows that it seems to be a problem specifically with Word 2013 (it clearly previously affected some other application, probably Word 2003, which is what I had when I reported the bug.) Other apps (e.g. Chrome, Notepad) don't exhibit the problem.

I have keyboard capture switched off, precisely so I can use Alt+Tab to switch host windows, not guest windows.

comment:26 Changed 7 months ago by michael

From your description this sounds more like an issue with the application than with VirtualBox. If it were, the problem should exist for all applications. You might try out the "keylook" tool <1> which will show you pretty clearly what input the guest is getting.


comment:27 Changed 7 months ago by rrt

I am unclear how this could be a problem with the application. This problem does not occur when the application is not running under a VM, it's not supposed to be the application's problem that it is running under a VM, and it doesn't seem very likely that the app would behave differently in this instance when running under a VM. Equally, assuming that all apps should behave the same seems like speculation to me; and clearly, some other apps suffer the same problem, as I wasn't running Word 2013 when I first noticed the bug.

I tried running KEYLOOK.EXE in my Windows 7 guest, and got the error: "The version of this file is not compatible with the version of Windows you're running." (I'm using Windows 7 64-bit, and an alternative error message from running the program from cmd.exe suggests that's the problem.) Searching didn't find me a 64-bit compatible version.

comment:28 Changed 7 months ago by michael

I found a version of keylook.exe which worked on a 64-bit Windows 7 and tested it myself. The guest indeed sees the "Alt" key up event, but I see that we also send another, spurious event before that one. Perhaps that is what is confusing MS Word.

comment:29 Changed 7 months ago by michael

Checking our source code I see that the spurious key release event before the "Alt" key up is there to stop Windows from seeing "Alt" pressed and immediately released and triggering unwanted actions, such as activating the menu (which usually happens if "Alt" is pressed and released). Unfortunately the event code we send used to only be used an error code, but is now also used by Brazilian keyboards (was that understandable?), which may be what is confusing Word. Not sure what the best solution is here, as you probably don't want your menu activated when you "Alt-Tab" out of the guest, but you probably don't want an "Alt-Tab" inside the guest either. And we can't hide the original "Alt" key down, as we do not know in advance that it is part of an "Alt-Tab".

comment:30 Changed 7 months ago by rrt

Thanks very much for continuing to investigate this problem. Perhaps you could post here (or even add to the VirtualBox documentation) a link to the Windows 7 version of keylook, as it sounds useful for debugging other key problems.

I am using a UK keyboard, so that code only run for Brazilian keyboards should not be a problem for me. I also cannot see why sending two key up events should be a problem, unless there is a bug in Word. Does the fact that timing seems to be important (i.e. if I hold down Alt for < 0.5s, I often don't get the problem) suggest any other lines of thought?

Just thinking about the particular problem here, I am unsure why it is quite so complicated. It would seem that what is needed is something like this:

  1. Modifier is pressed with guest OS focussed, key down event is generated.
  1. Non-modifier is pressed, and key combination is trapped by host OS; VirtualBox detects this situation, and sends a key up event to the guest.

I am unsure what the benefit of the extra key up event is: if I hold down Alt and wait for 1s before pressing Tab, then of course the guest should receive Alt keydown, and the Windows menus should activate. When I press Tab, that combination is trapped by the host, so will never reach the guest anyway. If the code is correct, it sounds like it is designed to deal with some other situation. In particular, I don't see how you can send the "spurious" Alt keyup event "early" enough to prevent Windows from e.g. displaying menus, as it seems to me the earliest you can send it is at the time when you can send the "correct" keyup event.

comment:31 Changed 7 months ago by michael

The source code of keylook is at:

Windows does not know that you have a UK keyboard, only that you are using a UK layout - but Brazilian keyboards are physically different, and the only way Windows can tell you have one is when it sees key events for keys which don't exist on other keyboards. I will upload a build of keylook which works on Windows 7 64-bits.

Changed 7 months ago by michael

comment:32 Changed 7 months ago by michael

Just to test this to see if that really is the problem I have created a couple of special builds (which I haven't actually tried myself...), one of which completely removes the additional key event, and the second of which replaces it with a down and up of the "ESC" key. I can't say at this stage whether we would actually make such a change, as I am not aware of anyone else who has issues with this, but changing it might well affect people. Still, I am interested in your feedback.

Note: these are "makeself" shell script installers. You should uninstall your current VirtualBox installation before installing one of them. They can be uninstalled using the uninstaller script in the "/opt/VirtualBox*" folder. You should download them using right click and "Save as", or your browser may detect them as text and try to show them in a tab.

comment:33 Changed 7 months ago by rrt

The first image (88967) produces behavior that I can reproduce with Notepad (and Word 2013 behaves the same): every time I press Alt+Tab, Windows behaves as if Alt had been pressed and released, i.e. the menus are highlighted the first time, unhighlighted the second time, etc. There is no dependence on a delay etc. This is not quite what I want, but is at least now consistent across applications and regardless of my timing.

The second image (88970) does exactly what I want: the Alt keystroke is effectively cancelled by the Escape each time I leave Windows.

comment:34 Changed 7 months ago by Willie

I can confirm this bug on Virtualbox 4.2.18, running Arch Linux 64 bit, Host OS is Win8 64 bit. I managed to reduce it a bit by setting scroll lock as the host key, but a stuck ctrl key still happens every now and then.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use