DllNotFoundException after .NET 5 in-place update

[TRZLGast]

Description

If Microsoft Update (MU) installs an in-place update of .NET 5 framework (no major/minor feature update) while framework dependent applications are running, then these applications may crash after a time because of missing dlls (FileNotFoundException/DllNotFoundException).

The in-place update installs the new version of the .NET framework and then it tries to delete the old version. If dlls of the old version have been loaded, they can't be deleted and so they were moved to a temporary hidden directory that will be deleted after restart. Moved dlls stay loaded in running applications, but can't be loaded by name/path anymore. And that's exactly the problem.
If one of these applications need to load an additional framework dll, the dotnet loader looks for this dll in the framework directory of the old version. This directory doesn't exist and so the application crashes because of DllNotFound or FileNotFound exception

Steps to reproduce

1. Create a .NET 5 WPF application with a button. In the click handler call a framework method from an assembly that isn't already loaded (e.g. MessageBox.Show(typeof(System.Printing.PrintPort).Name); )
2. Start this application on a system with installed .NET framework version 5.0.7
3. Activate Microsoft Update, search for updates and wait until version 5.0.10 is installed
4. Click the button of the WPF application
5. Crash

Application: WpfApp1.exe
CoreCLR Version: 5.0.721.25508
.NET Version: 5.0.7
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException: Could not load file or assembly 'System.Printing, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

With Procexp you can see the movement of loaded dlls.
Before .NET framework update

after .NET framework update

With Procmon you can see where the loader is searching for framework dlls after .NET framework update:

But this directory doesn't exist anymore.

You can reproduce this problem even easier. After an update of the .NET framework you only need to close the WPF application (no button click or custom code necessary). The application will crash again, but now you doesn't recognize it directly. You have to look into event log:

Application: WpfApp1.exe
CoreCLR Version: 5.0.721.25508
.NET Version: 5.0.7
Description: The process was terminated due to an unhandled exception.
Exception Info: System.DllNotFoundException: Unable to load DLL 'vcruntime140_cor3.dll' or one of its dependencies: Das angegebene Modul wurde nicht gefunden. (0x8007007E)
at __std_type_info_destroy_list(__type_info_node* )
at __scrt_uninitialize_type_info()
at _app_exit_callback()
at .LanguageSupport.DomainUnload(Object A_0, EventArgs A_1)
at .ModuleUninitializer.SingletonDomainUnload(Object source, EventArgs arguments)
at System.AppContext.OnProcessExit()

Because Window Update is running behind the scenes, and the described problems occur much later, it’s not easy to comprehend why the applications are crashing. .NET framework will be updated monthly and so there is a high risk that these types of problems appear.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[danmoseley]

@NikolaMilosavljevic any idea where this issue should go? WPF?

[NikolaMilosavljevic]

@NikolaMilosavljevic any idea where this issue should go? WPF?

This can stay in runtime as it is something that can be experienced with shared and desktop runtimes.

[danmoseley]

OK picked area-Setup.

[rkieslinger]

@danmoseley Is there an actual time table, when we can expect some feedback on this? We are in the middle of the release of our biggest update in years (migration from 4.7.2 to 5.0) and as the first small wave of customers got the update, this issue appeared and it seems huge.

[danmoseley]

❗ @NikolaMilosavljevic @vitek-karas can you help find someone to localize this one? It is blocking @rkieslinger update.

[vitek-karas]

@joeloff for the installer side of things. I don't think there's much the runtime can do here. If there's a way for the setup to leave the old version in place and only remove it upon next restart - that would probably be the best solution. But I don't know what is the contract with security servicing.

[rkieslinger]

If I remember correctly, the .NET Runtime update actually did install side by side, but the updates of the .NET Desktop Runtime and ASP.NET Core Runtime did not and so they are the ones that are causing issues.

@TRZLGast can you confirm that, just to be sure?

[joeloff]

I don't see much we can do from the setup side either. Upgrades uninstall. There's no way to defer a part of the upgrade until the next restart. Right now we install the new version and remove the old. That would break 99% of the cases where leveraging MU is removing the previously vulnerable pieces from the machine.

We introduced upgrades around 3.0 across the board. There are two models being used.

1. The shared host upgrades the actual MSI itself
2. For the standalone installs, runtimes + SDK, the new version of any MSI is laid down first before removing the old one.

This would be less of an issue for .NET Framework because assemblies would end up in the GAC I think

[rkieslinger]

So to sum it up, we just have these 2 options?

1. We tell our 20k+ customers, they gotta get used to a random monthly crash and that this is by design?
2. We disable .net updates via microsoft update on our customers computers (registry key BlockMU). Seems problematic, if there's other software on the computer using .net which is relying on them.

Doesn't MSI sometimes utilize PendingFileRenameOperations to delete files on the next reboot? Wouldn't that be a better solution, instead of snatching runtime files away from running applications?

Another approach which gets to my mind could be an entry in RunOnce to uninstall the old version safely at the next reboot?

[TRZLGast]

If I remember correctly, the .NET Runtime update actually did install side by side, but the updates of the .NET Desktop Runtime and ASP.NET Core Runtime did not and so they are the ones that are causing issues.

@TRZLGast can you confirm that, just to be sure?

Yes that's right.

before update:

after update (and restart):