Crashing inside 2.0.22 SDL_DYNAPI_entry

Hi, folks!

I’ve recently upgraded my game’s SDL2 build from version 2.0.12 to 2.0.22 (I was certain I had upgraded to 2.0.18 months ago, but apparently not?). Since this update, I have begun getting some SDL2 crash reports from Windows users, where it previously had been rock solid.

We don’t have a 100% set of crash repro steps yet, but the crash happens in the middle of gameplay at seemingly random times, often after minutes or hours of play. Some players see these crashes frequently, some rarely, and others (I suspect the large majority) don’t ever get it at all. I’ve never seen it happen myself, even after quite a lot of testing.

I don’t have any real clues in trying to track it down, and since it doesn’t seem to ever occur for me, it’s hard for me to debug apart from what I can get in our crash logs.

The crash seems to only happen when we call SDL_SetRelativeMouseMode(SDL_TRUE) (weirdly, I’ve never seen a crash report happen when we call it with SDL_FALSE). Our crash dumps give us this callstack for the crash:

MT2.exe caused an Access Violation at location 00007FFEC10D5826 in module SDL2.dll Writing to location 0000000000000040.

AddrPC           Params
00007FFEC10D5826 00000001118B1180 0000000000000017 0000000000000017  SDL2.dll!SDL_DYNAPI_entry
00007FFEC10D5E67 000000002935AA50 0000000007441A01 0000000001ABFDB0  SDL2.dll!SDL_DYNAPI_entry
000000000098338D 0000000000000000 000000003F800000 0000000000000000  MT2.exe!vsInput::CaptureMouse
<... other stuff inside the game itself ...>

(I’m assuming that we’re missing debug symbols for SDL2.dll, and SDL_DYNAPI_entry is actually just the only symbol the crash handler was able to find, rather than actually being where the crash occurred)

This is using the SDL2 libraries from the official release, from this package on the site: SDL2-devel-2.0.22-mingw.tar.gz (all our Windows builds are compiled using mingw)

This happens for me both with and without setting SDL_HINT_MOUSE_AUTO_CAPTURE to false. (I figured that changes made to mouse capturing in 2.0.22 might have been part of the problem, but I’m still getting occasional crash reports after having set the hint to false to try to revert to older behaviour, so it might be entirely unrelated)

I’ve verified that when the crash happens, we’re dynamically linking against a real SDL 2.0.22 DLL; it doesn’t appear to be a case of an end-user providing a different DLL that’s getting used instead of the one we intended.

Does anybody have suggestions about what I should be doing next to try to track this down? I’m tempted to try backing us off to 2.0.20, but obviously that’s not a real solve for the problem, whatever the problem turns out to be.

Definitely would appreciate any input on stuff I should be trying/checking!

This sounds like this bug:
Fix NULL dereference in SDL_UpdateMouseCapture() while mouse is grabbed by fgenesis · Pull Request #5608 · libsdl-org/SDL (

I haven’t had a chance to investigate yet, but does that fix help you?


Wow, yeah, that really does look suspiciously like it might be the cause of the issue we’re seeing reported!

Unfortunately, we still don’t have a good set of reproduction steps to trigger the crash; it just gets reported maybe once or twice a day across the players of our ‘testing’ build (we haven’t deployed 2.0.22 to our main ‘default’ Steam build yet). I can try applying that patch to our SDL2 build and upload to Steam and see whether the rate of reports goes down.

1 Like

As an update on this, I’ve now had a new build of our game using SDL2 2.23.0 commit f9a9d3c8d (“Also restore previous capture window if CaptureMouse() fails”) in our game’s public test branch on Steam for the last 20 hours or so and haven’t had a single crash reported so far.

So I’m cautiously optimistic that the fixes in that commit (and the prior one) have fully solved the problem some of our players were running into!

Great, thanks for the feedback!

And with another 24 hours of no further crash reports, I’m much-less-cautiously optimistic that the fixes have worked! Thanks, @slouken !

The same bug became visible in dhewm3 (at least I think so): Crashes when exiting mars city · Issue #460 · dhewm/dhewm3 · GitHub
It crashes with 2.0.22, works with 2.0.20, and works again with current git, so I can confirm that the fix works :slight_smile: