Universal Windows Platform (UWP) is the current name for a new type of application platform originally introduced with Windows 8 as “Metro” and later renamed to “Modern”. UWP apps can run on desktop, phone and console versions of Windows. They may only use a subset of the Windows API and run in a sandboxed environment. As a consequence, UWP apps can only use very limited areas of the file system. This article describes where UWP app settings are stored and how part of those settings roam between devices.
Sandboxing & Isolation
The consequence of UWP applications being sandboxed is that they cannot write just anywhere on the hard drive. Instead, the physical storage location is managed by the operating system. Whenever UWP apps want to read or write application data they need to do so via dedicated Windows API functions.
Settings & Folders
Windows provides two types of data stores for each UWP app: Settings is a key/value store similar to INI files or the registry. In fact, it is based on registry technology, as will be explained below. Settings is suitable for individual configuration items that are small in size, i.e. numbers, strings, dates, etc.
In addition to Settings UWP apps can make use of Folders, a store for files of (mostly) any type.
Roaming, Local & Temporary
UWP apps cannot simply store settings or app data, they must choose a so-called locality first. The locality determines how the stored data is treated by the OS. The following three localities are available:
- Cloud-based roaming to every device where the app is installed
- Maximum data size allowed to roam is limited per app
- Not roamed to other machines
- Preserved between app sessions
- Not roamed to other machines
- May be deleted at any time
Roaming App Data
The maximum data size allowed to roam per app is limited to 100 KB.
If the current size of the roaming data in the roaming app data store exceeds the maximum size specified by the RoamingStorageQuota setting, the system suspends data replication for all apps in the package to the cloud until the current size no longer exceeds the maximum size.
Data Retention in the Cloud
If an app is uninstalled from all devices belonging to a user, roaming data for that app will be preserved in the cloud for a “reasonable amount of time”. According to Microsoft that amounts to “a few weeks”.
Roaming data for an app is available in the cloud as long as it is accessed by the user from some device within the required time interval. If the user does not run an app for longer than this time interval, its roaming data is removed from the cloud.
Settings synchronization is triggered by the OS, not the app. I could not find any information as to how often that happens.
However, there is a special HighPriority setting that is synced more quickly than other roaming data. It must be under 8 KB in size in order to retain the HighPriority benefits. Exceeding 8 KB will not cause errors, but it will be roamed as if it were a normal setting.
The algorithm used to resolve sync conflicts is “last writer wins”. This applies to multiple instances of the app making changes to the same setting. The cloud version of said setting will always reflect the last change made by any app instance.
However, as per Microsoft roaming app data is not intended for simultaneous use on more than one device at a time. When an app is used on multiple devices concurrently, the changes from each app instance are synced to the cloud automatically. However, merging changes from the cloud with the local state is the app’s responsibility.
All app data is stored per app version. App data only roams between installed apps with the same version number. When the app is updated, older app data can be automatically migrated. The responsibility for that lies with the app developer, though, who must supply the migration logic.
Excessive Usage Protection
The system has various protection mechanisms in place to avoid inappropriate use of resources. If app data does not transition as expected, it is likely that the device has been temporarily restricted. Waiting for some time will usually resolve this situation automatically and no action is required.
Any files and directories placed in the roaming Folders store is synced, subject to the following exclusions rules:
- No archives (ZIP, etc.)
- No files that have names with leading spaces
- No file paths that are longer than 256 characters
- No empty folders
- No files with open handles
- Files that have names with these Unicode characters: e794, e795, e796, e7c7, e816, e817, e818, e81e, e826, e82b, e82c, e831, e832, e83b, e843, e854, e855, e864, e7e2, e7e3, and e7f3
Local App Data
The size of local app data is only limited by available disk space.
Temporary App Data
Temporary data may be removed at any time by either the System Maintenance task (automated) or Disk Cleanup (user-initiated).
Storage Locations on Disk
An app’s settings storage root is located at %LocalAppData%\Packages\PACKAGEID, i.e. C:\Users\Helge\AppData\Local\Packages\Microsoft.SkypeApp_kzf8qxf38zg5c. The name of PACKAGEID is concatenated from the application package name and a signing certificate based postfix.
UWP app state is stored in the local part of the user profile exclusively. None of it roams with a traditional roaming profile.
The roaming folder is located in the subfolder RoamingState of the app’s root settings directory, i.e. %LocalAppData%\Packages\PACKAGEID\RoamingState.
The local folder is located in the subfolder LocalState of the app’s root settings directory, i.e. %LocalAppData%\Packages\PACKAGEID\LocalState.
The temporary folder is located in the subfolder TempState of the app’s root settings directory, i.e. %LocalAppData%\Packages\PACKAGEID\TempState.
Roaming and local settings are both stored in the file settings.dat within the subfolder Settings of the app’s root settings directory, i.e. %LocalAppData%\Packages\PACKAGEID\Settings.
Settings.dat is a registry hive with some unusual properties:
- It has two root-level keys: LocalState and RoamingState
- Values are stored as binary data
- Value data is postfixed with an 8-byte timestamp that changes on every update
- Value types used are not REG_SZ, etc., but undocumented, e.g. 0x5F5E104 (integer?), 0x5F5E10B (bool?), 0x5F5E10C (string?)
Settings.dat can be viewed and/or modified by the following sequence of commands:
- Reg load
- Reg export
- Modify the exported .reg file
- Import the .reg file
- Reg unload