Where Are Microsoft Store Apps Installed: Default Locations and How to Find Them

Windows keeps these apps tucked away in Program Files\WindowsApps to maintain system stability and security—this folder is locked down to prevent accidental damage. 🔒 The %LocalAppData%\Packages directory holds user-specific data like settings and cached files, which is why you sometimes see apps reset after updates.

I’ve found that enabling "Hidden items" in File Explorer (View tab) makes these folders visible, though you’ll still need admin rights to modify files directly.

If you’re troubleshooting, tools like Everything Search (from voidtools.com) can quickly locate app files without digging through folders. Just remember: tampering with these files can break apps, so back up critical data first.

For deeper access, PowerShell commands like Get-AppxPackage reveal installed apps and their paths—perfect for manual cleanup or reinstallation.

How Windows handles Microsoft Store app installation paths

Windows uses a clever system to isolate Microsoft Store apps through virtualization and sandboxing, fundamentally different from traditional Win32 applications. The Program Files\WindowsApps folder acts as a secure container where apps run in a restricted environment, preventing them from modifying system files or accessing other apps' data.

This isolation is critical because Store apps often use the Universal Windows Platform (UWP), which enforces strict security policies—like running with limited permissions and requiring explicit declarations for system resources.

The read-only nature of Program Files\WindowsApps comes from how Windows packages these apps: they're essentially self-contained ZIP archives with all dependencies embedded.

Each app gets its own subfolder with a GUID-based name (like Microsoft.WindowsCalculator_8wekyb3d8bbwe), making them easy to identify but hard to accidentally modify. 💻 This design mirrors how mobile operating systems handle apps, ensuring stability even when multiple apps run simultaneously.

For comparison, traditional Win32 apps install to Program Files with full system access, while UWP apps operate in a "least privilege" model by default.

User-specific data lives in %LocalAppData%\Packages, where Windows stores app configurations, cached files, and temporary data. This separation is intentional: if an app crashes or updates, only its local data resets while the core installation remains intact.

The system uses Windows Registry entries to map these paths dynamically, meaning you won’t see the same folder structure across different Windows versions. For example, Windows 11 might use slightly different path formats than Windows 10, though the core concept remains identical.

Here's what happens under the hood when you install a Store app:

• Package Deployment: The app downloads as an .appx or .msix bundle, which Windows verifies for digital signatures before extraction.
• Virtualization Layer: The app runs through a lightweight Windows Sandbox (not the standalone tool), where system calls are intercepted and redirected to safe paths.
• Permission Model: Apps request capabilities (like camera access) at install time, and Windows grants them only if explicitly declared in the app's manifest.

The trade-off? Some developers complain about UWP's restrictions, like limited access to hardware or file system. But Microsoft's reasoning is clear: security and consistency outweigh flexibility.

For power users, this means Store apps are less prone to conflicts, but it also limits certain advanced use cases (like deep system integration). 🔒 The Program Files\WindowsApps folder’s hidden status reinforces this—Microsoft wants users to interact with apps through the Store, not by poking around in file explorers.

What most people don’t realize is how this design protects against malware. Since Store apps can’t write to arbitrary locations, even if one gets compromised, the damage stays contained. Traditional apps, by contrast, can modify system files or other programs—giving malware far more leverage.

This is why Windows enforces these paths so strictly, even if it feels restrictive at times.

Finding and accessing Microsoft Store app files manually

Start by enabling hidden files in File Explorer - click the View tab, check Hidden items, and uncheck Protected operating system files.

This reveals the Program Files\WindowsApps folder where all Microsoft Store apps reside. 🔍 For faster navigation, use the Win + R shortcut, type the full path (e.g., C:\Program Files\WindowsApps), and press Enter. Remember, these folders are read-only by default, so you'll need admin rights to modify files.

If you're having trouble locating specific apps, try using Everything Search (free from voidtools.com) - it indexes hidden files instantly. Just type part of the app name (like "Calculator") and it'll show the exact folder path.

For permission issues, right-click the folder, select Properties, then Security tab to adjust access levels. 💻 Pro tip: Create a shortcut to the folder by right-clicking it, selecting Send to, then Desktop (create shortcut) for quick access.

To safely uninstall apps manually, open PowerShell as Administrator and run Get-AppxPackage AppName (replace AppName with the app's partial name). This lists all installed versions. Use Remove-AppxPackage PackageFullName to uninstall, where PackageFullName includes the full GUID (e.g., Microsoft.WindowsCalculator_8wekyb3d8bbwe). Always back up app data from %LocalAppData%\Packages before making changes.

For troubleshooting, check the AppData folder for corrupted files. Navigate to %LocalAppData%\Packages and look for folders matching the app's GUID.

Delete the AC folder (app cache) if the app crashes - Windows will rebuild it on next launch. 🚀 If an app won't open after updates, try resetting it via Settings > Apps > Installed apps, then Advanced options > Reset.

This preserves your data while reinstalling the app.

When working with these folders, keep one critical rule in mind: never delete the main app files directly from Program Files\WindowsApps - always use the Store or PowerShell commands. This prevents Windows from detecting broken installations, which can trigger system errors.

For developers, you can temporarily make folders writable by taking ownership via Properties > Security > Advanced, but revert changes immediately after modifications.