Known Issue: FlexApps Close When .NET Is Updated

Why did every running FlexApp close in the middle of the day, with no error, while Windows Update was installing a .NET update?

On endpoints running ProfileUnity Client 6.9.5, a Microsoft .NET 10 update that installs while users are signed in closes every running FlexApp. No error or crash is reported, and unsaved work in those applications is lost. The update restarts the FlexApp Container Service, as it can restart any service that runs on the shared .NET runtime, and the Container Service closes FlexApps when it stops. It is avoided by installing .NET updates outside working hours. This article explains why it happens, how to confirm it, and how to schedule .NET updates so users are not affected.

Status

Symptoms

• All FlexApps open in the user's session close at the same moment, during the working day, with no error message.
• The Application log has no Application Error or crash event for the closed applications.
• At the same time, a .NET 10 update, such as a monthly .NET security update, was installing through Windows Update or another update tool.
• FlexApps may not start again in that session until the user signs out and signs back in.

.NET 8 and .NET Framework updates do not cause this on a 6.9.5 client, because the client does not use those runtimes for the Container Service.

Cause

FlexApps run through the Liquidware Labs Container Service (VirtFsService.exe). In ProfileUnity 6.8.6 and 6.8.7, the service carried its own copy of the .NET runtime inside its program file, so .NET updates never touched it; earlier versions ran it on .NET Framework. From 6.9.5, the client installs .NET 10 and a Container Service that runs on that shared runtime, as noted in Announcing ProfileUnity FlexApp 6.9.5. This allows smaller FlexApp installers and lets .NET be updated separately from ProfileUnity.

A .NET update installs the new runtime version and removes the previous one. While the Container Service is running, it is using the previous version's files, so the update uses Windows Restart Manager to stop the service, release the files, and restart the service once they are replaced. If the files cannot be released, the update asks for a device restart instead and finishes then. Other applications and services that run on the shared .NET runtime can be stopped and restarted the same way.

Whenever the Container Service is stopped, it ends the FlexApp application processes it is running. That is not new in 6.9.5; what is new is that a .NET update is one of the events that can stop it.

How to Confirm

Run the checks on the affected endpoint and compare the times with when the FlexApps closed.

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WindowsUpdateClient'; Id=19,43} | Where-Object Message -like '*.NET*' | Select-Object TimeCreated, Id, Message

Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Microsoft-Windows-RestartManager'; Id=10002,10003} | Where-Object Message -like '*Container Service*' | Select-Object TimeCreated, Id, Message

Terminating redirected process:

Scheduling .NET Updates

Treat .NET updates on ProfileUnity 6.9.5 endpoints the way you treat updates that need a restart: install them when users are not working in FlexApps.

• Microsoft Intune update rings: .NET updates arrive through Windows Update when Microsoft product updates is set to Allow. For laptops and other user devices, set Automatic update behavior to Auto install at maintenance time, which installs when the device is not in use. For devices that stay powered on overnight, Auto install and restart at a scheduled time with a time outside working hours also works; a device that is off or asleep at that time waits for the next scheduled time or a deadline. A deadline can force an installation during the working day, so check deadlines as well.
• Group Policy: in Configure Automatic Updates, select 4 - Auto download and schedule the install and set Scheduled install time outside working hours.
• WSUS: .NET updates are listed under Developer Tools, Runtimes and Redistributables. Approved updates install on the Group Policy schedule above, unless an approval deadline has passed.
• Configuration Manager: deploy .NET updates to a collection with a maintenance window outside working hours.
• Session hosts (RDS, Azure Virtual Desktop): stop new sessions on the host, sign users out, install .NET updates, and then restart the host (see When signing users out is not enough). In Azure Virtual Desktop, drain mode or a scheduled session host update handles the sign-out.
• Non-persistent desktops: apply .NET updates to the base image rather than to running desktops.

When signing users out is not enough

When users are signed out while the update installs, FlexApps assigned at sign-in are normally removed at sign-out, so the Container Service restart does not affect them. On the following endpoints, FlexApps stay in place after users sign out, and the restart removes them even when nobody is signed in:

• Application Preservation Mode is enabled in the configuration.
• The Remote Desktop Services role is installed. FlexApp One packages are not removed at sign-out on these hosts.
• FlexApps are assigned at the machine level, through ProfileUnity running as a service.

On these endpoints, install .NET updates in a maintenance window that ends with a restart of the device, so FlexApps are set up again when the device starts and users sign in.

If FlexApps were closed by a .NET update, have the user save any work in other applications, sign out and sign back in. FlexApps are started again at the next sign-in. On the endpoints listed under When signing users out is not enough, restart the device instead.

FAQ

Related Articles

• Managing .NET Core Security Updates for ProfileUnity FlexApp - Console and Client Side
• Announcing ProfileUnity FlexApp 6.9.5