Closed FlsZen closed 1 month ago
Looks like this may be a duplicate of #60144. How shameful this has been going on so long.
For those just joining us, I'm going to go with RobrechtU's workaround to lock runtime all files, and adding ASP.NET Core to it as well since our application uses that.
Description
Recently, every time .NET 6 releases a security update through Windows Update I receive a smattering of crash and exception reports. The Windows Update process is uninstalling the .NET runtime version our .NET 6 app is actively running on.
Our app controls hardware and is generally always running on the computer. After the update is applied, if the user access a section of the app they haven't used yet (during the lifetime of the process), it will get an exception or crash (depending on context) when it needs to load a .NET runtime DLL that hadn't been loaded yet.
Reproduction Steps
While our app is a large-ish WPF app, this issue can be readily reproduced with a simple console app and the runtime. Starting from a vanilla Windows 10/11 installation:
NetWUCrash.zip
Expected behavior
The app should print "Success".
Actual behavior
The app displays an exception message. (In our desktop application this will likely cause a crash since we aren't defending against the runtime going away.)
ProcMon shows it's trying to access the usual path, but the file is now gone:
Regression?
This reproduces readily with the versions specified in the notes. Take care to start the app with only an old net6 version installed and don't press Enter until Windows Update is done updating it to 6.0.33 (or whatever the current update version is).
Known Workarounds
Publishing a self-contained .exe is a viable workaround, but has the drawbacks of:
I've explored installing the runtime binaries in a different folder, but haven't been successful (may not actually be supported) and still had the security update drawback.
Configuration
We've been observing this on .NET 6, win-x64. We haven't released our .NET 8 update to customers yet and I haven't explored if this will still be an issue there.
Other information
I naïvely hope the Windows Update process could leave the .NET runtimes in place and remove them at the next reboot. Perhaps more than just the in-use DLLs could be relocated to C:\Config.Msi until the reboot? (Not sure if it would look for them there, though.)