Why is the MSIX Registry not visible on the machine?

Written by Alex Marin · January 18th, 2022

#MSIX

Based on my experience, when working with beginner IT Pros who are starting out with MSIX, there's a common misconception when defining registry keys.

They often assume that they can define registry entries inside the MSIX control settings on the OS or non-virtualized apps, just like they can in MSI.

But very soon they find out that registries work differently in MSIX, and they actually CAN'T be seen on the machine.

To sort this mix-up, in this article we will go back to the basics of MSIX so we can understand how the registry operates with it. Before we do that, let's review how containers work.

MSIX Registry - How MSIX Containers work

As described in our MSIX Introduction article, the MSIX container combines the support from Desktop Bridge apps with the one UWP apps – as shown below.

Unlike APPX, MSIX supports Win32 Apps, giving the user the possibility to create a container for traditional Windows applications.

The MSIX container provides access to new Windows 10 features, like enhanced security and access to new UWP APIs, but it also imposes some limitations.

Find the complete list of Microsoft’s recommendations and limitations in the following article: prepare to package an app (Desktop Bridge).

In the image above, we can see that the MSIX container has permission to access Kernel locations including:

the file system, registry
resources,
NTUSER

However, anything that is stored inside the container is only accessible by the MSIX app itself and not the entire system.

Also, if an MSIX application is required to write in a particular registry hive, it will only write and be visible in the MSIX hive. We explained this in more detail in our AppData Management in MSI/MSIX/APPV article.

There are ways to disable the default redirection, but it is not a recommended practice by Microsoft. Keep in mind that if you ever need to publish your application in the Microsoft Store, you need to have a very good reason for Microsoft to accept this behavior in your application.

How does the registry work in MSIX?

We now know that the registry in MSIX is not accessible to other Win32 applications or OS settings. But, how does it really work?

The registry hive in MSIX is not loaded and cannot be seen in the registry editor, but you can find it in the registry.dat file present in %ProgramFiles%\WindowsApps\PublisherName.AppName_AppVersion_architecture_hash

First example - registry is available only in the MSIX container

Let's consider the following scenario:

If we open up a sample MSIX application, we can see that it contains the registry.dat file.
Once the user starts the application, the registry.dat file is merged with other registries present on the system.
This merge allows the application to have full visibility of the registry hives.

What exactly does this imply?

It means that the registry is NOT available until you start the application, and even after you launch it. The registry is still not present on the machine - it is located only in the container of your MSIX application.

Second example - Triggering a program to run at Startup through registry or shortcut

Another scenario worth noting is related to Startup applications. With MSI, you were able to trigger a program to run at Startup.

You could choose to place any of the following:

A user registry key in HKCU\Software\Microsoft\Windows\CurrentVersion\Run
A machine registry key in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
A shortcut in the Startup Folder.

This is not the case with MSIX - you can't use any of the above methods to trigger a program to run at Startup because neither the registry or shortcut are available per machine.

This is why MSIX introduced classes in the AppxManifest.

To tackle this, we use the StartupTask Class to define that a particular application needs to be launched after the system is started and the user is logged into the machine.

Conclusion

To sum up, we hope we were successful in explaining why your MSIX registries are not visible on the machine.

Configuration of the system is NOT something that MSIX is designed to do, as we saw earlier.

As an alternative, you can use Group Policy Objects (GPO) or other methods like MSI, and scripting to carry out this system configuration task.