I have run into, and have been investigating a feature of the modern Windows Operating System that holds some of the magic used to integrate modern applications when they are installed. This feature I call StateRepository.
When traditional applications, those built using Win32 or .Net Framework API sets, are installed into the OS, they integrate by either placing files in specific directories or they write into specific parts of the Windows Registry. For example, to add a shortcut to the start menu the application installer writes a .lnk file into one of the start menu folders and the shell discovers it there and adds it into the start menu display. If the app needed to register a COM component, a bunch of registry entries would be written beneath one of the CLASSES keys and the COM Manager would find them when a COM call is made.
“Modern applications”, for example UWP, MSIX, and “Packaged Apps”, instead define the integrations needed in an internal file called AppXManifest.xml which is part of the package. When such an application is installed, this information is used by the AppInstaller to perform the integrations. But the Desktop AppInstaller does not simply do what the traditional installer would have done. To achieve clean installations and uninstalls, and also provide for isolations when needed, the AppInstaller performs the integrations differently and the OS has been adjusted to look for integrations in new places.
Previously, I had noted some of those locations. For example, some COM registrations now appear in the registry under Classes\PackagedCom\Package\<FullPackageName>. But until now I have never tried to find where all those integrations went. I assumed that perhaps the package AppXManifest might be consulted directly in some cases, even though I never saw that happen.
It was while running a ProcessMonitor trace that I discovered where some of that integration information is kept. It is kept in a couple of files we can refer to as the StateRepository. Perhaps this will provide a wealth of knowledge that will allow us to troubleshoot (and maybe someday fix) application deployment issues.
The StateRepository is stored in a protected area of the Operating System under the folder C:\ProgramData\Microsoft\Windows\AppRepository. We can witness the AppRepository being written to during modern application installation by one or more svchost processes. This includes a cached copy of the package’s AppXManifest file, a per-package/per-user .pckgdep file (a likely subject of further investigations), and a pair of files with names that start with StateRepository and have file type extensions of .srd.
By looking at the stack of ProcessMonitor events when these files were accessed, I determined that these srd files are actually SqlLite databases. I was able to make an offline copy of these files, and open them up for a look.
The two files are named StateRepository-Machine.srd and StateRepository-Deployment.srd that are of interest.
An open source tool from GitHub (sqlitebrowser/dbBrowser: Website at: (github.com)) with a home page DB Browser for SQLite (sqlitebrowser.org) can be used to read these copied files.
The Deployment database seems more interesting when looking at potential updating issues, and the Machine database contains tables more associated with the integrations, especially application and package extensions. Some of the table names from the Machine database are shown on the right.
The entries appear designed for fast lookup, and generally not requiring table join operations. However quite often the columns use terse ID fields (often just an integer). It appears that many of these IDs are the same as entries seen in new Registry locations, such as HKLM:\\Software\Microsoft\Windows\CurrentVersion\AppModel\StateRepository or HKCR:\\Software\Microsoft\Windows\CurrentVersion\AppModel\PackageRepository.
While I have no great examples yet of where viewing this information might be helpful, I am finding it helpful to view the table structure to understand if entries I add for a new (and questionably documented) schema extension is being implemented when I install the package.
I do not envisage that we should consider altering the information in these databases, nor in the registry locations I mentioned. But you never know.
I am posting this so that others, who might be so inclined, can peek a look and determine if there is something useful to them here.
One possibility that I am thinking about is to extend the AppModel api interface used by the PSF to determine information about the package that launched the containerized application. I have a long-standing request for Microsoft to add to that api to provide information about whether the app in running in a shared package container (and what other packages are in there), information not available programmatically today (other than through PowerShell, which would be too slow, holding up app launches for an extra second or more). Without a fast way to determine this at PsfLauncher startup, using SharedPackageContainer with the PSF isn’t going to work.
