Crash on close in Windows 7

[prietveld]

In v0.110 both the opengl and d3d9 version of puNES crash on my Win7x64 PC after closing the emulator, either via the window's 'x' or the menu item 'Quit'. There are two subsequent '... has stopped working' prompts upon close. After a crash or two Windows applies automatic compatibility settings, and I noticed 'disableusercallbackexception' is what is added to the registry for punes64.exe (and the error prompts do disappear after that). I tried both the portable and local configuration with the same problem. Other than this annoyance, the emulator works perfectly fine. Hopfully something that is fixable?

Edit: the crashes seem to always happen after having loaded a rom, sometimes after having just opened the settings menu, and rarely after opening and immediately closing the emulator.

Edit 2: walked back through all the released versions, and the crash issue was introduced with v0.105. v0.104 still worked without issue.

[punesemu]

Hi prietveld, thx for the report.
I can't reproduce the problem with my windows 7, I'll do some more tests and let you know.

Edit: Can you send me all the *.cfg files of the emulator?

[punesemu]

I can not reproduce the problem in any way, I have tried on several computers with windows 7 but the crash has never occurred. I've looked at the differences between version 0.104 and 0.105 and the only thing that seems plausible to me is the change made to audio handling in xaudio/snd.c although I can't figure out what could be causing the crash. I need your help to try to understand.

[prietveld]

Sorry for the delay! I have attached all the cfg files from a freshly unpacked, freshly crashed v0.110. To clarify, the crashes are always on close, two after each other, and they always occur after having opened a rom beforehand, rarely after just opening and immediately closing the emulator.

I can imagine it has something to do with the audio backend... I have a Creative X-fi Titanium running Creative's last official drivers, which might be somewhat out of the ordinary with most people having onboard audio.

If there is a debug build or something I can run here to help out, let me know!

cfg.zip

[punesemu]

Even with your cfgs the problem doesn't happen. Do you think it's possible to do a remote assistance with the teamviewer to be able to do some tests?

[prietveld]

No, sorry. But any tests I can do 'offline', no problem!

[punesemu]

It won't be easy but let's try. Try this version (d3d9 win64) by starting it from cmd and send me the debug messages that appear in the terminal.

punes.zip

[prietveld]

Ok, I added the debug log. Didn't see any entry added when the program closed / crashed, so I hope there something useful in there. By the way, I dropped the new exe in a v0.110 folder, as it seemed to need a couple of dlls. I assume that was the idea?

log.txt

[punesemu]

as it seemed to need a couple of dlls. I assume that was the idea?

This is just a debug executable but still it needs all the dlls present in the original 0.110 zip.
I was hoping that the log would give me some more information on where the crash occurred but unfortunately it says absolutely nothing, everything is normal so we have to walk blindly. I updated the debug zip making two changes, can you do the same thing and send me the new log? If you then realize that this version no longer crashes I'd be delighted.

punes.zip

[prietveld]

Thanks for looking into this, I really appreciate it! Still the crashes with this version, unfortunately. I will attach the debug log again:

log2.txt

[punesemu]

The log tells me that the main emulator thread quit correctly and this makes me think the audio thread is not closing properly for some reason. Let's do another test by disabling audio handling in the code.

punes.zip

[prietveld]

No sound, but still crashing. Here's another log...

log3.txt

[punesemu]

Unfortunately, without being able to reproduce the problem and without being able to do tests, I can do little. I've tried checking for the obvious but without deep debugging I'm not able to figure out what's going on. I'll do some more tests on some other windows 7 hoping it happens to me. Out of curiosity, have you tried the 32bit version?

[prietveld]

Interesting, the latest 32bit version does indeed not have the crash. Does that clue you in on the underlying issue?

[punesemu]

Unfortunately not, in fact I find it even more strange but I can't do anything else without debugging.

[punesemu]

Between version 0.104 and 0.105 I also updated the Qt static libraries bringing them to 5.15.0 for the 64bit version and I'm starting to think that those are the ones that crash. In the 32bit version I use 5.6.3 to maintain compatibility with old Windows.

[punesemu]

You can try this version? I have updated Qt5 to 5.15.8.

punes.zip

[prietveld]

Hey hey, no more crashes! Tried playing a couple of roms and no issues so far, this seems to have fixed it. Here is the log file in case it tells you something:

log4.txt

[punesemu]

I have not made any changes to the emulator, I have only updated the QT5. As I thought it was 5.15.0 that created the problem.

[prietveld]

Ok, thanks for working with me on fixing this. If updating QT doesn't lead to any adverse effects for other users I'll be happy to see the fix in a future release. Thanks!

[punesemu]

I have to ask you one last favor, can you try this version? Before starting to use the new qt I want to be sure that the WIP versions work correctly too.

https://github.com/punesemu/puNES/suites/10451319169/artifacts/517279898

[prietveld]

Works for me, no crashes with this version.

[punesemu]

Good, many thx for the support.

[prietveld]

Hi. I lost the download of this WIP version. Could you maybe re-upload it (or probably better: the most recent WIP version)? Or is there a new release imminent? In that case I can wait for a bit.

[punesemu]

Hi prietveld, you can use the last WIP, it's already compiled with the Qt5 5.15.8. For now I won't release new versions, I'm rewriting a part of the emulation core and it will take some time before I have something stable.