How to stop a long-running exe process (part of the package) and started by the app gracefully when the package is updated

[JosHuybrighs]

I have a WinUI/WinAppSDK desktop app in the Microsoft Store which, after being installed must be prepared to carry out various activities in the background and this both when the app is opened and closed. These activities are:

• A 15 minutes time triggered check whether the app must be started to do folder backup/sync.
• Do a folder backup/sync automatically after logon.
• Start the app when a configured USB storage device is inserted.
• React on requests coming from a trusted mobile device to upload media files over WiFi.

Except for the last service one can wonder why the app isn't using the BackgroundTask principles of WinAppSDK to handle this but as it has been pointed out in various topics about this (see #4014, #2322, #4115 ) at this moment only the timer triggered BackGroundTask really works in WindowsAppSDK.

Hence, my current solution unfortunately is to add a small "windows.startupTask" executable to the package that starts the first time the app is opened and then automatically each time the computer starts. It uses a PeriodicTimer to wait for the timeout, DeviceInformation.CreateWatcher to handle USB device inserts, and a TCP server implementation to listen for multicast messages. Of course it most of the time must do nothing. The 'main' part must wait in principle forever and does this as follows:

[STAThread]
static void Main(string[] args)
{
   ..
   bool keepRunning = true;
   while (keepRunning)
   {
      sAutoResetEvent.WaitOne();
      keepRunning = false;
   }
   ..
}

This works without any problems and also has little or no impact on resources in the system.
The only issue is that when the app is updated Windows can't gracefully shutdown the 'background' process resulting in errors in the Windows Event Log.

An "AppIsToBeUpdated" trigger would be beneficial here but it unfortunately doesn't exists. Are there other possibilities to make this better? Is there some kind of message that I can react upon to kill the process myself? I tried to change the exe to work with a message pump but the windows triggered 'kill' request doesn't come in.

[whiskhub]

My idea was to add a message only window, which handles WM_CLOSE and would shut down the process if that message is received. This works for taskkill, but not for "MSIX" shutting down the process.

I'm afraid that you'll need a visible window, otherwise it doesn't work. But I didn't test it enough. Hopefully someone at Microsoft could explain us, how Windows shuts down the processes when a MSIX package is being updated.

[JosHuybrighs]

@whiskhub
Thanks for the quick reply. As you mentioned hopefully we get some feedback from Microsoft.

[mominshaikhdevs]

@DrusTheAxe

[DrusTheAxe]

The only docs documents the current behavior:

Each active window in your application receives a WM_QUERYENDSESSION message. At this point, your application can call the RegisterApplicationRestart function again to update the command line if necessary.

When each active window in your application receives the WM_ENDSESSION message, your application should save data and shut down.

Note

Your active windows also receive the WM_CLOSE message in case the application doesn't handle the WM_ENDSESSION message.

At this point, your application has 30 seconds to close it's own processes or the platform terminates them forcefully.

After the update is complete, your application restarts.

Key phrase being each active window in your application. An "active window" is defined as the window that is currently in the foreground and receiving input from the keyboard and mouse.

P.S. The section heading is overly narrow and should be "Restart automatically after receiving an update from the Microsoft Store". The shutdown-via-Windows-messages for Centennial/DesktopBridge/PackagedClassicApp/:-) processes to unblock servicing a package in use is core MSIX behavior regardless where the package comes from.

[whiskhub]

Thanks for the reply!
And there's no way to have an active window, that is not visible, right? So that means there is no way to let "background" processes be shut down gracefully, without getting a crash error in the Event Log. That's not very nice :/

[JosHuybrighs]

I reworked my "Background" process and made it a WPF app. Apparently this works also when the window is hidden. The app gets both a "SessionEnding" and "Exit" event when the package is updated and when the computers is switched off. Like so:

    public partial class BGApp : Application
    {
        static CancellationTokenSource sCancelTokenSource = new CancellationTokenSource();
        static LogonWatcher sLogonWatcher;

        [STAThread]
        public static void Main()
        {
            var localFolder = ApplicationDataManager.CreateForPackageFamily(Package.Current.Id.FamilyName).LocalFolder;
            string filePathName = Path.Combine(localFolder.Path, "SyncFolder.BackgroundTasks.log");
            var loggingLevel = (ConditionalFileLogger.LoggingLevel)AppSettings.Instance.LoggingLevel;
            ConditionalFileLogger.Enable(loggingLevel, filePathName, "SyncFolder#BackgroundTasks",
                                         maxSize: 100000, maxBackups: 0);

            var app = new BGApp();
            app.InitializeComponent();

            app.Run();
        }

        protected override void OnStartup(StartupEventArgs e)
        {
            base.OnStartup(e);

            // Create the main window but do not show it
            BGAppMainWindow mainWindow = new BGAppMainWindow();
            mainWindow.Hide();

            this.Exit += OnBGAppExit;
            this.SessionEnding += OnBGAppSessionEnding;


            var currentUser = WindowsIdentity.GetCurrent();
            bool isAuthenticated = currentUser.IsAuthenticated;
            bool isSystem = currentUser.IsSystem;
            string userName = currentUser.Name;

            Package package = Package.Current;
            PackageId packageId = package.Id;
            PackageVersion version = packageId.Version;
            var versionStr = $"{version.Major}.{version.Minor}.{version.Build}";

            ConditionalFileLogger.LogPrependNewLine($"Services - Started (v{versionStr}), Args: {_commandLineArgs.Length} ({_commandLineArgsStr}), Username: {userName}, isAuthenticated: {isAuthenticated}, isSystem: {isSystem}");

            CancellationToken ct = sCancelTokenSource.Token;

            // Start IPCServer
            IPCServer.Instance.Start(ct);

            // Start ScheduleBackupTask
            var schedBackupTask = new TaskSchedular();
            schedBackupTask.Start(ct);

            // Start PortableDeviceWatcherTask
            var pwdWatcher = new PortableDevicesWatcher();
            pwdWatcher.Start();

            // Start LogonWatcher
            sLogonWatcher = new LogonWatcher();
            sLogonWatcher.Start(_commandLineArgs.Length == 2);

            // Start NetworkDevicesServer (if enabled)
            if (AppSettings.Instance.CompagnionAppEnabled)
            {
                NetworkDevicesServer.Instance.Start();
            }

        }

        public static void ExitApplication()
        {
            ConditionalFileLogger.Log("SyncFolder.BackgroundServices - Got Exit request from host");
            // Issue request to cancel all tasks
            sLogonWatcher?.Stop();
            sCancelTokenSource.Cancel();
            // Exit
            Application.Current.Shutdown();
        }

        private void OnBGAppSessionEnding(object sender, SessionEndingCancelEventArgs e)
        {
            ConditionalFileLogger.Log("SyncFolder.BackgroundServices - Got SessionEnding event");
        }

        private void OnBGAppExit(object sender, ExitEventArgs e)
        {
            ConditionalFileLogger.Log("SyncFolder.BackgroundServices - Got Exit event, request all tasks to exit");
            // Issue request to cancel all tasks
            sCancelTokenSource.Cancel();
            ConditionalFileLogger.Log("SyncFolder.BackgroundServices - Process terminated");
        }
    }

Although I'd rather would like to see better support for all kind of background tasks in the WindowsAppSDK, I can live with this.
The only issue you have to take care of is that you must rename the App and MainWindow classes of the WPF project into something like BGApp and BGMainWindow because otherwise you will get build errors in Visual Studio because the same classes are also present in the main UI app. The footprint of the WPF app with some additional dll files is also a little bit bigger than with for instance a WinForms app.