.Net 5.0 Application using NAudio libraries crashes after applying cumulative update 21H1 to Windows 10

[MarcoAuday]

My application started crashing after applying the Windows 10 "21H1" cumulative update.
As soon as I click the play button to play any WAV file the application freezes for 10 seconds and then abruptly ends - no error messages on the screen. Only the Event Log reveals the problem message:

MyApp.exe
2.1.0.0
607f5cf5
msvcrt.dll
7.0.19041.546
564f9f39
c0000005
00000000000744ce
3134
01d75d5bc38d4623
D:\Development\MyApp\MyApp.exe
C:\WINDOWS\System32\msvcrt.dll <====================== OFFENDING LIBRARY
cb662446-488f-4cb5-80f2-a815faeb3852

Has any of you experienced the same behavior after updating Windows 10 with the 21H1 cumulative update?
Thank you.

[daniel-rck]

Can confirm this Error.

Excerpt from my eventlogs:

Name der fehlerhaften Anwendung: MyApp.exe, Version: 1.0.0.0, Zeitstempel: 0x609308e7
Name des fehlerhaften Moduls: msvcrt.dll, Version: 7.0.19041.546, Zeitstempel: 0x564f9f39
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000000074452
ID des fehlerhaften Prozesses: 0xf60
Startzeit der fehlerhaften Anwendung: 0x01d75decd878748b
Pfad der fehlerhaften Anwendung: C:\{projectfolder}\bin\Debug\net5.0-windows10.0.19041.0\MyApp.exe
Pfad des fehlerhaften Moduls: C:\Windows\System32\msvcrt.dll
Berichtskennung: c5b60de9-e231-4236-84da-5bbbcc60dedd

EDIT: Attached a small sample to reproduce error.
WpfSampleApp.zip

[klaritan]

This started happening with mine as well.
I used this on top of it and it makes screeching sound: https://markheath.net/post/fire-and-forget-audio-playback-with

[DENLN]

It also crashes in Windows 7.. Maybe it's in .NET 5.0.7 Update ?

[MarcoAuday]

The application was migrated into .NET 5.0 some time ago and it used to work fine. Since then I have applied the regular Visual Studio and Windows 10 updates. I suspect that it was CU 21H1 or one of the follow-up updates. Unfortunately I do not have another computer where I can test the application with - and without - the latest updates. I also noticed that "msvcrt.dll" has not been updated lately because in my computer it is dated: 2020-10-14.

[KyodaiKen]

Similar issue here. I get weird sounds played back and then it quits with an access violation. I think they've changes something and the memory pointer for the WaveOut buffer for example is not set right, playing back program code instead of audio data, then going outside of the program's memory.

[KyodaiKen]

Ok, it's the .NET framework 5.0. I have an older compiled version of my app still and it's on 3.x and that one works. So, there's a bug in the current "hotfix" of .NET 5.x. The NAudio team should contact Microsoft ASAP. It has nothing to do with any other updates (Cumulative, etc.). Unfortunately .NET updates cannot be uninstalled.

[KyodaiKen]

Does any of you use a specific audio output API via NAudio? Like WaveOut, DirectSound, WASAPI, etc.?

[jcddcjjcd]

Same here. Started with CU 21HI.
Have spent a day trying various alternative ways of playing the wav file but to no avail.
Does not appear to be related to the callback or type of stream.
I am unable to catch an exception anywhere, Net v5.0 Wpf app just crashes.
The issue exists on my laptop and desktop and appears unrelated to the audio driver or hardware.

[cits]

Same here.

It is the NET 5.0.7 runtime causing the issue. Rolling back to 5.0.6 is the fix. BUT Microsoft is forcing the 5.0.7 update and I have to keep removing 5.0.7 and reinstalling 5.0.6

[KyodaiKen]

Same here.

It is the NET 5.0.7 runtime causing the issue. Rolling back to 5.0.6 is the fix. BUT Microsoft is forcing the 5.0.7 update and I have to keep removing 5.0.7 and reinstalling 5.0.6

I've installed 5.0.0 and the issue was still there.

[KyodaiKen]

Same here. Started with CU 21HI.
Have spent a day trying various alternative ways of playing the wav file but to no avail.
Does not appear to be related to the callback or type of stream.
I am unable to catch an exception anywhere, Net v5.0 Wpf app just crashes.
The issue exists on my laptop and desktop and appears unrelated to the audio driver or hardware.

The issue causes memory to be read that does not belong to the process, so the Windows kernel kills the application with the error "Access Violation". It is NOT the Cumulative update! It's a "hotifx" in the current .NET 5.x runtime.

[cits]

I've installed 5.0.0 and the issue was still there.

I don't see that here. 100% reproducible in all my tests across multiple machines. NET 5.0.6 works without issue, but with 5.0.7 it fails consistently.

[KyodaiKen]

I've installed 5.0.0 and the issue was still there.

I don't see that here. 100% reproducible in all my tests across multiple machines. NET 5.0.6 works without issue, but with 5.0.7 it fails consistently.

