Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crashes caused by "Unsupported key press" #524

Open
PoloniumRain opened this issue Aug 4, 2024 · 11 comments
Open

Crashes caused by "Unsupported key press" #524

PoloniumRain opened this issue Aug 4, 2024 · 11 comments

Comments

@PoloniumRain
Copy link

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
Copy link
Owner

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
Copy link
Author

PoloniumRain commented Sep 9, 2024

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

I'm using the default dinput setting.

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

@schellingb
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants