The MSIX Runtime Layer Mapping and PSF

Tools like the Microsoft MSIX Packaging Tool will routinely capture file location information and store these paths by using VFS variables as an indication of where that location would be interpreted on any potential target system that is set up differently, which increases portability. The MSIX package format stores file paths for the file system using these variables, and any registry values that contain file paths are also parsed and variablized.

While the MSIX format supports a wide range of VFS locations that may be present in the package, not all of these locations are treated the same way by the MSIX runtime (a name we can use for the support for interpreting these variable path information), leading to many traditional applications packaged into MSIX as needing the Package Support Framework.

When the MSIX runtime has support for a VFS variable, it causes files in those locations within the package to act as a layered overlay over the native location. This means that if the app tries to access files using the native path (for example, on an x64 OS, "C:\Windows\System32") the application in that runtime container would see all of the native files and folders in that location overlayed by those in the package VFS path (for example "C:\Program Files\WindowsApps\PackageFamilyName\VFS\SystemX64"). The app can also directly reference package files by using the package VFS path, but when it does it will only see the package files. Because applications are developed so differently, some applications will use native pathing, while others will use the package path, and some will use a mixture of the two in different parts of the application. This makes it often desirable to try to control the application packaging in ways that trigger the application to use native pathing with the layering, or alternatively to try to get it to always use package pathing. For a majority of applications, the former is usually preferred as it allows for improved integration with the OS and other applications.

As we look into the details of how some applications work, the success of layering is also sometimes impacted by how the application makes certain requests. Some approaches, such as the use of FileFind APIs work well, while others where the application directly opens a reads the list from a directory file are more problematic and lead to layering issues, even with the PSF. Ultimately, the dll injection techniques used by the PSF are less comprehensive/effective than filter drivers for such things.

Support in the MSIX runtime for a variable mapping from local path to overlay the package path applies to the visibility of the application to those files and folders. Separately, there is a second part of the runtime support that controls whether or not the application can make changes to files. When supported, this generally leads to those changes being redirected to a package-specific path in the user's AppData\local\Packages directory. The PSF FileRedirectionFixup (and MFRFixup in the future) are added to packages to help with applications that need to modify package files.

The documentation by Microsoft on how all this works is spotty at best, and this page attempts to provide what has been determined through testing. The table below shows VFS variables that have been detected as used by the MSIX packaging tool, and the differing support we see in the MSIX Runtime and with the PSF FileRedirectionFixup:

• MMPT Mapping indicates whether we have detected that the Microsoft MSIX Packaging Tool variablizes these locations when capturing. Testing has shown that this support appears to be consistent in both file locations and variablization of file paths in registry values, however it is not certain that the support is 100% consistent.
• RT Visible indicates whether the MSIX runtime supports native path requests include the package VFS path layer to see package files and sub-folders. These results are from testing against the MSIX runtime in Windows 10 21H2 and may be different on different OS versions as Microsoft has been improving this support from earlier versions and may continue to do so in the future. This column assumes that the package did not include the Capability setting XXXXXX.
• RT Write indicates whether the MSIX runtime support automatic redirection to the package-specific folder for writes to the package path. This column assumes that the package did not include the Capability setting XXXXXX.
• Cap Visibile indicates whether the MSIX runtime in a package that has the XXXXXX capability set, supports native path requests include the package VFS path layer to see package files and sub-folders.
• Cap Write indicates whether the MSIX runtime in a package that has the XXXXXX capability set, support automatic redirection to the package-specific folder for writes to the package path.
• FRF Visibile indicates whether the FileRedirectionFixup supports native path requests to include the package VFS layer to see package files a subfolders.
• FRF Write indicates whether the FileRedirectionFixup "typical configuration" supports automatic redirection to the package-specific folder for writes to the package path. Note that this support actually is implemented as a Copy-on-Access, and even if the app tries to open package files for read purposes this copy and redirection will occur. Additionally, in the typical configuration, executable files are excluded from Copy-on-Access.
• Whenever there are two variables that represent native paths where one is a subset of another, the MMPT packaging will choose the mapping that represents the longer of those. For example, SYSTEMX64 will be used for a file in the "C:\Windows\System32" folder rather than the variable "Windows". The VFS variable AppVPackageDrive acts as a "catch-all" way to handle the variablization of path locations not covered by other path locations. We see this used most often when the application that installs to a "C:\VendorName" folder that is mapped to "VFS\AppVPackageDrive\VendorName" in the package.
• The native paths shown are assuming an x64 OS. The 32bit OS uses a subset of these mappings and sometimes different mappings.

Native Path	MMPT Mapping	RT Visible	RT Write	Cap Visible	Cap Write	FRF Visible	FRF Write
C:\Program Files (x86)\Common Files	ProgramFilesCommonFilesX86
C:\Program Files\Common Files	ProgramFilesCommonFilesX64
C:\Program Files (x86)	ProgramFilesX86
C:\Program Files	ProgramFilesX64
C:\Windows\System32\Catroot2	AppVSystem32Catroot2
C:\Windows\System32\Catroot	AppVSystem32Catroot
C:\Windows\System32\drivers\etc	AppVSystem32DriversEtc
C:\Windows\System32\driverstore	AppVSystem32Driverstore
C:\Windows\System32\Logs	AppVSystem32Logfiles
C:\Windows\System32	SystemX64
C:\Windows\SysWow64	SystemX86
C:\Windows\System	System
C:\Windows\Fonts	Fonts
C:\Windows	Windows
C:\ProgramData\Microsoft\Windows\StartMenu\Programs	Common Programs
C:\ProgramData	Common AppData
C:\Users<username>\AppData\LocalLow	LocalAppDataLow
C:\Users<username>\AppData\Local	Local AppData
C:\Users<username>\AppData\LocalRoaming	AppData
C:\Users<username>\3D Objects	3D Objects
C:\Users<username>\Contacts	Contacts
C:\Users<username>\Favorites	Favorites
C:\Users<username>\Music	My Music
C:\Users<username>\Videos	My Videos
C:\Users<username>\OneDrive	OneDrive
C:\Users<username>\Saved Games	SavedGames
C:\Users<username>\Searches	Searches
C:\Users<username>\Documents	Personal
C:\Users<username>	Profile
C:\Users\Public\Desktop	Common Desktop
C:\Users\Public\Documents	Common Documents
C:\Users\Public\Music	CommonMusic
C:\Users\Public\Pictures	CommonPictures
C:\Users\Public\Videos	CommonVideo
C:\Users\Public	Public
C:\	AppVPackageRoot

Microsoft Documentation:

• https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes