Game crashes related to MSI Afterburner (SOLVED)

Bugs
#1

I’ve received the report below from a user:

Don’t know if anyone else has encountered this, but the game doesn’t seem to play nice with MSI Afterburner. Opening MSI Afterburner when the game is already open crashes the game. Opening the game when MSI Afterburner is already open… sometimes crashes the game, I think? Other times the on-screen framerate display just doesn’t work.

Not sure where to even begin with this but thought I would bring it up anyway. I have this error log from the user:

2020-04-14 01:08:06 (1586851686)
Crash [1.2.167] [96f7a5e4f617d5f6f4645f30a3e6ff656689435d]
Device Model : 
Device Language : en
Device OS : Windows 6.2
Signum [57005]
Userdata0 = []
Backtrace:
00007FF793B35B1C,00007FF793B35D08,0000000000E60B55,00007FFE2D6B006A,00007FFE30464B32,00007FFE3044C6D6,00007FFE3046121F,00007FFE3042A289,00007FFE3045FE8E,0000000180031920
 0 0x7FF793B33040 _snscanf_s <unknown>:0
 1 0x7FF793B33040 _snscanf_s <unknown>:0
 2 0xE39A70 alcCreateContext <unknown>:0
 3 0x7FFE2D6AFE80 UnhandledExceptionFilter <unknown>:0
 4 0x7FFE30463000 memset <unknown>:0
 5 0x7FFE3044C640 __C_specific_handler <unknown>:0
 6 0x7FFE30461100 __chkstk <unknown>:0
 7 0x7FFE30429EF0 RtlRaiseException <unknown>:0
 8 0x7FFE3045FE60 KiUserExceptionDispatcher <unknown>:0
 9 0x180031920 <unknown symbol> <unknown>:0
#2

Yeah, not really sure what to do here. @dapetcu21 have you seen similar reports regarding Interrogation? @Pkeod?

@JCash do you have any input?

#3

@britzl I have not seen this in our games.

@Alex_8BitSkull I PMed you a Steam key for FSR to give to the user, see if that game crashes for them too.

Are you generating debug symbols with your builds? You should be! If not create a new build with symbols also made, and get a crash report from them.

3 Likes
#4

Good advice!

#5

Thank you kindly, I will send it over to them to see.

I’m not generating debug symbols, but happy to do so in the future. A quick search to explain what they are leaves me a little but not much wiser. Should I always be generating debug symbols? Is there a cost?

1 Like
#6

Debug symbols are necessary to make non-vanilla crash logs useful to see what is going wrong. They do not have a real cost to generate, for release builds like you are doing with a live audience they are very important to generate and store.

1 Like
#8

If the engine crashes the debug symbols are used to turn a meaningless callstack of memory addresses into a list of names of the functions that were called when the crash occurred. This greatly helps when debugging. On some platforms the debug symbols are included inside the engine binary and on some platforms it is a separate file. On platforms where the symbols are included in the engine binary it obviously increases the size.

In release builds we strip the debug symbols from the engine, but we provide them as a separate file, which later can be used to symbolicate a crash, ie turn the memory addresses into function names.

For vanilla builds, ie builds without native extensions, we provide the debug symbols as downloadable files on our download server (d.defold.com). Files such as dmengine.js.symbols and dmengine_release.dSYM.zip are examples of such files.

For builds which include native extensions the debug symbols for the vanilla engine will not work. When you bundle your application you have an option in the Editor to “Generate debug symbols” and from bob.jar there is --with-symbols. The debug symbols will be downloaded together with your application bundle. You should make a habit of always generating debug symbols and storing these per released version of your game.

3 Likes
#9

That callstack looks weird to be honest. There’s no reason memset should call UnhandledExceptionFilter and then end up in OpenAL (alcCreateContext).

But as the others mentioned, what we’d like to see is the unstripped executable and also the _crash file from the user (although most of that data is in the post you have there)

2 Likes
#10

Creating a build with debug symbols creates another file called “dmengine.pdb”. Do I include that file in the build I push to Steam, or take it out? Just want to make sure either way.

Will this mean a new type of error log is created (_crash)? If so, where can I tell the user to search for it? If not, is there something additional I need to put in my code first? My game currently has a user set toggle option to use either Err for local error files or defold-googleanalytics to upload exceptions automatically.

#11

No need to upload it to Steam. Keep it around and make sure you know which Steam release the .pdb file belongs to!

This is always created when a crash happens. It contains the call stack. The callstack+dmengine.pdb allows us to get a better understanding of what’s going on.

You are already reading the _crash file somewhere right? Google Analytics for Defold reads it at least: https://github.com/britzl/defold-googleanalytics#automatic-crashexception-tracking

#12

Good to know! Do I need to set it one aside for each OS I build to, or are they all the same if the only difference is the target OS?

Yes, I think so. The info I posted at the beginning of the thread was from an Err-generated log. For GA I also believe it’s captured, like this example (not as pretty):

image
image.png383×624 35.8 KB

#13

One per OS!

:+1:

1 Like
#14

Also, on windows, the crash extension generates a _crash.dmp, which is even more useful to us, since that (and the exe plus pdb) allows us to debug the crash much more easily.

1 Like
#15

I’ve restructured the Debugging manuals a bit and included some of the information from the thread. There is now a new Debugging section in the menu on the left and a bunch of pages:

17

2 Likes
#16

Response from the user after testing FSR:

From the key you provided, I tried running both Fairy Solitaire and the remastered version.
Starting the game first, then starting MSI Afterburner, and vice versa.
For both versions.
They seemed to work fine.
The original version froze with a black screen the first time, but the next couple of times it worked.
No crashes.

#17

That’s great! Is there a default location where _crash.dmp is saved? If so that could be a useful thing to add to the manual as well.

#18

It’s not 100% clear to me if FSR (the other does not use the Defold engine) had issues?

What is your dependencies list?

#19

I asked for clarification and the answer is that FSR never had any issues. The black screen in the original happened only once, and the user was unable to reproduce it.

https://github.com/subsoap/defsave/archive/v1.2.0.zip
https://github.com/adamwestman/debeat/archive/debeat-2.2.0.zip
https://github.com/subsoap/defblend/archive/master.zip
https://github.com/britzl/defold-googleanalytics/archive/1.4.1.zip
https://github.com/britzl/defold-input/archive/2.5.1.zip
https://github.com/subsoap/err/archive/master.zip
https://github.com/subsoap/defos/archive/v2.4.0.zip
https://github.com/britzl/steamworks-defold/archive/2.0.0.zip

#20

I don’t see any NEs which stand out unfortunately. FSR uses more NEs.

Getting him to run a build which you have debug symbols ready for to get the crash file is the best lead right now.

2 Likes
#21

These are the only ones with native code, and both have been tested quite extensively as far as I know.

1 Like