[FIXED] Game crashes using OpenAL DLL provided by official Windows installer [Win 8.1, Creative X-Fi]

[Expack3]

Upon running Alpha 18 of 0 A.D. on my Windows 8.1 machine, which was installed using the official Windows installer in D:\Games\0 A.D. alpha, I found the game crashed as soon as the game's main menu attempted to play any sort of sound - which always meant the main menu's song. Everything else, from the GUI to the scrolling background graphics, otherwise loaded fine. Having seen similar behavior in other OpenAL-reliant games, such as FEZ and Zelda: Mystery of Solarus DX, I first attempted to delete the OpenAL DLL provided by the Windows installer to force the game to use my machine's local version of OpenAL (version 2.1.0.0). This immediately solved the problem, and I was able to play the game without any further discernible issues.

It should be noted I use a Creative X-Fi Fatality Professional PCI Express sound card, which has native OpenAL hardware acceleration support when using the official Windows drivers/DLLs. Also, as a side note, exchanging the provided OpenAL DLL with the latest stable OpenAL Soft 32-bit DLL (renamed to OpenAL32.dll to match the DLL being replaced) also allowed the game to run properly.

I have included all log files generated by the game as attachments - which, unfortunately, do not seem to include any crash information regarding the included OpenAL DLL.

mainlog.html

system_info.txt

Edited March 14, 2015 by Expack3

[historic_bruno]

Also, as a side note, exchanging the provided OpenAL DLL with the latest stable OpenAL Soft 32-bit DLL (renamed to OpenAL32.dll to match the DLL being replaced) also allowed the game to run properly.

That's good to know! I'll update to the latest OpenAL Soft for the next release Edit: created a ticket for that: http://trac.wildfiregames.com/ticket/3100

I have included all log files generated by the game as attachments - which, unfortunately, do not seem to include any crash information regarding the included OpenAL DLL.

There is no crashlog.dmp or crashlog.txt in the log folder? Odd...

[Expack3]

There is no crashlog.dmp or crashlog.txt in the log folder? Odd...

There was a crashlog.dmp, but it was totally empty and never populated with any information. Since the issue is easily reproducible, I'll go and see if I can coax a crashlog file with actual content out of the game binary.

[Expack3]

While I wasn't able to get a crashlog.dmp with actual contents tonight, I was able to get an error out of Visual Studio 2010's JIT debugger:

Unhandled exception at 0x650be6f6 in pyrogenesis.exe: 0xC0000005: Access violation reading location 0x1298f000.

Pyrogenesis.exe, which threw the error, was attempting to access OpenAL32.dll at 650be6f6(). Attached to this post is a partial dump of the disassembled code, including the line affected. Given how vague the disassembled code likely is, I'll just debug a source-built version of the game instead in the morning.

OpenAL32error_dissassembly.txt

Edited March 15, 2015 by Expack3

[Expack3]

After debugging the code a bit, I've turned up the following series of events:

1. CGUIManager::TickObjects() is called upon startup.
2. The first iteration of CGUIManager::TickObjects' FOR loop is run, which calls it->gui->TickObjects
3. GUI::TickObjects() eventually calls GUI<CStr>::RecurseObject
4. GUI<CStr>::RecurseObject eventually causes a crash on the 11th iteration of its FOR loop, which is the access violation reported earlier.

I realize this isn't much to go on, but the code I'm used to debugging is in C#, Visual Basic, and Java, and C++ code is quite hard for me to read, let alone understand. I'll keep trying, but I get the feeling my usefulness in following this up is ending.

[historic_bruno]

Hi, can you try this DLL and see if it also works? It's OpenAL Soft 1.16 built with VS 2013.

OpenAL32.zip

[Expack3]

Hi, can you try this DLL and see if it also works? It's OpenAL Soft 1.16 built with VS 2013.

OpenAL32.zip

The file works just as well as the official Windows binaries - sounds playback normally, and I was able to play 4 singleplayer matches in a row without issue.

Also, I did notice something I hadn't before: unit responses seem to play over one another. For example, when I define a scouting route for my first mounted unit, a unit voice response is generated every time I click to generate a waypoint - even if the previous voice response hasn't finished. Is this normal?

Edited March 24, 2015 by Expack3

[historic_bruno]

It's "normal" but not desired Someone even volunteered to work on it, but I don't know what the status is.

[historic_bruno]

Fixed in r16461.