[MSIX] Running Packaged Win32 Apps (console only ones included) (multiple instances running included) regardless of ILs, Do Not Get Terminated Instantly.

[mominshaikhdevs]

Describe the bug

As Per the title. After Clicking Uninstall from the start menu, the running app and all of its associate running window instances should be terminated instantly. Observe that, The App and All of Its associate running window instances do run for quite a time and Windows still lets the app function as its normally run, This happens for quite a time (about ±1 min), until suddenly It's all BOOM, disappeard for good.

This issue does not happen processes running as "UWP apps" (CoreWindow + LowIL/AppContainer + MSIX). They do get terminated instantly, when clicked Uninstall from the start menu.

Steps to reproduce the bug

Happens in any packaged Win32 Apps that do not use "CoreWindow"(is UWP).

Expected behavior

those apps should be terminated instantly like they manually get from The Task Manager Treatment. They do not behave so when running unpackaged. So, this is yet another MSIX Bug.

Screenshots

No response

NuGet package version

None

Packaging type

Packaged (MSIX)

Windows version

No response

IDE

Visual Studio 2022-preview

Additional context

[DrusTheAxe]

This is an OS topic, not specific to Windows App SDK.

This happens for quite a time (about ±1 min)
Do you have a specific example?

the running app and all of its associate running window instances should be terminated instantly
They are stopped relatively quickly, but maybe not instantaneous due to system load and/or the app is first asked to politely shutdown.

Uninstall amounts to pkgmgr.RemovePackageAsync() which implicitly acts with a 'Force' i.e. shutdown apps using the package before proceeding with the removal work. If a package is in use Windows asks it politely to stop, and if it doesn't Windows will terminate with extreme prejudice (TerminateProcess).

For processes running as RuntimeBehavior="packagedClassicApp" or "win32app" the "ask politely" is WM_CLOSE + WM_ENDSESSION events, and after a timeout exhausing Windows' patience, TerminateProcess. This is documented at https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#restart-automatically-after-receiving-an-update-from-the-microsoft-store. Apps sluggish to respond to the polite shutdown request can make uninstalls not-instantaneous.

MSIX follows this "Be nice...until it's time to not be nice" mantra. This is ByDesign, to give apps a chance to politely unwind from active system state. This helps avoid system instability. Immediately leaping to TerminateProcess can create problems e.g. if the app's communicating and sharing resources with other processes.

This seconds-not-instant isn't unusual for uninstallers. Any uninstaller has to run, then determine its work, then decide if any processes are running using the about to be uninstalled resources and then stop them (one way or another). That is often not instantaneous.

[DarranRowe]

@DrusTheAxe

Since this is about console applications, would console applications use the console control handler? Otherwise this would indicate that a console application that is running in a package would need a window to monitor for these events.

[mominshaikhdevs]

MSIX follows this "Be nice...until it's time to not be nice" mantra. This is ByDesign, to give apps a chance to politely unwind from active system state. This helps avoid system instability. Immediately leaping to TerminateProcess can create problems e.g. if the app's communicating and sharing resources with other processes.

that all good and nice.

but, when I said:

They do not behave so when running unpackaged.

dont need to go very far. .NET console apps are perfect examples. :)

Happens in any packaged Win32 Apps that do not use "CoreWindow"(is UWP).

This issue does not happen processes running as "UWP apps" (CoreWindow + LowIL/AppContainer + MSIX). They do get terminated instantly, when clicked Uninstall from the start menu.

Does that mean, Windows assumes Any win32 packaged apps are essentially:

Apps sluggish to respond to the polite shutdown request can make uninstalls not-instantaneous.

?

If so, It still is a MSIX Bug.

[DarranRowe]

@DrusTheAxe

Since this is about console applications, would console applications use the console control handler? Otherwise this would indicate that a console application that is running in a package would need a window to monitor for these events.

Well, I decided to answer my own question. When it is a console application, Windows sends Ctrl+C to the application. So if the application is not terminating then it is a long running application without Ctrl+C handling enabled.

If so, It still is a MSIX Bug.

It isn't. Happily calling TerminateProcess is a really bad thing. If the console application is communicating via some channel, or is writing to some location that isn't private to the package (like the registry or Documents), then just terminating the application can corrupt data or cause other problems. You have to remember that console applications packaged like this would more than likely started life as some free floating console utility with some major assumptions about the system capabilities.

Very few uninstallers would happily terminate without giving the application a chance to cleanly shut down, some even forces the user to choose how to handle the case when the application is still running. So I personally feel that it would be more surprising and more problematic if the application just terminates.

It is also not a problem with how Windows handles the uninstallation process if the console application doesn't register for console events.

[mominshaikhdevs]

It is also not a problem with how Windows handles the uninstallation process if the console application doesn't register for console events.

that's a reasonable argument. Thus, Closing.

[DrusTheAxe]

@DrusTheAxe

Since this is about console applications, would console applications use the console control handler?

Sorry, I forgot to mention a Ctrl-C event is (also?) sent to the process (process' console(s)?) to handle the console cases -- console apps, winmain apps with associated consoles (e.g. AllocConsole()), etc

Apps should register/listen for the usual "go away" notifications and respond to them in a timely manner.

As @DarranRowe rather eloquently noted, abruptly terminating a process can cause data loss, data corruption, instability and other woes. We use TerminateProcess as the ultimate backstop if/when a process is unresponsive (not-nice). We try to avoid pulling that trigger unless absolutely necessary but if we have to, better that than a hung system.