ME3 multiplayer randomly crashes

BassGuitarFox​ 

• Go to your „C:\Windows\LiveKernelReports” folder. (There might be subfolders.)
• Zip two or three crash dump files files (*.dmp) together together (Compare the timestamps with the times of the crashes.) and upload them to your public OneDrive folder or a file hosting service of your choice.
• Post the link to the ZIP file here.

holger1405​ 

Apologies for the delay—I've been attempting a ton of troubleshooting on my end over the last couple of weeks.

I've been using WinDbg to troubleshoot/analyze .dmp files with the help of ChatGPT. I've analyzed close to ~10 different crash dumps this way and they have always come back with the same result/root cause. It seems to be something with the game's audio thread (a NULL pointer dereference inside ME3’s Wwise audio engine).

Given the findings above, I've also included a recap of the ChatGPT analysis below. I've also uploaded the 3 crash dumps, as requested, below, in case you'd like to verify on your end:
https://drive.google.com/file/d/1BGrX1mHxEDwSe1AteWZN6eJb3kwCnNP9/view?usp=sharing

GPT bug report (with some edits from my end) is below:

Bug Report: Mass Effect 3 Multiplayer – Consistent Crash-to-Desktop on Audio Events

Title:
Mass Effect 3 Multiplayer crashes to desktop. No error message.

This crash event often occurs during the Drone Escort objective precisely at the moment the Drone reaches the destination zone, but it also occurs at other points. Crashes are intermittent but can be very frequent at times. The Drone Escort is the most reproducible/predictable trigger, but some other potential crash triggers include "Ally Down" and Power usage (Overload, Flamer, etc.).

Environment:

• Game: Mass Effect 3 (2012, latest Origin/Steam/EA App builds) - This specific case is Steam
• Mode: Multiplayer
• OS: Windows 11 (multiple users, modern hardware: Lenovo Legion, ASUS, etc.) - This specific case is Lenovo Legion Pro 7i Gen 9 with RTX4090 GPU
• Audio: Realtek/Nahimic, NVIDIA HD Audio, USB DACs all tested (issue occurs regardless of device, reproduced on all)

Description:
Mass Effect 3 Multiplayer crashes to desktop with no error message. The crash occurs most consistently when:

• The Escort Drone objective reaches the destination zone (MOST COMMON/PREDICTABLE)
• A teammate is incapacitated (“Ally Down”) and the announcer VO/stinger plays.
• Occasionally crashes also occur during power use (e.g., Overload impact, Flamer loop).

These aren't always the trigger, sometimes it seems more random, but these are some patterns I've noticed. The Escort Drone reaching destination is by far the most predictable moment to crash.

Repro Steps:

• Launch ME3 Multiplayer and join a match.
• Trigger an Escort objective and let the drone reach the destination.
• Observe: when the issue occurs, game freezes briefly then crashes to desktop. Precisely the moment the Drone reaches the destination zone and sounds play.

Expected Result:
Game should continue running; announcer VO/stingers should play normally.

Actual Result:
Game consistently CTDs at the moment of the announcer VO or stinger.

Crash Dump / Trace Findings:

• Exception: 0xc0000005 Access Violation at MassEffect3.exe+0x52BE1
  Faulting instruction: cmp word ptr [esi+8Ch],0 with ESI=0x00000000
  → NULL pointer dereference inside ME3’s Wwise audio engine.
• Stack traces always run through:
  • MassEffect3.exe!AK::MemoryMgr
  • MassEffect3.exe!AK::IAkStreamMgr
  • awc (audio streaming component)
  • ntdll!RtlUserThreadStart
• ETW/WPR traces confirm:
  • Crash occurs on ME3’s audio thread.
    Thread idles in ntdll!NtWaitForMultipleObjects, then wakes to process an audio event and faults immediately in MassEffect3.exe.

Diagnosis:

• Likely a lifetime/race condition in Wwise 2010.3.3 integration:
  • A voice/stream object is freed or uninitialized.
  • When announcer VO or objective stinger events fire, the engine dereferences [NULL+0x8C].
•  Content-triggered: Escort complete and Ally Down VO/stingers are the most consistent triggers.

Impact:

• Prevents stable Multiplayer sessions on modern systems.
• Affects a wide user base (confirmed on multiple new gaming laptops and desktops).

Suggested Fix Direction:

• Reproduce internally with Drone Escort objective (potentially other scenarios like Ally Down or power use).
• Audit Wwise object lifetime handling for multiplayer VO/stinger events.
• Potential mitigations:
  • Null-check object before dereference.
  • Patch affected VO/stingers to avoid triggering invalid objects.
  • Provide option to disable Multiplayer announcer VO/stingers.

To your second question: is this on BioWare/EA’s side or yours?

This is a game-side bug.

You’ve proven it occurs across multiple devices (Realtek, NVIDIA HDMI, USB audio).
You’ve cleaned up all the common third-party APOs (Nahimic, Elgato, etc.).
The dumps consistently show ME3 itself dereferencing a NULL pointer in its audio engine.