Have you switched the runtime and recompiled? I've definitely installed 5.0.0 and it did not work. Maybe it didn't really uninstall, I don't know.

But there is definitely an issue in the runtime and I hope Microsoft will fix this ASAP.

[h1cks]

Can confirm the same issue in the past 2 days. Sound now plays random samples in memory. .NET 5.0 application.

[markheath]

Wow, thanks everyone for reporting this. I'm afraid I've been extremely busy on other projects recently, but I will try to chase up with Microsoft to understand what is going on here

[Zintom]

I can concur I am getting the same problem with WaveOut and Wasapi on .NET 5.0.7

[Zintom]

Can anyone suggest a way to rollback my .NET Sdk version? I've tried uninstalling from the Control Panel and installing 5.0.5 from the website but 5.0.7 persists. To be completely honest I don't remember installing 5.0.7 so this must have happened with a VS update, in which case is it impossible to uninstall 5.0.7?

[KyodaiKen]

The only thing that worked for me was changing the runtime back to 3.x and recompiling my application.

[Zintom]

The only thing that worked for me was changing the runtime back to 3.x and recompiling my application.

That is a solution I suppose, but I REALLY don't wanna move back to .Net Core 😬 (older C# version too which isn't convenient)

Luckily my apps aren't very popular so it's not a critical issue at this stage 🤗😁. I'm very intrigued to hear what Mark's prognosis is, I don't understand low level stuff but it does excite me!

[emyfreya]

I was going crazy ! I thought I had to do something with it !
Even when specifying <RuntimeFrameworkVersion> on my .csproj, nothing worked.

The only thing that works is a WPF app with <TargetFramework>netcoreapp3.1</TargetFramework>.
Thing is, my app is using "Production ready" WinUI 3 that needs <TargetFramework>net5.0-windows10.0.18362</TargetFramework>. Hope this gets fixed, I really wanted to code !

Edit:

Odd thing is, it works if you go on your bridge project app and right click on it then Publish → Create app packages... then sideloading and then compile it in x64. Then do all the install process, start your app and NAudio works perfectly fine.

And it's because of RuntimeFrameworkVersion, I need to read more doc

[klaritan]

Our WPF did not work with Publish. It doesn't crash, but audio still wouldn't play.

Had to switch audio library, but transition was easy enough as we already had a wrapper. Hopefully NAudio gets it fixed soon so we can revert it back in the future.

[Mephistofeles]

Have you tried building self-contained (with 5.0.6 runtime included) application for a temporary fix?
https://docs.microsoft.com/en-US/dotnet/core/deploying/#publish-self-contained

[TheRealLenon]

Tried with any .NET 5 version. Can reproduce it on any version.

[AraHaan]

Try it with the latest .NET 6 Preview 4 SDK and Runtime. Would like to hear if it works then too? If not then file issue at https://github.com/dotnet/runtime/ and link this one as well and tell them it started in .NET 5's version of the runtime.

Chances are this could possibly be a regression they failed to catch.

[ghost]

Yea me to, ill also note if I keep trying to get it to play it plays a weird screeching sound if successful

[KyodaiKen]

Yea me to, ill also note if I keep trying to get it to play it plays a weird screeching sound if successful

To me it really looks like a memory pointer issue.

[Fabi]

Works fine on 5.0.6, .NET 6 previews and the 5.0.8 branch. With 5.0.7 it's broken. You can test it by downloading the zip files of these versions and invoke dotnet from these folders.

The crash is basically in the driver for me in 5.0.7. But yea something in 5.0.8 branch already fixed it too

[misharp]

A PR was created in .NET to fix this issue. Also mentioned that making the NAudio interop classes sealed would also resolve the issue.

[KyodaiKen]

Works fine on 5.0.6, .NET 6 previews and the 5.0.8 branch. With 5.0.7 it's broken. You can test it by downloading the zip files of these versions and invoke dotnet from these folders.

The crash is basically in the driver for me in 5.0.7. But yea something in 5.0.8 branch already fixed it too

No, it can randomly work in newer dotnet runtimes:

The crash is caused by use-after-free bug. The crash will only happen if something else actually modified the freed memory in a specific window of time. It is certainly possible that the crash will come and go due to unrelated changes - that's the nature of use-after-free bugs.

Originally posted by @jkotas in dotnet/runtime#54132 (comment)

[Fabi]

Works fine on 5.0.6, .NET 6 previews and the 5.0.8 branch. With 5.0.7 it's broken. You can test it by downloading the zip files of these versions and invoke dotnet from these folders.
The crash is basically in the driver for me in 5.0.7. But yea something in 5.0.8 branch already fixed it too

No, it can randomly work in newer dotnet runtimes:

The crash is caused by use-after-free bug. The crash will only happen if something else actually modified the freed memory in a specific window of time. It is certainly possible that the crash will come and go due to unrelated changes - that's the nature of use-after-free bugs.

Originally posted by @jkotas in dotnet/runtime#54132 (comment)

another fact: not random. But in general you are right, yes!

