Inside MSIX
Demystifying MSIX Architecture, Development, Deployment and Troubleshooting
Latest posts
Footprint vs Payload files
Payload files Payload files are files stored in and delivered by the package. This includes your code, assets, and data, such as executables, DLLs, images, configuration files, and resources. For example: Content files The term content is sometimes used in MSIX-related APIs and documentation, but it does not provide as clean a classification as payload and footprint. For example, the Packaging API associates a content type with payload files. To avoid ambiguity, we'll use payload file when referring to files stored in the package. Footprint files Footprint files are package metadata and infrastructur...
PackageType: Main, Framework, Resource, Optional, Bundle
Every MSIX package is one of four package types: MSIX also supports Bundle packages. Bundles are somewhat different from those four package types: a Bundle is a container for one or more MSIX packages. Windows APIs nevertheless expose Bundle alongside the other package types when identifying packages. Each package type has its own behaviors, nuances, and rationale worthy of a dedicated discussion. We'll take a brief whirlwind tour of MSIX package types here and explore them in greater detail in future blog posts. What does imply? What does actually mean? MSIX packages have various properties and beh...
MSIX PackageVolume: How Package Storage Works
An MSIX package can be staged in several ways and locations: By far the most common is PackageVolume. We'll dig into the rest in future posts, but for now let's focus on MSIX PackageVolume. In the beginning... When MSIX first appeared in Windows 81 packages would be staged to a unique directory under . More specifically, packages were placed in a subdirectory named with the package's full name. For example: Every package has a unique package full name, and thus is staged to a unique subdirectory within its package volume. This is commonly referred to as a pkgdir. This illustrates one of MSIX's ...
Servicing While In Use and ERROR_PACKAGES_IN_USE
How does MSIX service a package while it's in use? Simple: It doesn't. A core principle of MSIX servicing is: Do not service a package while it's in use. Deployment provides several ways to deal with that constraint. Options range from terminating applications to deferring servicing until the package is no longer in use. How hard can it be? 'Servicing a package' means any deployment activity modifying software, including update, remove, repair and other operations. Altering installed software can be highly disruptive if the software is in use. Executables and DLLs may be mapped into running processes. File...
What Kind of Packaged Process Is It?
As previously discussed, we can divide processes into the two broad categories of packaged vs unpackaged, based on if the process HAS or LACKS package identity. Packaged processes can be divided into three broad categories: All three have package identity, but they make different tradeoffs between compatibility and modern packaged behavior. RuntimeBehavior Packages specify how an application process is created and runs via multiple properties in . The RuntimeBehavior attribute clearly expresses this: is a Universal app. It was first introduced in Windows 81. New lingo appeared with it, initially ref...
What’s a PFN?
What's a PFN? MSIX introduced Package identity in Windows 8. While the familiar package identity "5-tuple" was functional, it wasn't especially convenient to pass through APIs or embed in resources such as files, registry keys, URLs, or XML documents. To address this, Windows defined an opaque string representation known as a Package Moniker. Windows called a related identifier derived from a package's Name and Publisher the Package Family Moniker. These were commonly abbreviated as PM and PFM. As development progressed, Windows quite sensibly required new APIs to pass through API Design Review. The review tea...
Remove and Package Lifetime
MSIX uses a Garbage Collection (GC) design for staged package lifetime and destaging. Throughout this article: Package Core Principles A staged package can't be destaged while any references to it exist. This is a direct consequence of MSIX's core architectural principles: Consequently, removing a package's payload from disk is not a direct result of a single API call. Instead, package payloads are automatically destaged when they are no longer needed. Even then, destaging may not occur immediately. Some actions that remove a reference don't directly trigger Deployment activity. In these cases,...
Remove Is Not Uninstall
Just as There is no Install – it’s ‘Stage’ and ‘Register’ explained that Install is not truly an installation operation in MSIX, Remove is similarly not an uninstall operation. This can be surprising - sometimes even alarming - to developers coming from traditional installer technologies such as MSI, where uninstalling software typically implies: In MSIX, that model simply does not exist. Remove = Deregister + (Maybe) Destage From MSIX Deployment's perspective, a package lifecycle consists of four fundamental operations: There's a symmetry here. Stage and Register do the work necessary to make ...
Package Integrity and Enforcement
A recent conversation started (as many interesting conversations do) with a simple question: "Why is MSIX secure?" MSIX includes multiple layers of protection designed to defend against both accidental damage and malicious tampering. But as with all good security solutions, it's not the individual elements so much as their interlocking design that makes the whole stronger than the sum of its parts. MSIX was designed around several core facets, integrated in sometimes novel ways. A packaged process can be trusted to a higher degree than most applications because Windows maintains a verifiable chain of trust fr...