ZDoom

latest psxdoomtc
latest gzdoom vintage (just downloaded)
map61 attack

playing/going thru options

stable freeze after 5-7 minutes

memory dump: https://drive.google.com/open?id=1cN3pc ... sToa2tY3rC

can provide teamviewer if needed

msinfo https://drive.google.com/open?id=1Sjtot ... pEd_kphPYL
app evt log https://drive.google.com/open?id=1uJrA1 ... Nj8NaBCU3M
app hang archive (mentioned in evt log) https://drive.google.com/open?id=1dqZxP ... UpJALcfFg8


specs

ASUS RoG Strix X470-F GAMING motherboard
AMD Ryzen 5 2600X CPU
2x8192 Kingston HyperX Predator HX436C17PB3K2/16 DDR4 RAM @ 3000 MHz CL17 (XMP)
MSI GeForce GTX 1060 GAMING VR 6G GPU
Creative Sound Blaster X-Fi Platinum Fatal1ty Champion Series soundboard

OCZ ARC100 120 GB SSD (win10 1803 pro x64)
Samsung HD-103UJ 1000 GB HDD (zdoom)
Seagate ST2000DL003-9VT166 2000 GB HDD
Seagate ST2000DX001-1CM164 2000 GB SSHD

configs https://drive.google.com/open?id=1IiOXx ... 0djBGvvf1X
MODS - configs for PSX Doom TC Customizer

gzdoomg3.7.2_legacy 64bit (2019-01-20 11:43:49 +0100)

Creative Sound Blaster X-Fi Platinum Fatal1ty Champion Series soundboard

actually it is "Creative Sound Blaster X-Fi Titanium Fatal1ty Professional Series"
please update Message #2

As a quick check, could you please try to enable VSync? Also, why do you use legacy/vintage build with quite modern hardware?

_mental_ wrote:As a quick check, could you please try to enable VSync? Also, why do you use legacy/vintage build with quite modern hardware?

VSync was enabled during previous attempts -- I disabled it (that's why it's off in the config), but it didn't make any difference. The problem occured regardless of VSync setting.

I think I have also tried QZdoom (renamed to GZdoom -- app changed its icon immediately thereafter) -- with same "results", so I guess that's why I decided to move on to Vintage builds.


UPD:
Same results using latest Modern build -- but now it froze after much less time -- like 2 minutes.
vsync enabled.


only crash dump created https://drive.google.com/open?id=1rwLjU ... 2nKDCfFIVH
no entries in App event log

taskmgr -- wait chain analysis -- gzdoom.exe is in deadlock.

gzdoom.exe (pid 12340) thread 14660
|_gzdoom.exe (pid 12340) thread 8740
.....|_gzdoom.exe (pid 12340) thread 14660
gzdoom.exe (pid 12340) thread 8740
|_gzdoom.exe (pid 12340) thread 14660
.....|_gzdoom.exe (pid 12340) thread 8740

Prepare to buy some new hardware soon. This sounds like some component in your system is coming close to the end of its lifespan.

The system is less than a year old, CPU and motherboard released less than 9 months ago. Are you really sure? What Component should I replace?

Maybe there's some kind of Debug mode in gzdoom? How can I collect Verbose logs or something? I cannot even get to "Send GZdoom crash report" stage.

According to the second dump, it was deadlocked in openal32.dll. Just out of curiosity, will it freeze with -nosound command line option?

Actually the sound card is the only old component (besides few hard drives). Thanks for the guess.
Makes sense because it's OpenAL device.

Still haven't tried with No sound.


Tried the following instead:
Deleted all Configs
Played clean doom2.wad fine
Played doom2+psxtc.pk3 fine
Played doom2+psxtc+psxtcmus.pk3 fine

(Not using psx doom customizer)
so far so good, no freeze.
Maybe I'll be able to "pin-point" the culprit (problem PK3/setting in gzdoom.ini)

Freeze now appears randomly, or doesn't appear at all

First, it crashed after changing some options, including switching OpenAL device from Default to "OpenAL Soft on SB X-Fi (B)" and performing writeini shortly thereafter (sorry -- no dump)

When Sound Device was Default, don't remember encountering any crashes. But that's the only device -- "OpenAL Soft on SB X-Fi (B)", which should be used when Default is selected.
Maybe it's just a coincidence (I was impatient and changed openAl device to "OpenAL Soft on SB X-Fi (B)"), but "after" does not mean "due to" here, IMO.

Most recently -- used ini based on PSXDOOM.INI with some changes (writeini) from previous crash

I was playing with Resolution Scale

Caught freeze again with -nosound and just psxtc.pk3 psxtcmus.pk3 (no psxdoom customizer)

Dump is now 5.62 gb https://drive.google.com/open?id=1KdtYI ... _avu9Kuwta
gzdoom ini https://drive.google.com/open?id=16bCIs ... iHDH5DXIY6

not sure if the crash reason is same as in my initial message (video memory overflow -- just a guess)


btw, @_mental_, what tool do you use to analyze memory dumps?
Tried windbg from Windows 10 SDK -- it didn't find any exceptions (or maybe I simply don't know how to use it).

I'll try with clean gzdoom cfg created from scratch, no change in options at all.

lafoxxx wrote:what tool do you use to analyze memory dumps?
Tried windbg from Windows 10 SDK -- it didn't find any exceptions (or maybe I simply don't know how to use it).

I’m using Visual Studio 2017, 2015 should work too. Actually, WinDBG is enough to check dumps. You need to use Microsoft symbol server in WinDBG to get meaningful information in callstacks.

[img]https://i.postimg.cc/cCJPj7s0/openal.png[/img]
With -nosound, there was no such crash -- no mention of openal32, and I think it'd crashed anyway with same steps I followed -- change virtual resolution to very high values (so probablythere's no need to investigate this case yet).

If the issue is really in OpenAl,
Do I need to build my own opernal32.dll? Is it possible to get some kind of OpenAL debug/verbose info (about this specific AlSourcePlay 0x79 issue)?

This time GZdoom Crashdump was created: https://drive.google.com/open?id=1R5_eY ... uQ3QRB9nLe

I don't have the debug symbols for the openal32.dll

Spoiler:

---

************* Path validation summary **************
Response Time (ms) Location
Deferred cache*
Deferred srv*https://msdl.microsoft.com/download/symbols
0:005> .ecxr
*** WARNING: Unable to verify timestamp for openal32.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for openal32.dll -
rax=0000000000000000 rbx=0000000000000400 rcx=0000021d7e105990
rdx=0000021d7e0d683c rsi=000000000000007f rdi=00000000000001fc
rip=000000005bd45e15 rsp=0000003d74aff880 rbp=0000000000000000
r8=0000021d7e0d6640 r9=0000000000000004 r10=0000021d7e0c8e90
r11=0000021d7e105850 r12=0000021d7e0d6640 r13=000000005bd678c0
r14=0000021d7e0d6640 r15=0000000000000100
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
openal32!alcCreateContext+0x36875:
00000000`5bd45e15 0f280402 movaps xmm0,xmmword ptr [rdx+rax] ds:0000021d`7e0d683c=????????????????????????????????

Is it possible to resolve this somehow?
Thanks for all your feedback so far.

Well, it’s possible to build Debug version of the latest OpenAL release and replace .dll in GZDoom folder.
This won’t resolve the issue but will probably give some hints about the real cause of the crash.