Uninstall a Microsoft Store app, wait for the progress bar to finish, then check your storage. The number barely moves. If you're wondering why Windows 11 storage does not change after uninstalling apps, the answer depends on where the app came from: MSIX-packaged apps and traditionally installed desktop software can fail to free up space for two entirely different reasons. For a Store app, that result can be normal even when removal from your account went through without a hitch.
Many apps distributed through the Microsoft Store use a packaging format called MSIX, though the Store also distributes traditional MSI and EXE apps. Microsoft built it specifically to avoid the registry bloat and orphaned files that plagued older Windows software, but that same design draws a hard line between "removing an app" and "deleting its files."
Microsoft's own engineering team has said as much directly: install, in MSIX terms, "is not a formal concept." For an MSIX package, removal can deregister the app from your Windows user profile without necessarily deleting its package payload from the PC. It does not guarantee its files leave your drive.
Much of the time, this is a deliberate tradeoff rather than a failure. Windows keeps shared files in place so it doesn't break something else running on the machine. What follows is why this happens for Microsoft Store apps specifically, how it differs from the leftover-file problem that has always plagued ordinary desktop software, and what you can actually verify before assuming your storage is being held hostage.
Why a Microsoft Store app is still taking up space after uninstall
Windows breaks the MSIX app lifecycle into four distinct steps, and none of them is called "install" or "uninstall." An app is staged when its files land on disk, registered when it becomes visible and usable to a specific user account, deregistered when that user loses access, and destaged when the files are actually deleted.
Think of staging like stocking a supply closet shared by an entire office. Registering someone is like handing that one employee a key. Take the key back and that employee can no longer get in, but the closet itself stays fully stocked.
Microsoft's MSIX removal APIs separate per-user removal from removal of the package payload. RemovePackageAsync, for example, removes the package for the current user. It destages the files, meaning it actually deletes them, only if the system determines nothing else on the machine still needs them.
That's the mechanical root of what's sometimes described as Windows 11 MSIX staged app storage: "removed from view" and "deleted from disk" are two separate steps, triggered independently, and only one of them is guaranteed when you click Uninstall.
The clearest case: another Windows account still uses the app
Staging happens once per machine, not once per user. Registration happens per user, meaning a single package is stored one time on a PC and shared across every account that has access to it.
If a second Windows account on your machine still has that app registered, uninstalling it from your own account only removes your access to it. The package itself stays put on disk, waiting for that other user. The app vanishes from your Start menu and your apps list, with nothing telling you it's still present for someone else logged into the same PC.
This is the most intuitive version of the storage puzzle, and arguably it's the system working exactly as intended on a shared computer. A parent, a sibling, a coworker on a shared office machine, all can keep using an app you've just uninstalled from your own profile. It doesn't, though, explain what happens on a computer where only one person ever logs in.
The less obvious case: shared components on a single-user PC
Even with a single account, apps frequently depend on shared components: MSIX framework packages such as VCLibs and the Windows App SDK. These components can be packaged separately and shared by multiple apps.
If App A gets removed but App B still relies on one of those shared framework packages, Windows keeps that framework staged, even on a machine with exactly one user account.
That's a different scenario from App A's own files surviving. App A's payload can be fully destaged while a separate, shared runtime it once depended on remains behind, which is often why the storage you recover is smaller than expected rather than zero.
Microsoft's provisioning system adds a wrinkle here: it tracks entire package families rather than individual versions. A newer version of a shared component doesn't need to be reprovisioned from scratch; it's simply staged, and Windows registers whichever version in that family happens to be highest the next time you sign in.
That's a narrower point than it might sound: it doesn't mean Windows checks a full dependency chain across every installed app before deleting any single one's files, only that shared components are versioned in a way built around families rather than one-off packages.
That's a second, entirely separate reason storage stays put, and it shows the multi-user explanation isn't the whole story. A single-user laptop can show exactly the same symptom for exactly the opposite reason.
A different problem: how traditional desktop apps leave storage behind
Everything covered so far applies to MSIX packages from the Microsoft Store. Traditional Win32 desktop software has its own, unrelated storage problem, worth separating out so you don't misdiagnose which one you're dealing with.
For conventional desktop programs, Windows typically hands the removal job to the app's own registered uninstaller rather than hunting down every trace itself. That uninstaller often deletes the core program files but leaves cached data, logs, settings, and registry entries behind, which is why reinstalling a program can bring back old preferences or old bugs, as if nothing was ever removed.
Shared components tracked by registry reference counts are one reason generic cleanup tools can't safely judge what's still needed. It's a rough parallel to MSIX's dependency logic, but running on far older, far less consistent plumbing.
Two genuinely different mechanisms produce the same visible symptom: your storage number doesn't move the way you expected. MSIX retention is a deliberate design choice built around shared packages. Desktop-software leftovers are incomplete cleanup by whatever installer the vendor happened to ship.
Before you try to reclaim the space
A practical checklist before assuming the worst:
Confirm whether the app came from the Microsoft Store (MSIX) or a traditional installer, since the cause and the fix are different in each case.
Check whether other local accounts exist on the machine that might still have the app registered.
Recognize that shared runtime packages like .NET, Visual C++, and the Windows App SDK are a normal, machine-wide fixture, not leftover baggage tied to one specific app you uninstalled.
Microsoft documents PowerShell methods for checking whether an MSIX/AppX package still exists for other users, including Get-AppxPackage -AllUsers, although using package-management commands to remove packages system-wide requires more care than a normal Settings uninstall.
What to do next
MSIX retention and desktop-software leftovers look identical on a storage meter but call for opposite instincts. One is Windows protecting something another account or app still needs; the other is a vendor's uninstaller simply not finishing the job.
The decision rule is short: figure out whether the app in question was Store-distributed or traditionally installed before doing anything else, and don't delete package folders that Windows has flagged as protected just because an app disappeared from your Start menu. That single distinction is worth more than any cleanup utility, and it's the one thing worth checking before storage anxiety talks you into something a reinstall can't undo.
Comments
Be the first, drop a comment!