Registry

The MSIX container for Win32 applications brings the App-V registry style of containerization support to the mainstream. This helps to solve some issues, like registry bloat and application interference with other applications, but isolation causes different issues that you might have to deal with as well.

The Windows Registry consists of a number of registry hives. Most technical people are already familiar with the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER hives of the registry. As a user logs into a Windows desktop, their personal user hive is loaded into the logon session as HKEY_CURRENT_USER. MSIX containerized applications use a new type of hive known as the Application hive. The Application hive is only loaded within the container processes when the modern app is started.

The application hive includes two major branches, MACHINE and USER. Similar to how the VFS allows the runtime to layer certain package folders over the local file system, these two application hive keys act as an overlay to HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER.

Having all these registry entries stored separately for each app means the end-user will get shorter boot and logon times, as Windows doesn’t have to load the registry entries for all the apps. The application hive becomes mounted only when the container is started.

For more information on how a package's file and registry items work under MSIX, visit Microsoft’s documentation.

Registry Format in the Package

The MSIX package format stores the containerized registry of the package in standard form of the registry “dat” format. An MSIX package can have up to three .dat files.

• Registry.dat
• User.dat
• User.Classes.dat

The User.dat file (when present) will contain a copy of the HKCU portion, and the UserClasses.dat file (when present) will contain a copy of the HKCU/Software/Classes area. It's a common assumption that these two extra files are used to boost performance for tools or components that only need to view those portions of the package registry. But, our experience has shown that the User.dat and User.Classes.Dat files only appear in the package when there are registry items in the package for the HKCU/Software/Classes area.

The .dat file format is a native registry file form, and if you need to view it, you can use a tool like RegEdit to import/export .dat files onto an existing key. The file is expected to contain a root key called “REGISTRY”, with sub keys for MACHINE and USER as needed for the equivalent to HKLM and HKCU on the native system.

Traditional Apps and Application Registry Hive: Possible Issues

When delivered, the .dat files within the package are immutable, meaning that the registry values themselves can never be changed when a user runs the application. Instead, similar to App-V changes attempted directly to the application hive might be redirected to another safe location. Originally this redirection was not supported by App-V, but redirection for registry writes for many “Current User” registry items was added to the 2004 OS runtimes. The Package Support Framework may be able to support additional cases not supported by the runtime itself.

We can't disregard the possibility of human error when including logic or appropriately handling error returns to registry calls in some scenarios. Some programmers may have never encountered the kinds of issues which can occur when running inside a container and could lead to the programming logic request to be reinstalled, for memory corruption to occur, or the application to crash.

There are no hard rules as to when an application will have an issue in a registry request. But predominantly, it usually depends on the following aspects:

• How the application makes the request. When the application makes a request to operate on a registry key or item, it includes a request for the needed permissions. For example, those permissions can include Read, Write, and Delete permissions, or owner and ACL information. One of the most common issues we see happening with MSIX is related to applications that ask for “full access in registry calls". While this was always allowed (at least for HKCU), it is not under MSIX. In particular, Deletion, ACLand Ownership permissions are disallowed by the MSIX runtime.

• The part of the registry the request is made for. HKLM andHKCU requests with the same access permissions may behave differently under the MSIX runtime.
• The version of the OS the app is running on. Microsoft can change the MSIX runtime behavior from one version of the OS to another. For example, the restrictions were lessened slightly in the 2004 version of the OS.

If the application source code is not available for modification to remediate the situation, the Package Support Framework has a registry fixup that may solve the issue by performing changes to the API calls made by the application.

When permitted, all Writes to the application hive are copy-on-written to a private per-user, per-app location, the same way AppData is handled.

This allows the system to easily delete all the registry entries created by the app during its lifetime. This process happens upon uninstallation and avoids the all-known registry rot that has been slowing down Windows machines for decades.

All of these hives are virtually merged at run-time with the registry found on the OS, allowing the app to “see” the entire registry as a singular resource. This dynamic merging permits the application to view the modified package hive layered on top of the package hive, which in turn is layered on top of the system hives.

A note for those familiar with the App-V virtual registry. The App-V virtual registry works in a similar functional way, except for two aspects:

• Under App-V, registry keys can contain a marker to indicate if layering should merge with the system hives, or override (hide) the equivalent system key. The override method was used to hide keys and values of a potentially natively installed version of the same application. MSIX always uses the merge method.

• Under App-V, registry keys and items can have deletion markers, indicating that the item should not exist as far as the app is concerned, even if it is present on a lower layer. MSIX (at this time) does not support any form of deletion markers.

Replacement of Registry Strings Containing File Paths

Typically, when a repackaging tool is used to generate an MSIX package from a traditional installer, the tool will automatically generate the .dat files for you. When these tools perform this action, they normally look for file string values that might be stored in the registry item values, either in Reg_SZ, Multistring, or Expandable string/multistring types. These file paths are usually altered to use file pathing relative to the package root folder.

As a case in point, the application might store the location of an important component upon installation, and then read that value to know where to look for it. On an x64 system, the file itself may have been written to “C:\Program Files” and is captured in the package under the “VFS\Program Files” folder. So, if the original registry value started with “C:\Program Files”, the reference string would change the beginning of the string to “VFS\ProgramFilesX64”.

Developers creating packages may use the same technique to help with portability.

Debugging the Containerized Registry

The isolation from the system’s regular hives provided by the use of Application hives means that you’ll have fewer problems with packages interfering with each other. However, in some cases, this isolation creates an impediment for inter-app communication through the registry. And, it also changes the way you debug your registry.

As an illustration, a ProcessMonitor trace will show registry references in different forms, depending on how the application determines the registry path. When the application starts with a hard coded base path in the application, you might see the ProcMon trace events using the “native path” (which gets redirected to the registry hive), but when the application uses a return path (taken from the registry) to form a new registry request, the path can appear in the ProcMon trace in the following form: “\REGISTRY\WC\Silo{id}user_sid\Software…” You can interpret this as an instance of the application hive for a current user path.

The Package Support Framework Trace fixup may also be added to the package to allow tracing of an exact Windows API call. This trace always shows the call as made by the application.

Either form of tracing can be used to determine when registry calls are failing, as well as remediation through application source code changes or other Package Support Framework based fixups.

It is often convenient to access the applications view of the registry using a tool like RegEdit. Accessing the registry using tools externally from the package container provides no access to the application hive of a package. These resources are only visible in the app’s container, so, you will need to launch your registry editor or command prompt directly into the container. If you enable "developer mode" on the OS, you can do this with a simple PowerShell command:

Invoke-CommandInDesktopPackage

Advanced Installer - MSIX PowerShell cmdlets provides some other MSIX PowerShell commandlets that you might find useful in testing or debugging situations.

You can also use the free Hover application built by the Advanced Installer team to speed up the process of running commands inside the package container environment.

Download it from: Advanced Installer - Hover.

OS Integration

As mentioned in the beginning of this chapter, the registry entries of an MSIX-packaged app are visible only inside its container - which means that other apps, including the OS cannot “see” the registry. Naturally, this characteristic changes some packaging habits.

Registry entries to define resources like FTAs, update PATH environment variables, or add COM components, are ignored. All of these resources must be declared in the Package Manifest for them to be integrated into the OS when the application is installed. Most repackaging tools will migrate these settings for you.

See section "AppxManifest.xml aka the Package Manifest” more details.