MSIX App Activation Explained: How Windows Starts Packaged Processes Beyond the Start Menu

Activation is not CreateProcess​

Most of us picture an app launch as a CreateProcess() call spinning up a new process. For packaged apps, Windows has a specific term for bringing an application to life: activation.

Kapustein says activation does more than create a process. Among other things, it creates the new process with the appropriate package identity. His post adds two claims:

• Activation verifies that the package is in an appropriate state before the process starts.
• It can start repair, also called remediation, when the package isn't in that state.

Those two claims come from the post itself. Microsoft's Learn documentation backs up the importance of package identity but doesn't describe the state check or remediation in detail. Treat the repair behavior as the author's description, not a documented troubleshooting procedure.

This "activation" has nothing to do with product keys or licensing. It is the packaged-app lifecycle term.

What counts as an activatable extension point​

The post's definition is simple: an activatable extension point is something Windows can activate. <Application> declarations and certain <Extension> declarations qualify, and those declarations can cause Windows to activate a packaged process.

"Certain" matters. The post does not say every manifest extension starts a process. It also warns that <Extension> elements show up in many XML namespaces, so the prefix isn't the concept. Its examples of <Extension> declarations are:

• uap17 with windows.packageExtension
• com4 with windows.comServer
• desktop9 with windows.fileExplorerClassicContextMenuHandler

These are examples, not a complete list.

Three ways a packaged process can start​

The post separates obvious triggers from less obvious ones:

The COM and WinRT case is the surprising one. Code that asks for a class can cause Windows to start a packaged process, with no user clicking an icon.

What Microsoft's documentation adds​

The Application element. The Learn schema page says the Application element's attributes are also used as activation info in the startup and management of an instance of the app. In its words, they describe how to start a process and with what behavior. Executable is the default launch executable, and EntryPoint is the activatable class ID.

Activation settings can be inherited. Activation attributes can be set on the Application element. They can optionally be set on an app-scope Extension element too. If an extension doesn't set them, it inherits them from the parent Application.

Not every extension is a separate process. The package-level Extension page lists in-process and out-of-process server categories. An in-process server is a DLL exposing activatable classes. An out-of-process server is an EXE exposing them. That is why the post's COM example is specifically out-of-process.

Version and combination limits. The uap10 attributes RuntimeBehavior and TrustLevel arrived in Windows 10 version 2004 (build 19041). If a package installs on older systems, it needs equivalent activation attributes, otherwise the activation info will be incomplete, and the install will fail. Some combinations are also invalid. For example, win32App with appContainer trust isn't supported.

Package identity gates the integrations. Learn's list of features that need package identity includes background tasks, push notifications, custom context-menu extensions, share targets, manifest-based file and protocol associations, startup tasks and app services. Apps packaged with external location can also have identity on Windows 10 version 2004 or later.

A namespace detail to watch​

The post's example for hosted runtimes uses uap5 with windows.hostRuntime. Microsoft's current hosted-apps documentation shows the same category under the uap10 namespace. In that model:

• The host declares the runtime with a uap10:HostRuntime element carrying an Id.
• The hosted app refers to that Id through uap10:HostId, instead of naming its own executable.
• Windows then launches the host executable under the hosted app's identity.

The hosted-apps page says the feature starts in Windows 10 version 2004. I can't tell from the evidence whether the post's uap5 example is a typo, a legacy form or something else. Check the exact schema version before copying either into a manifest.

Why this matters in practice​

• Developers: Think about the manifest entry point and the trigger, not just the EXE name. A file association or an out-of-process class request can start your packaged process, with no visible launch. Test those paths separately.
• IT admins and support staff: A packaged process may appear because of a shell action or a component request, not a direct Start-menu launch. This is my inference from the documented scenarios, not a diagnostic method the post describes.
• Security-minded readers: Every activatable declaration is a way for Windows to start code in your package. Review those declarations when auditing an MSIX package. That is general industry reasoning, not a finding from the post.

Related series​

The post follows Kapustein's recent "Is it MSIX?" entries on finding package identity. Part 3, published October 13, covers TASKLIST and PowerShell. Part 2, published October 6, covers the identity APIs. Together they give a reasonable path from "is this process packaged?" to "how did Windows start it?"

Bottom line​

This is a vocabulary post, and a useful one. It introduces no new capability, so don't expect new behavior in Windows. It does name a concept that clears up why packaged processes sometimes appear without an obvious launch. It also draws a line that matters for manifest authors: only certain extensions are activatable, and the schema prefix tells you little about which.