Windows command guide
Re-register Windows Store Apps with PowerShell
Built-in Windows apps depend on app package registration data. When that data becomes inconsistent, apps can stop opening, disappear from expected locations, or report package-related errors. Re-registering those apps tells Windows to rebuild that link using each app manifest.
This guide is written around the specific symptom-command match for repair windows store apps, not as a generic dump of terminal lines. That makes the page more useful for real troubleshooting and reduces the chance of running the wrong repair step.
Get-AppxPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
Best place to run it
Elevated PowerShell is the right execution context for this page. Because this repair touches protected Windows state, a normal unelevated shell can return misleading access errors or partial results.
Fast repair workflow
- Start from the exact symptom on this page: Built-in apps fail to launch or close immediately
- Run the service or app repair line exactly as shown: Get-AppxPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}.
- This workflow is tuned for this repair, so avoid mixing it with unrelated repair commands too early.
- Re-open the affected app, service, or feature and check whether the same component still fails.
- If the issue persists, check service state, dependencies, package integrity, or event logs before doing a broader repair.
Copyable wrapper script
Use this wrapper when you want the page command inside a clearer script block with start and finish prompts.
$ErrorActionPreference = "Continue"
Write-Host "Run this PowerShell block in an elevated window before trusting the result."
Write-Host "Starting targeted Windows repair step..."
Get-AppxPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
Write-Host "`nReview the output above before moving to the next fix."
Verification commands after the repair
These follow-up commands help you check whether the repair actually changed the Windows state that matters, instead of assuming success from a single line.
wsreset
Get-AppxPackage Microsoft.WindowsStore
What problem this command is trying to solve
This command targets broken registration of built-in AppX packages across user profiles. It is often relevant when Microsoft Store apps or native Windows apps stop working correctly.
- Built-in apps fail to launch or close immediately.
- Apps seem missing even though Windows components are still installed.
- Package-related errors appear after updates or profile issues.
How the command works
PowerShell enumerates installed AppX packages and re-registers them by pointing Windows back to each package manifest file. That can restore missing associations and app registrations.
When it makes sense to run it
Use it when Store apps, Settings-related components, or bundled apps look broken after updates, account changes, or corrupted registration data.
Before you run this command
- Open an elevated Command Prompt or PowerShell window before running Get-AppxPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}.
- Confirm that the symptom really matches this guide, especially if you are seeing signs such as: built-in apps fail to launch or close immediately.
- Identify the exact Windows component that is failing before you use Get-AppxPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}, so you do not reset unrelated parts of the system.
What result to expect
After running Get-AppxPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}, compare the result against the symptom that brought you here. The most useful checkpoint is whether built-in apps fail to launch or close immediately becomes less frequent, changes form, or produces a clearer error message. A command page is stronger when it helps you verify a real change instead of just assuming the line must have worked.
How to verify that it worked
The best verification step after Get-AppxPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"} is to repeat the action that previously triggered the problem. If apps seem missing even though windows components are still installed still appears in exactly the same way, the command probably was not the whole answer and you should move to the next targeted check instead of assuming the page is finished.
Why administrator rights matter here
This command changes a Windows service, package, or built-in app component. Run it in an elevated shell so Windows can apply the repair instead of only returning an access or privilege error.
Before you run it
Run PowerShell as administrator. The command may output several messages while it processes packages. Some warnings can appear even when the overall repair succeeds.
When this is probably the wrong fix
This is not the right first fix for every generic crash. Use it when the failing part is a Windows service, built-in app package, indexing component, print queue, audio stack, or similar subsystem.
What to do if it does not help
If Get-AppxPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"} does not improve built-in apps fail to launch or close immediately, move to the next repair step that matches the same symptom family instead of piling on random commands. The best follow-up depends on whether the failure is mainly about a Windows service, package, or built-in app component.
Frequently asked questions
Should I use Get-AppxPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"} for this exact Windows symptom?
Use it when the behavior on your PC lines up with the repair target on this page: This command targets broken registration of built-in AppX packages across user profiles. It is often relevant when Microsoft Store apps or native Windows apps stop working correctly.
What should I check right after Get-AppxPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}?
Check whether the original trigger still reproduces the same failure. For this page, a useful checkpoint is whether built-in apps fail to launch or close immediately becomes less frequent, changes form, or points you toward a more specific next step.
When should I not rely on Get-AppxPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"} alone?
This is not the right first fix for every generic crash. Use it when the failing part is a Windows service, built-in app package, indexing component, print queue, audio stack, or similar subsystem.