diesel_lover6204
New member
- Joined
- Oct 22, 2025
- Messages
- 19
The post on Reddit is also me:
So I bought this MSI Vector 16 HX AI A2XWHG, it’s been great otherwise, great thermals and performance, and once you drop in 32GB of RAM, it should be good for a few years.
However, ever since I bought the laptop, the audio has been bugging me, just like:
case 1
case 2
Although on my machine it’s much less severe, it’s usually a brief pop and immediately recovers. Or audiodg.exe pegs one CPU core, and system loses sound, but once you kill the process, everything goes back to normal.
Recently I decided to get to the bottom of this, and here’s my finding first:
It’s likely a audiodg.exe heap corruption (0xC0000374, LFH double-free), very likely caused by either Intelligo/Nahimic/Intel.
Symptom
This issue most often occurs when an audio stream starts/stops (e.g., beginning playback, opening a Twitter/X video). If a music player keeps a continuous stream open, crashes are rare.
What did not fix it
After enabling dump for audiodg.exe, and using WinDbg to analyse it, I can see the failing thread is the ntdll heap GC timer. "!heap (HEAP_FAILURE_SEGMENT_LFH_DOUBLE_FREE)". Considering that the audiodg.exe crash can coincide with video in Chrome, this points to iGPU / Level Zero activity. Here's what ChatGPT has to say:
I don't know, looks pretty convincing to me. I don't know what to do next, just putting out what I discovered so far, maybe this will help people and things will get resolved. If I helped, someone headpat me.
So I bought this MSI Vector 16 HX AI A2XWHG, it’s been great otherwise, great thermals and performance, and once you drop in 32GB of RAM, it should be good for a few years.
However, ever since I bought the laptop, the audio has been bugging me, just like:
case 1
case 2
Although on my machine it’s much less severe, it’s usually a brief pop and immediately recovers. Or audiodg.exe pegs one CPU core, and system loses sound, but once you kill the process, everything goes back to normal.
Recently I decided to get to the bottom of this, and here’s my finding first:
It’s likely a audiodg.exe heap corruption (0xC0000374, LFH double-free), very likely caused by either Intelligo/Nahimic/Intel.
Symptom
- audiodg.exe crashes repeatedly with 0xC0000374 (heap corruption).
- Event Log says faulting module ntdll.dll, offset 0x117885 (consistent across crashes).
- Audio impact is brief hiccup; the service restarts and continues.
What did not fix it
- BIOS: enabling Codec Sx Wake and PME → no change.
- dGPU-only display mode → did not resolve (so not Optimus/MUX).
- Changing "DSP modules" in MSI "advanced BIOS": Realtek post-processing, Smart Amp, Dolby/DTS, and sound control panel's “hardware acceleration” toggle → no real change.
- MSI Center AI mic denoise (Intelligo under the hood) and toggling it → no change; issue persists.
- Nahimic → A lot of people hate on Nahimic, but it's most likely not the real cause. It's integral part of the audio driver, trying to cleanly remove Nahimic is futile. Also according to my testing, if Nahimic breaks, it's the symptom, not the cause.
After enabling dump for audiodg.exe, and using WinDbg to analyse it, I can see the failing thread is the ntdll heap GC timer. "!heap (HEAP_FAILURE_SEGMENT_LFH_DOUBLE_FREE)". Considering that the audiodg.exe crash can coincide with video in Chrome, this points to iGPU / Level Zero activity. Here's what ChatGPT has to say:
Every dump ends as ntdll’s heap GC thread hits LFH double-free. In earlier dumps the live user-mode stack shows ucrtbase!malloc → dnnl.dll (oneDNN) → Intelligo modules (B10E0005.dll, IGOAPO2.dll) doing neural-net primitive setup/teardown right before the heap gets corrupted. That strongly suggests a lifetime/ownership bug in the AI processing path, not in Windows Audio itself.
Intelligo’s denoise APO (IGOAPO2.dll) ships with ov_runner.dll (OpenVINO runner) and dnnl.dll. OpenVINO/oneDNN pick a compute engine (CPU/GPU/NPU/GNA) via Level Zero. When an audio stream starts or the graph topology changes, the APO (or its runner) can create/destroy oneDNN primitives and device resources—exactly the kind of code path where a double free / double release can slip in.
You can provoke a hiccup/crash by hovering a Twitter video (Chromium overlay/decoder kicks the iGPU). That UI event shouldn’t matter to audio, yet it aligns with iGPU power/engine transitions and Level Zero context churn, which would force the APO’s backend to re-init/release resources. If that code releases the same heap block twice (or releases after the device is lost), you get your LFH double-free later during heap GC.
Even dock audio (not using the OEM speaker post-effects) glitches when the GPU event happens. Nahimic is loaded, but its frames aren’t on the hot stack in your dumps; re-enabling/disabling the classic enhancements didn’t change frequency. That weakens the “it’s Nahimic DSP” theory and keeps the focus on the Intelligo↔Intel offload layer.
Forcing dGPU display didn’t stop the crashes. That’s consistent with the problem living in audiodg’s compute offload (Level Zero GPU/NPU/GNA) rather than the display/MUX path. The Intel Level Zero UMD still loads into audiodg even in that mode.
I don't know, looks pretty convincing to me. I don't know what to do next, just putting out what I discovered so far, maybe this will help people and things will get resolved. If I helped, someone headpat me.
. (Not to mention that there is a bunch of other stuff you can do with this program to improve performance, but only if you know what you are doing).