[RESOLVED] Later revisions of DSOAL causing application error upon exiting

[Mr. Cat]

Hello everyone

I was suggested by @ThreeDeeJay over on GitHub (link to the issue) to see if any of you have any insight into what might cause a crash upon exiting Diablo II when using newer revisions of DSOAL - more specifically r435a and onwards as provided over on http://vaporeon.io/hosted/dsoal-builds/

Interestingly, r435a was uploaded 2023-Feb-05 21:40:22, yet the files provided with the Cactus utility, both of which have later commit and build dates (as described on this page), do not cause the same crash.

Speaking of which, it looks like this:



It's presented right as the game process is closed.

Using the latest version provided over on the Vaporeon repository (r444 at the time of writing, uploaded 2023-Apr-17 06:14:07), all the in-game sounds work, including any 3D audio processing, as well as the game as a whole - yet the same application error shows up upon exiting.

For reference, the game is stock Diablo II, using the offline installer provided by Blizzard, then updated to v1.14D by using the Battle.net option in the game.

No other modifications whatsoever (including anything else provided by Cactus), only the DLLs dsoal-aldrv.dll and dsound.dll for 3D audio processing.

I've also attached a ZIP file containing log data from the debug functions of DSOAL.

Since a search on this forum shows a lot of discussions about the DSOAL wrapper, I sympathize if you don't want to spend your resources on investigating this issue - especially as you've kindly provided your own working DLLs for 3D sound utilization, and the Vaporeon builds seemingly don't provide any information on either the build or commit details.

Any input is greatly appreciated.

[fearedbliss]

Hey @Mr. Cat,

Hmm I'm not sure about that one since I haven't released new builds of the DSOAL / OpenAL code in Cactus for a year. The commits mentioned in Cactus are for 2022, not for 2023, so I think you are running a newer build than the Cactus provided DLLs. I did build my own DLLs from the upstream sources. I think when I built them last year I had a VS 2019 Toolchain, and used CMake to build the projects. I'm using VS 2022 now. I can try experimenting with building the latest DSOAL/OpenAL sources with my stuff and see if I can still get the crash.

IIRC, the DSOAL dll sources needs to be used with a compatible OpenAL sources as well, so you'll need to be careful there.

What OS are you on? All of my stuff was primarily compiled on Windows 10, and I think I also tested it on Windows 7 and Linux (via Wine).

I also normally am only testing D2 1.00 - 1.10 since those are the Blizzard North versions of the game. From what I can see above, you were saying the Cactus DLLs are working and the Vaporeon ones are crashing after the game exits?

[Mr. Cat]

Oh man, you're right, I never looked at the year - woops.

Personally, I'm running Windows 11, latest stable release, letting Windows Update do its thing in the background.

Correct, your DLL files are working. Checking the dates for the Vaporeon builds, yours are around r430. r435 worked as well - something that changed with r435a started the errors.

[fearedbliss]

Hey @Mr. Cat,

I updated my dsoal and openal-soft sources to the latest sources, re-compiled, and ran and everything is working fine with no crashes after the game finishes in both 1.09b and 1.14d. Please test these DLLs and see if they crash for you, if they don't, I'll go ahead and update the ones in Cactus with them. When I was going over my notes I saw my previous steps where I set the architecture to Win32, I do remember I had to do that because I was having issues getting it to work last year, maybe this has something to do with it. These were my original bug reports in the dsoal github:

https://github.com/kcat/dsoal/issues/49 ... 1076936119
https://github.com/kcat/dsoal/issues/48

[zip link removed, it's now part of latest Cactus]

This is the following information for the build and toolchain:

Architecture must be set to Win32, or Diablo II may crash or not even detect it.

OS: Windows 10 Version 22H2 (OS Build: 19045.2846) x64

# Configure for Win32. Only need to do this once.
cmake -A Win32 -B build

# Build / Rebuild Cleanly
cmake --build build --clean-first --config Release

-- Building for: Visual Studio 17 2022
-- Selecting Windows SDK version 10.0.22000.0 to target Windows 10.0.19045.
-- The C compiler identification is MSVC 19.35.32216.1
-- The CXX compiler identification is MSVC 19.35.32216.1
...

OpenAL Soft: 622ee190efffef9407ff6
Commit Date: 2023-04-30-0353
Build Date: 2023-04-30-1629

DSOAL: 52224b17832fda41d021
Commit Date: 2023-04-05-1035
Build Date: 2023-04-30-1629

[Mr. Cat]

Indeed, you solved the case - and as I was just about to type here, I only got crashes because of whatever non-Blizzard North did with v1.14d.

Unless I used your uploaded build, which works perfectly, enabling 3D audio whilst not producing any application error upon exiting.

Using the r444 Vaporeon build throws the error - but not with 1.09b.

No idea what's what, but here's a shortlist of the facts:

- Your uploaded build works not only with 1.09b, but also 1.14d
- r444 Vaporeon works with 1.09b, but produces an application error with 1.14d

So, judging by the facts discussed in this topic, some culprit lies in the Vaporeon builds after r435a - part lies in changes introduced by Blizzard after North's departure.

[fearedbliss]

@Mr. Cat I see. Well glad I was able to help. As mentioned above, that the was the build toolchain and steps i used to compile. Everything at it's default settings. Vaporeon folks can use that to compare with what toolchain and settings they are using to compile. Maybe there are some compiler flags or optimizations that are making some parts of D2 unstable and causing the issue.

I'll go ahead and update the files in Cactus with my new DLLs from yesterday. Marking this as Resolved.