ME3 multiplayer randomly crashes

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.