MSIX PackageVolume: How Package Storage Works

An MSIX package can be staged in several ways and locations:

• PackageVolume
• Development Mode
• System package
• StageInPlace
• External Location

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 8¹ packages would be staged to a unique directory under Program Files. More specifically, packages were placed in a subdirectory named with the package’s full name. For example:

C:\Program Files\WindowsApps\Contoso.PointOfSale_1.2.3.4_x64__1234567890abc

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 core reliability principles: avoid updating packages in place.

Package isolation, sometimes called “side-by-side” behavior, allows MSIX to stage a package without modifying another package. Downloading and writing the new package can therefore take considerable time without making the existing package unavailable.

It also avoids a classic source of broken software: an update-in-place operation that fails after modifying only part of an existing installation.

PackageVolume enters the room…

This installation store is owned and managed by Windows. Because it was originally the only location where packages could be staged, it was often referred to internally as the Single-Instance Store (SIS).²

Windows Mobile 8.1 introduced support for installing packages on non-System disk volumes, including removable media such as SD cards.³ New APIs were introduced to create and manage installation stores on other disk volumes, with the new abstraction officially named PackageVolume.

As there could now be multiple ‘installation stores’ on a system, the phrase Multiple-Instance Store (MIS) started to make the rounds. Fortunately it never got traction and disappeared relatively quickly. A swing and a MIS, if you will 🙂 The SIS phrase also faded from use, leaving PackageVolume as the only phrase in the glossary.

Windows later added support for network shares.

MSIX originally required NTFS, but the list of supported file systems has grown over the years. This now includes FAT, FAT32, exFAT, ReFS, XRFS and CimFS. However, not every feature is available on every file system. For example, MSIX’s disk space optimization requires hardlink support, which FAT, FAT32, and exFAT don’t provide.

Adding an MSIX PackageVolume

Package volumes can be defined and managed via the PackageManager API. For example, to create a PackageVolume:

var packageManager = new PackageManager();
var path = "Q:\\My\\Packages\\Go\\Here";
var volume = await packageManager.AddPackageVolumeAsync(path);

or the Add-AppxVolume PowerShell cmdlet:

Add-AppxVolume 'Q:\My\Packages\Go\Here'

This creates the directory Q:\My\Packages\Go\Here, ready for packages to be staged.

A default path is used if you specify a drive with no path. For example:

Add-AppxVolume 'Q:'

creates Q:\WindowsApps.

Default PackageVolume

Deployment APIs accept an optional PackageVolume parameter. If specified, the package will be staged to this package volume.

One of the package volumes is marked as the default package volume. Deployment uses this volume when an operation doesn’t specify a target PackageVolume.

Offline PackageVolume

If a package volume is defined on a disk volume that’s made unavailable, Windows’ storage subsystems notify Deployment, which marks the package volume offline and sets the PackageOffline package status for every package on that volume.

For example, suppose a USB flash drive appears as E: and a package volume is created on it. Removing the drive makes the package volume unavailable. The package volume remains defined, but Windows marks it offline, along with the packages staged on it.

Reinsert the drive and Windows can bring the package volume and its packages back online.

A PackageVolume By Any Other Name…

How is a package volume identified? For instance, removable media can change drive letters over time. Likewise, network shares have no drive letter.

A package volume is uniquely identified by the underlying storage volume’s media ID. This identifier is independent of the volume’s current mount point, so changing a drive letter doesn’t change the identity of the package volume.

APIs

MSIX offers a wealth of PackageManager APIs and PowerShell cmdlets to manage package volumes:

• Add – AddPackageVolumeAsync, Add-AppxVolume
• Remove – RemovePackageVolumeAsync, Remove-AppxVolume
• Find/Enumerate – FindPackageVolume(), FindPackageVolumes(), GetPackageVolumesAsync(), Get-AppxVolume
• Get Default – GetDefaultPackageVolume(), Get-AppxDefaultVolume
• Set Default – SetDefaultPackageVolume(), Set-AppxDefaultVolume
• Set Offline – SetPackageVolumeOfflineAsync(), Dismount-AppxVolume
• Set Online – SetPackageVolumeOnlineAsync(), Mount-AppxVolume

Package volumes are also accepted by package operations such as AddPackageOptions.TargetVolume and MovePackageToVolumeAsync(). PowerShell provides equivalent functionality through parameters such as -Target and cmdlets such as Move-AppxPackage.

Non-System Package Volumes are Encrypted

Some of MSIX’s protections and integrity guarantees depend on Windows enforcement. These protections could be bypassed by moving storage containing staged packages to another system.

To mitigate this threat, MSIX encrypts package files in all non-System package volumes. The System package volume is exempt from this behavior.⁴

This protection applies to packages staged in a PackageVolume; it isn’t general-purpose volume encryption. For broader protection of the volume and its contents, use technologies such as BitLocker.

¹ The MSIX packaging platform originated as APPX in Windows 8 and has evolved substantially over time.

² Multiple-drive support was desired, but schedule constraints pushed it to a future release. Bringing up a new technology like MSIX is a substantial undertaking, so many good ideas couldn’t make the initial release.

³ This enhancement quickly propagated to other Windows SKUs with the first release of Windows 10.

⁴ The primary threat addressed here is offline access to package files after removable or secondary storage is moved to another system. Applying the same protection to the System volume offered substantially less benefit because that storage is not ordinarily removable independently of the system.