[Zintom]

It looks like this is going to be fixed in dotnet/runtime#54235 (comment) once merged.

This still exposes technically incorrect code in the WaveOutBuffer, it would be correct to mark the class as sealed.

[TheIronWolfModding]

Not sure yet if this is relevant, on OS build 2004 WASAPI output I get:

Exception thrown at 0x00007FF8547A4B89 (KernelBase.dll) in CrewChiefV4.exe: WinRT originate error - 0x80004001 : 'Not implemented'.
onecore\com\combase\winrt\error\restrictederror.cpp(1016)\combase.dll!00007FF85663C363: (caller: 00007FF856646039) ReturnHr(5) tid(2e44) 8007007E The specified module could not be found.

CrewChiefV4 is .NET 4 app though optionally using WASAPI ouput. No issue with WaveOut.

I will investigate deeper when I've time.

edit: it happens every time we do this:
KernelBase.dll!RaiseException�() Unknown
combase.dll!SendReport(HRESULT error, unsigned int cchMax, const wchar_t * message, unsigned short pSid, void * pExceptionObject, IUnknown *) Line 433 C++
combase.dll!RoOriginateError(HRESULT error, HSTRING__ * message) Line 590 C++
AudioSes.dll!Microsoft::WRL::ActivationFactory<struct Windows::Media::Internal::IAudioPolicyConfig,class Microsoft::WRL::FtmBase,class Microsoft::WRL::Details::Nil,0>::ActivateInstance(struct IInspectable * *) Unknown
[Managed to Native Transition]
NAudio.dll!NAudio.CoreAudioApi.AudioClient.AudioRenderClient.get() Unknown
NAudio.dll!NAudio.Wave.WasapiOut.Init(NAudio.Wave.IWaveProvider waveProvider) Unknown

CrewChiefV4.exe!CrewChiefV4.Audio.NAudioOutWasapi.Init(NAudio.Wave.ISampleProvider sampleProvider, bool convertTo16Bit) Line 116 C#

here, sample provider is NAudio.Wave.SampleProviders.SampleChannel
Reader is: WaveFileReader

[jackpoz]

dotnet/runtime#54132 (comment)
The .net fix will take long, it would be faster to mark the required classes sealed in naudio and publish a minor version in nuget to fix this issue with the current .net 5.0.7

[cits]

dotnet/runtime#54132 (comment)
The .net fix will take long, it would be faster to mark the required classes sealed in naudio and publish a minor version in nuget to fix this issue with the current .net 5.0.7

Which classes need to be marked as sealed?

[jkoritzinsky]

For this particular case, the WaveHeader type would need to be sealed. Generally, any class types used in interop as “layout class” types (as opposed to COM interop) should probably be sealed.

[jcddcjjcd]

I left this comment on: dotnet/runtime#54132

The sad thing here is that NAudio is widely used. It has 2.34 Million downloads on github and there is currently nothing that comes close to it's functionality that is maintained.
There was mention above that if NAudio made it's classes sealled then the problem would go away.
Is that an option that could be considered?

And got this reply from jkoritzinsky:
That option would have to be considered by the owners of NAudio, and based off the parallel issue over there, it seems it might be.

I'm hoping this will be looked at.

[markheath]

I noticed the comment about sealing the classes used for interop. It sounds like something that would be worth trying. Haven't had the chance to dig deep into this myself yet. Would be happy to accept a PR if anyone wants to give this a try with WaveHeader (which seems to be the main culprit)

[jackpoz]

I created a PR at #798 and a small repro project at https://github.com/jackpoz/NetCore507Crash , testing before and after the PR and the "sealed" change fixed the crash.

[jackpoz]

@markheath do you have any plan on when next NAudio release will be so we can just update to latest nuget package ? Thanks

[markheath]

I've just pushed a new version of the NuGet package. Please let me know if it resolves your issue

[cits]

I've just pushed a new version of the NuGet package. Please let me know if it resolves your issue

YES! 2.0.1 works for me. Thanks very much.

[markheath]

Awesome, many thanks to @jackpoz

[h1cks]

I've just pushed a new version of the NuGet package. Please let me know if it resolves your issue

For me, it no longer crashes, but MP3 playback only runs for about a second before going silent. The Waveout says the mp3 is playing in its current state. Volume is maxed. The upside is, it no longer crashes. But Mp3 playback is not working for myself.

Just to clarify, this isn't under https://github.com/jackpoz/NetCore507Crash/blob/master/Program.cs sample.

This is using the AudioFileReader to load the MP3 and passing the AudioFileReader Object to the WaveOut.Init function and then calling Play. This path may not function correctly, I will review the above link and implement that method.

[jcddcjjcd]

2.0.1 fixed it for me though I have only tested with wav files.
Thanks for your work.

[emyfreya]

I can confirm that WaveIn works again. Thanks !

[tolache]

How do I fix this if I'm using NAudio.Extras NuGet package? It doesn't seem to have received an update.

[markheath]

Make sure that you're also referencing NAudio 2.0.1