Jun 30, 2020. Sep 06, 2020.
In this tutorial, we will be listing the steps to access the WindowsApps folder in Windows 10. WindowsApps folder contains files and data related to the apps installed from the Windows Store, cache files and data of progressive Windows Apps, Universal Windows Platform, Electron, etc. Earlier these files were present under Program Files. However, now they have all been moved inside the subfolder labeled WindowsApps.
- Windows apps - introduced in Windows 8, primarily installed from the Store app. Universal Windows Platform (UWP) apps - designed to work across platforms, can be installed on multiple platforms including Windows client, Windows Phone, and Xbox. All UWP apps are also Windows apps, but not all Windows.
- With the advent of Windows 1.0, software vendors came out with new programs to take advantage of the new GUI operating system. This program demonstrates.
To modify or access any system-level files, administrative privilege is required. This is something that most of you might very well be aware of. However, rules are slightly different if you wish to access this folder. Even if you are the admin of your PC, you can’t directly access the WindowsApp folder in Windows 10.
If you are logged in as an administrator, you may try it right away. First off, make sure the Hidden Files option is enabled (click on View in the top menu bar and you’ll see that option). Now, head over C:Program Files and double click the WindowsApp folder. You will get a pop-up: You currently don’t have permission to access this folder. It will prompt you to click on Continue to access this folder. Doing so will throw another pop-up: You have been denied access to this folder.
So, to access this folder, you will have to change the permission and ownership from System to Admin. That is, you are taking over the administrative rights from the System. Now that the background is clear, let us have a look at the steps to access WindowsApp Folder in Windows 10.
Accessing WindowsApps Folder in Windows 10
- Log in as an administrator, head over to C:Program Files, right-click on the WindowsApp folder and select Properties.
- Next, select the Security tab and click on Advanced.
- Under the Permissionentries section, select TrustedInstaller and click on Change next to Owner.
- Type in your account username in the object name box. If you aren’t sure of the username, head over to C:Users and you’ll see a folder named after your account username. That name needs to be entered here. Make sure to enter the correct username. Otherwise, you won’t be able to access the WindowsApp folder on your Windows 10 PC.
- Next, click on Check Names. The object name field should now be updated with your computer’s location. Once done, click OK.
- Now, checkmark the box next to Replace owner on sub containers and objects. Finally, click Apply > OK.
- That’s it. You could now easily access the WindowsApp folder in Windows 10.
Finally, Windows will now change the ownership of each and every file. Moreover, this trick isn’t just limited to this folder. These rules are universally applicable to any folder that is owned by your System and whose rights you wish to transfer to yourself (admin). However, if you are still facing any issues while accessing the said folder, drop in your queries in the comments section below.
- Read next: Useful Windows Taskbar Tips and Tricks
Get App Windows
-->This article provides a deeper dive on what happens to files and registry entries when you create a Windows app package for your desktop application.
A key goal of a modern package is to separate application state from system state as much as possible while maintaining compatibility with other apps. Windows 10 accomplishes this by placing the application inside a MSIX package, and then detecting and redirecting some changes it makes to the file system and registry at runtime.
Packages that you create for your desktop application are desktop-only, full-trust applications and are not virtualized or sandboxed. This allows them to interact with other apps the same way classic desktop applications do.
Installation
App packages are installed under C:Program FilesWindowsAppspackage_name, with the executable titled app_name.exe. Each package folder contains a manifest (named AppxManifest.xml) that contains a special XML namespace for packaged apps. Inside that manifest file is an
<EntryPoint>
element, which references the full-trust app. When that application is launched, it does not run inside an app container, but instead it runs as the user as it normally would.After deployment, package files are marked read-only and heavily locked down by the operating system. Windows prevents apps from launching if these files are tampered with.
File system
The OS supports different levels of file system operations for packaged desktop applications, depending on the folder location.
AppData operations on Windows 10, version 1903 and later
All newly created files and folders in the user's AppData folder (e.g., C:Usersuser_nameAppData) are written to a private per-user, per-app location but merged at runtime to appear in the real AppData location. This allows some degree of state separation for artifacts that are only used by the application itself, and this enables the system to clean up those files when the application is uninstalled. Modifications to existing files under the user's AppData folder is allowed to provide a higher degree of compatibility and interactivity between applications and the OS. This reduces filesystem “rot” because the OS is aware of every file or directory change made by an application. State separation also allows packaged desktop applications to pick up where a non-packaged version of the same application left off. Note that the OS does not support a virtual file system (VFS) folder for the user's AppData folder.
AppData operations on Windows 10, version 1809 and earlier
All writes to the user's AppData folder (e.g., C:Usersuser_nameAppData), including create, delete, and update, are copied on write to a private per-user, per-app location. This creates the illusion that the packaged application is editing the real AppData when it is actually modifying a private copy. By redirecting writes this way, the system can track all file modifications made by the app. This allows the system to clean up those files when the application is uninstalled, thus reducing system 'rot' and providing a better application removal experience for the user.
Other folders
In addition to redirecting AppData, Windows' well-known folders (System32, Program Files (x86), etc) are dynamically merged with corresponding directories in the app package. Each package contains a folder named 'VFS' at its root. Any reads of directories or files in the VFS directory are merged at runtime with their respective native counterparts. For example, an application could contain C:Program FilesWindowsAppspackage_nameVFSSystemX86vc10.dll as part of its app package, but the file would appear to be installed at C:WindowsSystem32vc10.dll. This maintains compatibility with desktop applications that may expect files to live in non-package locations.
Writes to files/folders in the app package are not allowed. Writes to files and folders that are not part of the package are ignored by the OS and are allowed as long as the user has permission.
Common operations
![Windowsapps folder permissions Windowsapps folder permissions](/uploads/1/1/8/9/118922428/101852811.jpg)
This short reference table shows common file system operations and how the OS handles them.
Operation | Result | Example |
---|---|---|
Read or enumerate a well-known Windows file or folder | A dynamic merge of C:Program Filespackage_nameVFSwell_known_folder with the local system counterpart. | Reading C:WindowsSystem32 returns the contents of C:WindowsSystem32 plus the contents of C:Program FilesWindowsAppspackage_nameVFSSystemX86. |
Write under AppData | Windows 10, version 1903 and later: New files and folders created under the following directories are redirected to a per-user, per-package private location:
Windows 10, version 1809 and earlier: Copy-on-written to a per-user, per-app location. | AppData is typically C:Usersuser_nameAppData. |
Write inside the package | Not allowed. The package is read-only. | Writes under C:Program FilesWindowsAppspackage_name are not allowed. |
Writes outside the package | Allowed if the user has permissions. | A write to C:WindowsSystem32foo.dll is allowed if the package does not contain C:Program FilesWindowsAppspackage_nameVFSSystemX86foo.dll and the user has permissions. |
Packaged VFS locations
The following table shows where files shipping as part of your package are overlaid on the system for the app. Your application will perceive these files to be in the listed system locations, when in fact they are in the redirected locations inside C:Program FilesWindowsAppspackage_nameVFS. The FOLDERID locations are from the KNOWNFOLDERID constants.
System Location | Redirected Location (Under [PackageRoot]VFS) | Valid on architectures |
---|---|---|
FOLDERID_SystemX86 | SystemX86 | x86, amd64 |
FOLDERID_System | SystemX64 | amd64 |
FOLDERID_ProgramFilesX86 | ProgramFilesX86 | x86, amd6 |
FOLDERID_ProgramFilesX64 | ProgramFilesX64 | amd64 |
FOLDERID_ProgramFilesCommonX86 | ProgramFilesCommonX86 | x86, amd64 |
FOLDERID_ProgramFilesCommonX64 | ProgramFilesCommonX64 | amd64 |
FOLDERID_Windows | Windows | x86, amd64 |
FOLDERID_ProgramData | Common AppData | x86, amd64 |
FOLDERID_Systemcatroot | AppVSystem32Catroot | x86, amd64 |
FOLDERID_Systemcatroot2 | AppVSystem32Catroot2 | x86, amd64 |
FOLDERID_Systemdriversetc | AppVSystem32DriversEtc | x86, amd64 |
FOLDERID_Systemdriverstore | AppVSystem32Driverstore | x86, amd64 |
FOLDERID_Systemlogfiles | AppVSystem32Logfiles | x86, amd64 |
FOLDERID_Systemspool | AppVSystem32Spool | x86, amd64 |
Registry
App packages contain a registry.dat file, which serves as the logical equivalent of HKLMSoftware in the real registry. At runtime, this virtual registry merges the contents of this hive into the native system hive to provide a singular view of both. For example, if registry.dat contains a single key 'Foo', then a read of HKLMSoftware at runtime will also appear to contain 'Foo' (in addition to all the native system keys).
Only keys under HKLMSoftware are part of the package; keys under HKCU or other parts of the registry are not. Writes to keys or values in the package are not allowed. Writes to keys or values not part of the package are allowed as long as the user has permission.
All writes under HKCU are copy-on-written to a private per-user, per-app location. Traditionally, uninstallers are unable to clean HKEY_CURRENT_USER because the registry data for logged out users is unmounted and unavailable.
All writes are kept during package upgrade and only deleted when the application is removed entirely.
Windowsapps Folder Cleanup
Common operations
This short reference table shows common registry operations and how the OS handles them.
Operation | Result | Example |
---|---|---|
Read or enumerate HKLMSoftware | A dynamic merge of the package hive with the local system counterpart. | If registry.dat contains a single key 'Foo,' at runtime a read of HKLMSoftware will show the contents of both HKLMSoftware plus HKLMSoftwareFoo. |
Writes under HKCU | Copy-on-written to a per-user, per-app private location. | The same as AppData for files. |
Writes inside the package. | Not allowed. The package is read-only. | Writes under HKLMSoftware are not allowed if a corresponding key/value exist in the package hive. |
Writes outside the package | Ignored by the OS. Allowed if the user has permissions. | Writes under HKLMSoftware are allowed as long as a corresponding key/value does not exist in the package hive and the user has the correct access permissions. |
Uninstallation
Windowsapps Folder Permissions
When a package is uninstalled by the user, all files and folders located under C:Program FilesWindowsAppspackage_name are removed, as well as any redirected writes to AppData or the registry that were captured during the packaging process.