Keyboard key sticks in "down" state, cannot be cleared

[Jwoithe]

I am running Protel 99SE (a graphical electronic schematic/PCB capture suite) in a 32-bit mswindows guest. The host OS is 64-bit Linux. When in PCB mode one can select a "component" and use the arrow keys to move that component around. If there is a long distance to move, holding down the applicable arrow key is common. The component is redrawn after each button press event.

If the arrow key is held down for longer than about 5 seconds, the key "sticks" down. Even after the key is lifted, the guest OS sees a continuous stream of key events (generated by keyboard autorepeat) and acts on these as best it can. CPU usage by VirtualBox increases to 100%. The guest OS becomes completely unresponsive to further mouse and keyboard events. Pushing and releasing the arrow key (or any other key) has no effect. The only way to recover is to use Virtualbox to send an ACPI power off event. This is eventually seen by the guest OS and it shuts down normally. Sending the event can take considerable time since VirtualBox's control window becomes very slow in the fault condition.

On one occasion during testing the ACPI event caused a dialog box to be displayed asking whether changes should be saved. The keyboard focus rapidly cycled between the three buttons in a leftward direction. Since it was the left arrow key that was pressed earlier on, this conclusively demonstrated that the key was stuck. No mouse or keyboard events were being processed in this case either.

This problem does not occur in VirtualBox 4.1.x. It was first observed in VirtualBox 4.2.x. It is seen in every version of VirtualBox from 4.2.x on, up to and including 5.0.20 (all tested on the same 32-bit Linux host). In the past we have worked around this by sticking with VirtualBox 4.1.x for this program. However, since this no longer works on recent Linux hosts due to ongoing kernel changes there is a need to move to a later VirtualBox. This key handling regression, however, is a show stopper.

The problem has been observed in both a win2k and winxp guest OS. It has been observed with 32-bit and 64-bit Linux hosts. It occurs with a USB wireless keyboard and a PS/2 wired keyboard (tested on the same machine). The problem is not dependent on the graphics card (it can be replicated using onboard Intel graphics and PCIe AMD/Nvidia cards, all with the open source drivers).

In VirtualBox 5.0.x, capping the VM's CPU utilisation to 70% does not change the behaviour.

The problematic behaviour has not yet been observed in any other software. It seems that Protel 99SE does something uncommon when handling these keyboard-induced moves. A graphical redraw is done in response to every key down event, so maybe there's something about the way these are handled by Protel 99SE.

[Jwoithe]

Since this is related to input event handling and was introduced at the same time as the problem described in ticket #15377, there may be a connection between these two problems.

[Jwoithe]

The problem is still occurring in VirtualBox 5.0.24.

Preliminary testing under VirtualBox 5.1.0-RC1 suggests that the problem might be resolved in this version. Testing will continue and further updates posted as appropriate.