Your system/config can make it more or less frequent (e.g. Realtek/Nahimic exacerbate it), but the root cause is in MassEffect3.exe’s audio thread logic. That’s BioWare’s bug, not yours.

BassGuitarFox​ 

The IAkStreamMgr is on of the last functions called, that is a Wwise audio engine function, but if the game crashes out of a drivers incompatibility with the game engine, it is still the drivers fault. 

• Press the Windows key and i.
• System > Sound > Output, click on Speakers (Realtek(R) Audio) 
• Disable the "Audio enhancements" and surround sound. 
• Test. (If you don't use the laptop speakers do the same with the Audio device you use.) 

holger1405​ 
After the crash dump analysis pointed to the audio path, I went through a significant amount of troubleshooting/testing on just about everything I could come up with related to my audio stack.

I isolated every different audio output method I had available (1. Realtek(R) Audio through my laptop's speakers/headphones, 2. NVIDIA High Definition Audio from an HDMI-connected Dell monitor, and 3. ElGato Wave XLR headphone output) one-by-one in a clean stack with everything else fully disabled. I also disabled all the advanced settings like Audio enhancements and Spatial sound. I also disabled Nahimic (came preloaded on the laptop, I believe integrated with Realtek), at the "services" level. Unfortunately, I reproduced the crashes on every method/iteration I tested (including Realtek(R) Audio, NVIDIA High Definition Audio, and ElGato Wave XLR). I also changed my laptop's audio to a generic Windows Audio driver at one point instead of Realtek's driver (GPT's suggestion), and I still reproduced the crash.

 GPT was initially thinking Nahimic was the most likely culprit, but with the crashes also persisting on NVIDIA High Definition Audio (HDMI-connected monitor) and ElGato Wave Link it doesn't necessarily seem to be the case. I will say that I only disabled Nahimic at the "Services" level, and did my best to make sure it wasn't running in any capacity in Task Manager during each test, but it does still exist on my system. Not sure if it'd continue to cause issues somehow.

I will re-test Realtek(R) audio on my laptop headphones or speakers, isolated by itself, with Audio enhancements and Spatial sound off just for the sake of being thorough, but this did not seem to stop the crashes before.

BassGuitarFox​ 

Nahimic is responsible for many crashes in many games.

Chat GPT is nice servant but a bad master, it has no data to point to anything really, and so it is just hallucinating what might be the case. 

If you completely deleted the driver and Nahimic and used a generic Windows Audio driver, audio is probably not the culprit. 

Seeing the many "LiveKernelEvent" errors in your DxDiag that are either driver or directly hardware related, I would suggest a BIOS update, 
(This should be a Legion Pro 7 16IRX9H - Type 83DE, Your BIOS is listed as N2CN24WW the newest on the Lenovo page for this Laptop as N2CN27WW.) and if that don't helps a clean re-installation of the OS with only drivers from Lenovo. 

holger1405​ 

​I updated my BIOS to N2CN27WW, I crashed within about 3 rounds. Same behavior as always. This time was at the beginning of wave 3 at the start of the objective during an announcer sound byte. This fits with a lot of the other behavior I've experienced and does seem to align (anecdotally) with the idea that this could be audio-related.

I definitely understand your point with GPT, but in this case it had ample data to point to what it's suggesting with the game's audio thread. This was directly based on analysis of around 10 different crash dumps over multiple weeks. Do you see something different when you review the .dmp files I attached above?

I really only had GPT guide me through analyzing the crash dumps via WinDBG, and every single analysis came back with the same results (specifics summarized in the post above). Always the same null pointer dereference inside MassEffect3.exe in the game's audio thread handling. 

To confirm/support the crash dump findings, I then captured the crash event via Windows Performance Recorder and analyzed the .etl trace file via Windows Performance Analyzer. Everything aligned exactly with what GPT described from all the prior crash dump analyses. I looked at exactly where the crash happened in ME3's audio thread just like it described, so it seemed to be accurate there. Given everything in the crash analysis was consistently pointing to the audio thread, I went through just about anything I could try from GPT's suggestions to fix it after that (including all the different driver and audio stack testing). Unfortunately nothing has fixed it, and everything continues to point back to a game-side issue in the analysis.

I ran a couple of the statements you responded with back through GPT to see what it came back with, below are GPT's responses (in quotes). At this point, I have to ask, how do we know it's not right? I've gone through multiple weeks of analysis and troubleshooting attempts and nothing has completely solved the crashes. Certain things may have reduced the frequency (for example—running my HDMI-connected monitor through NVIDIA High Definition Audio went multiple days and a significant number of rounds with no crashes which is pretty unusual), but nothing has fully stopped the crashing. I've reproduced the crashing on multiple independent driver stacks, I've clean uninstalled and updated all my NVIDIA and Intel graphics drivers, I've messed with video settings in-game and in NVIDIA, and I've updated my BIOS. If everything coming out of the analysis from GPT and my crash dumps is pointing to a game-side issue, how do we know it's not that? 

This issue is clearly happening for a solid number of people; I continue to see more and more people posting about ME3 crashes recently across various platforms (YouTube, Reddit, here). It's clearly not isolated to my hardware. I also got multiple friends into the game recently, starting in late June, and every single one of them has experienced these same crashes, too.

GPT's responses:
I asked it about the following statement:
"The IAkStreamMgr is one of the last functions called, that is a Wwise audio engine function, but if the game crashes out of a drivers incompatibility with the game engine, it is still the drivers fault."

"What’s true

-IAkStreamMgr is indeed a Wwise (audio middleware) interface, and it is the last thing in your stacks before the crash.

-Audio middleware does sit between the game and the OS audio subsystem, so in some cases an incompatible driver can expose bugs that the game’s audio code wasn’t hardened against.

What’s misleading

In your case, you’ve proven it’s not a driver incompatibility:

You reproduced the crash on three completely different output stacks:

-Realtek HD Audio (with/without Nahimic)

-NVIDIA HDMI Audio

-Elgato USB audio

You even swapped Realtek for the generic Microsoft HD Audio driver, and the bug still occurred.

If it were purely a driver incompatibility, you’d expect the problem to go away on at least one of those stacks. Instead, the crash signature is identical every time.

What the dumps actually show

The faulting instruction is always:
cmp word ptr [esi+8Ch],0
ESI = 0x00000000

That’s a null pointer dereference inside MassEffect3.exe, not inside a driver DLL.

The call stack never lands in audiodg.exe, ksuser.dll, mmdevapi.dll, or xaudio2_7.dll (places you’d expect if a driver handoff was failing).

Instead it dies inside the game’s own build of Wwise 2010.3.3 (MassEffect3.exe), which BioWare integrated.

So whose “fault” is it?

Drivers can exacerbate timing (e.g. Nahimic or Elgato adding latency, making a race condition fire more often).

But the bug itself is in ME3’s code — specifically its audio thread handling.

The safest phrasing: “This is a latent bug in ME3’s 2012 Wwise integration that becomes exposed on modern systems regardless of driver stack.”

So, to answer you directly:
No, it’s not really “the driver’s fault” here. The game dereferences a null pointer in its own audio code. Different drivers change how often it happens, but they don’t cause it — BioWare’s 2012 Wwise integration has a bug that needs a null-check or content patch.


Another GPT response supporting the same ideas:

"I understand why drivers are often suspected, especially with Nahimic or Realtek in the chain, but in this case the crash is not isolated to one driver stack. I’ve reproduced the CTD on:

-Realtek(R) Audio (with and without Nahimic, enhancements off, spatial sound off)

-Generic Microsoft HD Audio driver (replacing Realtek completely)

-NVIDIA High Definition Audio (HDMI monitor output)

-Elgato Wave XLR USB audio

In all of these cases the crash signature is identical:

-Exception code 0xc0000005 (Access Violation)

-Faulting instruction at MassEffect3.exe+0x52BE1: cmp word ptr [esi+8Ch],0 with ESI=0x00000000

-Call stack through MassEffect3.exe!AK::MemoryMgr → MassEffect3.exe!IAkStreamMgr → awc

ETW traces confirm this happens on the game’s audio thread: it idles in ntdll!NtWaitForMultipleObjects, wakes to process an event, then immediately faults inside MassEffect3.exe. No third-party DLL or driver module is on the stack at the fault site.

So while drivers like Nahimic can change timing and frequency, the underlying bug is a null pointer dereference in the game’s audio engine integration. It occurs consistently when certain announcer VO/stingers fire (e.g. Escort complete, Ally down), regardless of output device or driver.

That points to this being a game-side issue in MassEffect 3’s Wwise audio handling, not a Realtek/NVIDIA/Elgato driver fault.

That keeps it short enough for a forum thread, but clear that this is reproducible across devices and that the dumps all agree it’s ME3’s own audio code.

BassGuitarFox​ 

Because it isn't working like this. 
ME3 (2012) is an old game, and the older a game is, the higher the chance that it will be incompatible with modern hardware.

But this is is also a beloved game and still played by many people, if there would be a general problem with the games audio engine now, we would see far mor post about this here or elsewhere. 

Also, the audio engine is not working on its own, it is not producing a access violation out of thin air, it always is a collaboration with the specific driver or other modules.  
The fact that the game crashes on completely different audio devices suggests that there are additional problems.

Furthermore, as said before, there are several  "LiveKernelEvent" errors in your DxDiag. 

These "LiveKernelEvent" errors are hardware-related (graphics and USB systems) and clearly indicate driver problems inside your system. (A hardware defect is also possible.)
The also present BSOD errors also point in this direction. 

 

For whatever it's worth, I've had some success cutting down on the crashes by disabling the in-game overlay. Not ideal since I can't send/receive invites, but it's helped a lot.