Community Q&A

Welcome to Audiokinetic’s community-driven Q&A forum. This is the place where Wwise and Strata users help each other out. For direct help from our team, please use the Support Tickets page. To report a bug, use the Bug Report option in the Audiokinetic Launcher. (Note that Bug Reports submitted to the Q&A forum will be rejected. Using our dedicated Bug Report system ensures your report is seen by the right people and has the best chance of being fixed.)

To get the best answers quickly, follow these tips when posting a question:

  • Be Specific: What are you trying to achieve, or what specific issue are you running into?
  • Include Key Details: Include details like your Wwise and game engine versions, operating system, etc.
  • Explain What You've Tried: Let others know what troubleshooting steps you've already taken.
  • Focus on the Facts: Describe the technical facts of your issue. Focusing on the problem helps others find a solution quickly.

0 votes
We are experiencing intermittent crashes on Nintendo Switch with Unity (2019.1.0f2) . It happens around 50% of the time on first boot - before the Unity logo appears. Removing reference to WWise stops the crash. It's not occurring on our xbox, ps4 and Windows builds. WWise version is 2019.1.1.6977.

Most of the threads are stuck on WaitProcessWideKeyAtomic.
Appreciate any ideas on what might be causing the issue, thanks
closed with the note: Changing the Script Execution Order so the AKInitializer is at the top seems to fix it
in General Discussion by Mark B. (100 points)
closed by Mads Maretty S. (Audiokinetic)

1 Answer

0 votes
firstly this does not look like a crash but rather a deadlock - crash implies a thread did something which has caused the execuation to abort - deadlock implies that a thread is doing something which prevents one or more other threads from progressing.

both of the callstacks you share are dealing with a mutex that is protecting an allocator that the switch file system is using. the top thread is trying to deallocate memory and waiting for the mutex to become available. the bottom thread is trying to allocate memory and waiting for the mutex to become available. so the answer lies elsewhere.. what I can say with some certainty here is that the mutex that both these threads are trying to acquire is currently locked. next I would look for a thread which hash InternalCriticalSectionImplByHorizon::Enter in an upper frame that isn't waiting to acquire ( not in AbitrateUnlock ).

Just a guess based on your thread names - are you opening a file as Wwise is trying to close it.. is it valid with the nx filesystem to do that?

ps. you probably shouldn't post what could be details of the inner workings of the NX, unless your NDA with nintendo lets you do that, in future :)
by Dan M. (2.6k points)
Thanks for your feedback. Changing the Script Execution Order so the AKInitializer is at the top seems to fix it - I wasn't able to find out exactly why it was happening.

I have removed the details of the NX call stack - but thought I'd leave this up in case it's useful to others.

Thanks again - much appreciated.
ok so we can surmise that code in AKInitialzer needs to be run to initialize something before you use it - could be memory, filesystem, who knows.

> I have removed the details of the NX call stack - but thought I'd leave this up in case it's useful to others.

thanks!
...