Jump to content

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


Expack3
 Share

Recommended Posts

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 by Expack3
Link to comment
Share on other sites

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...
Link to comment
Share on other sites

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. :)

  • Like 1
Link to comment
Share on other sites

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 by Expack3
  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

attachicon.gifOpenAL32.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 by Expack3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...