Crashes caused by "Unsupported key press"

[PoloniumRain]

When recently testing many games for #519 i found that 4 or so games would crash when pressing certain keys/mouse buttons and Game Focus was not enabled.

When a crash happens the game will completely lock up most of the time, but other times it will crash back to the DOS command prompt and the sound will be stuck in a short 0.5 second loop. RA doesn't lock up though, so i can restart the game, which will fix the issue.

The problem with replicating this is that i've mostly forgot which keys/buttons i pressed whenever this has happened, but it always happens by pressing a certain button on my Razer Naga Pro mouse, and this button has been remapped to Volume Up in the Razer Synapse software. Obviously this can't be replicated without at least having a Razer mouse and this software. But i can consistently get the Quake II DOS backport to always crash when pressing the Volume Up button on this mouse. I also remember a game would crash simply by pressing the arrow keys, but can't remember which game.

Here is the Q2 crash from the log file:

[libretro INFO] [DOSBOX LOG] DMA segbound wrapping (read): 0:1ffff size 1x [1] wrap ffff
[libretro WARN] [DOSBOX] Crash: Unsupported key press
[ERROR] [Environ]: SET_MESSAGE_EXT: DOS crashed: Unsupported key press

This log isn't from a debug build, because annoyingly the DBP debug build does not crash with Q2! lol. It's only when i compile a "Release" build that the Q2 crash happens.

This "Unsupported key press" crash isn't a new problem either. For a long time now (maybe 3+ years) it has been a problem, but the crashes were rare so i didn't bothered reporting it, but recently it's been happening more due to the many games i've been testing. Again, it only happens when Game Focus is NOT enabled.

It will happen with:

• RA 1.19.1 and far older versions, including clean installs with default settings.
• The latest DBP commit, and very old DBP versions. Either with default or custom settings.
• Windows 10 and 11.
• Any keyboards i've tried, which all use a UK layout (it makes no difference what Keyboard Layout Core Option has been selected).

[schellingb]

I really have no idea how it could be happening.

Somehow an unknown key arrives inside the emulator code at a point where that really shouldn't be happening. I can easily not make the emulation crash, just do nothing when that happens, but I'd really like to know how it comes to this.

It happens 100% when pressing that certain button on the Razer Naga Pro mouse? Or is it somehow random?

[PoloniumRain]

It's 100% of the time, at any point in the game.

I've just found that DBP is detecting multiple key presses simultaneously. So when i use the volume wheel/knob on my keyboard, i can increase Windows 11 volume without any lock ups or crashes with Q2DOS. But when i do the same thing with a button on my mouse, that uses the exact same "Volume Up" Windows command, it then crashes Q2DOS. I've also now discovered that, for this specific mouse button, it locks up Q2DOS 100% of the time when Game Focus is either enabled or disabled. It makes no difference.

The other key being detected is the right arrow key. Because when on the DBP Start Menu, if i press the same Volume Up mouse button, instead of just increasing the Windows volume, it will also input the right arrow key, because it's also changing the Auto Start and Skip Frames. No other core or any software does this, but DBP somehow detects a right arrow key press. Again, enabling/disabling Game Focus makes no difference.

It might also be detecting other key presses apart from the right arrow key, because in QDOS (not Q2DOS), if i hold down the same Volume Up mouse button, it will move me backwards during gameplay, but very slowly, as if the down arrow key is quickly being tapped, instead of held down. Game Focus still makes no difference.

I know this sounds like it could somehow be a problem with my mouse, but pressing a key while Game Focus is not enabled can also lock up both Windows 98 and DOS games in the same way. The only 2 differences are that it only happens when Game Focus is not enabled, and it happens very rarely. It's random. Certain keys are more likely to cause a lock up/freeze. This also happens with different keyboards and a laptop, which are not Razer products.

Being as keys do different things when Game Focus isn't enabled, maybe that's interfering? Like in QDOS i've mapped W to move forward, but if i press W while Game Focus is not enabled, it will instead bring up the DBP Action Wheel. Most keys are inconsistent like this with DBP when Game Focus isn't enabled, but then some other keys like Enter will always work as expected. That could explain why some keys are more likely to cause a lock up. I've never had a crash/lock up with keys that always work as expected when Game Focus is disabled, like the Enter key.

[schellingb]

All these cases you mention end with

[libretro WARN] [DOSBOX] Crash: Unsupported key press

or

[ERROR] [Environ]: SET_MESSAGE_EXT: DOS crashed: Unsupported key press

in the log?

[PoloniumRain]

Always for the mouse button.

As for the key presses, I'm not sure if it was 100% of the time. So today i've been trying to recreate it, but being as it's rare and totally random, i can't get it to happen so far... But i'm certain that for at least some of the lock ups/freezes i see the "Unsupported key press" pop-up notification from RetroArch.

[schellingb]

To maybe figure out what that certain mapped button on the Razer Naga Pro does I wrote a simple input event logging tool. Can you try to do this for me:

• Get msgtest-20240919.zip
• Run msgtest.exe
• It opens a small window and a logging console window
• Move the mouse over the small window (titled "Window Message Tester")
• Press SPACEBAR on the keyboard (to start logging)
• Press that certain button on the Razer Naga Pro mouse which has been remapped to Volume Up in the Razer Synapse software
• Press SPACEBAR on the keyboard again (to stop logging)
• Copy the text out of the console window into here

Hopefully it logs something like this:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

msg=0x100 (WM_KEYDOWN) hwnd=0x3e84f9e wparam=0xaf lparam=0x300001 result=0x0
msg=0x101 (WM_KEYUP) hwnd=0x3e84f9e wparam=0xaf lparam=0xc0300001 result=0x0

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[PoloniumRain]

Here's the results for the Volume Up mouse button:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

msg=0x100 (WM_KEYDOWN) hwnd=0xa81bee wparam=0xaf lparam=0x1300001 result=0x0
msg=0xc029 hwnd=0xa81bee wparam=0x10 lparam=0x0 result=0x0
msg=0x101 (WM_KEYUP) hwnd=0xa81bee wparam=0xaf lparam=0xc1300001 result=0x0

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And this doesn't cause a crash so far, but just in case these buttons are doing something weird, here's the Volume Down mouse button as well:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

msg=0x100 (WM_KEYDOWN) hwnd=0xa81bee wparam=0xae lparam=0x12e0001 result=0x0
msg=0xc029 hwnd=0xa81bee wparam=0x10 lparam=0x0 result=0x0
msg=0x101 (WM_KEYUP) hwnd=0xa81bee wparam=0xae lparam=0xc12e0001 result=0x0

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[schellingb]

Thank you! So it is quite similar to what I get from pressing just a regular volume up keyboard key. One more thing, can you check in RetroArch what you have set under Settings -> Drivers -> Input?

[PoloniumRain]

I'm using the default dinput setting.

And i just tried sdl2 and raw .. Both of them also cause the exact same crash.

[schellingb]

Interesting. I can't reproduce it by faking an input event that matches what your mouse is emitting so I'm still a bit lost. I just committed the only idea I have for what could be wrong. Can you try a build including the latest commit I just did?

[PoloniumRain]

That's fixed it! :)

I've tried dinput, sdl2 and raw... None of them crash any more. It also fixes the right arrow key input which was happening on the Start Menu when pressing the Volume Up mouse button.

As for the random and rare crashes caused by keyboard key presses, i'll just have to wait and see if these still happen, because i can't reproduce them, but after spamming loads of keys without Game Focus being enabled, i haven't had any problems so far. So i'll give it some time and if things continue looking good then i'll close this issue.

[schellingb]

Ah, now it all makes sense 😅
libretro/RetroArch#16502
This happened 4 months ago and it was what extended the range of possible key events which then all had the possibility of crashing our core due to the missing filter of unknown keys. Glad this main issue is fixed. There's still the random crashes you mentioned happening since 3 or more years but I'm quite sure that is something different altogether then.