Fix ms action center You will need a new app to open this ms-actioncenter link

If clicking the notification bell, date/time, or the network/volume icons suddenly brings up the prompt “You’ll need a new app to open this ms-actioncenter link”, Windows is trying to hand off to a built‑in shell protocol that no longer resolves to a handler — and the fix is usually a repair of the shell/AppX registrations, removal of a policy or a bad update, or repair of the Windows component store.

Background / Overview​

The ms-actioncenter: protocol is the shell-level handler Windows uses to open the Notification Center and Quick Settings (in Windows 11) or the combined Action Center (in Windows 10). When the handler is functional, clicking the taskbar icons opens the appropriate flyouts. When it fails, Windows displays the “You’ll need a new app…” dialog because no app is registered for that URI scheme.
Community troubleshooting and vendor writeups consistently point to three broad root causes:

• corrupted AppX / SystemApps registrations (often after manual debloating or package removal),
• Group Policy / MDM policies that disable the Action Center/Notification Center, and
• system component store or update regressions that break shell components.

Below I walk through verified, risk‑aware ways to restore the handler and related shell flyouts, and then analyze why the problem happens and how to prevent recurrence.

---

Quick symptom checklist (what you’ll see)​

• Clicking the notification bell or date/time does nothing or shows “You’ll need a new app to open this ms-actioncenter link.”
• Clicking network/volume/battery area (system tray corner) produces the same prompt.
• Shortcuts like WIN+A or WIN+N fail to open the Quick Settings / Notification Center.
• Taskbar flyouts that depend on SystemApps appear blank or do not dismiss properly.
  These symptoms match multiple community reports and troubleshooting threads where the AppX re‑registration or DISM/SFC repairs resolved the issue.

---

How to approach the repair (strategy and safety)​

Start with the lowest‑risk, fastest checks and progress toward the more invasive repairs only if earlier steps fail. That order minimizes downtime and avoids unintended side effects.
Recommended order:

• Quick checks (restart Explorer, sign out/in, test another user).
• Re-register system AppX packages (PowerShell).
• Check and remove any policy disabling the Notification/Action Center.
• If issue started after an update, roll back the latest quality update.
• Repair system files with DISM and SFC.
• If still broken, check WindowsApps permissions, re-register only SystemApps, or perform an in‑place repair install.

Each step below includes exact commands, expected behavior, and risk warnings.

---

1) Quick checks (fast, safe)​

• Restart Windows Explorer: open Task Manager (Ctrl+Shift+Esc) → Processes → Windows Explorer → Restart. This often clears UI-only hangs and should be done before anything else.
• Sign out and sign in, or reboot. Simple reboots fix state issues 30–40% of the time for UI handler problems.
• Test with another local user: create a new local account and log in. If the new account’s Notification Center/Quick Settings work, the problem is likely a per‑user registration or policy; if it fails for all users, it’s system‑wide.

These quick checks are safe and fast; many troubleshooting threads list them as the first steps before deeper fixes.

---

2) Repair Notification Center by re‑registering AppX packages (PowerShell)​

Why this works: the Taskbar flyouts rely on built‑in AppX/SystemApps packages and their registered manifests. If those registrations are corrupted (often after debloat scripts, broken removals, or partial updates), the ms-actioncenter: URI no longer maps to the correct system component. Re‑registering AppX packages restores the registered manifests for built‑in apps.
Run as Administrator:

• Search for PowerShell, right‑click and choose Run as administrator.
• Paste this single command and press Enter:

Get-AppxPackage -AllUsers | ForEach-Object { Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml" }

• Wait for the command to finish (it can take several minutes). You may see red error lines for packages that can’t be registered for all users; that is normal in many mixed‑user environments.
• Reboot and test.

Community posts and long‑standing troubleshooting guides repeatedly use this exact command to restore Start, Search, Action Center, and other system AppX behaviors. Expect it to fix many ms-actioncenter failures.
Risk and caveats:

• This re‑registers built‑in apps for all users. On corporate machines with specific provisioning or custom AppX packages, re‑registration may not be appropriate without admin approval.
• It can produce non‑fatal red errors; those are usually safe to ignore unless they persistently block functions.
• If the system has had deliberate AppX removals by debloat tools, re‑registration may not recreate removed content.

---

3) Remove Notification/Action Center policies (Registry / Group Policy)​

Why: some debloat scripts or MDM/Group Policy settings deliberately disable the Action Center or Notification Center using policy keys. When set, Windows can block the ms-actioncenter handler even when the AppX packages are intact.
Important safety note: editing the registry incorrectly can cause system instability. Only change the keys below and avoid deleting values unless you are sure they came from a tweak or debloat tool.
Steps (per‑user and machine‑wide locations):

• Press Win+R → type regedit → Enter.
• Check these paths:
• HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Explorer
• HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Explorer
• Look for DWORD values named DisableNotificationCenter or DisableActionCenter. If present and set to 1, change them to 0. If missing, you do not need to create them unless you know a previous tweak did so. Creating a key and setting it to 0 is safer than deleting an unknown policy created by enterprise management.

If your PC is managed by IT (work/school), these values may reapply at next policy refresh; coordinate with IT before changing machine‑wide policy.
Why this matters: registry keys and policies show up in community support threads as common causes when users have used debloat scripts or group policy changes. When present, removing or resetting them restores the shell’s ability to open the flyouts.

---

4) Uninstall the latest quality update (if the problem began right after updating)​

When to use: only if the ms-actioncenter error began immediately after a recent cumulative/quality update. Some updates have caused regressions in explorer/shell components; rolling back the most recent quality update can restore behavior without a full reinstall.
How to uninstall:

• Settings → Windows Update → Update history → Uninstall updates → choose the most recent Quality/Cumulative Update (KBxxxxxxx) and uninstall, then reboot.
• If Settings won’t open, use Advanced Startup: Start → Power → hold Shift and click Restart → Troubleshoot → Advanced options → Uninstall Updates → Uninstall latest quality update.

Caveats:

• Windows will often reinstall the update; if the rollback fixes the issue, immediately pause updates until Microsoft releases a fixed update or you accept the risk.
• Rolling back security updates reduces protection; balance the operational need with security. Several release notes and insider flight notes reference fixes and regressions that affected taskbar flyouts, indicating that updates can be implicated in Quick Settings/Notification Center behavior.

---

5) Repair system files: DISM and SFC​

Why: if package registrations fail to repair or the component store is corrupt, the Windows servicing stack may be unable to install or register system packages properly. Use DISM to repair the component store, then run SFC to repair protected files.
Run from an elevated Command Prompt:

• Open elevated Command Prompt (run as administrator).
• Run:

DISM /Online /Cleanup-Image /RestoreHealth
Wait — this can take 10–30 minutes. If DISM reports it used Windows Update to obtain files, that’s normal.

• Then run:

sfc /scannow
SFC will scan and repair system files. Reboot afterward.
These commands are the standard repair sequence recommended in many troubleshooting threads for Start/Action Center/Settings problems; multiple community answers and troubleshooting guides recommend DISM followed by SFC for component store or system file corruption.
If DISM fails with errors about source files, you can provide an alternate source (Windows image or ISO) — only attempt that if you’re comfortable with component repair.

---

6) Check WindowsApps permissions and re-register SystemApps only​

If the AppX bulk re‑registration is noisy or you want a narrower repair, focus on SystemApps (where Notification Center and Quick Settings live) and verify permissions for C:\Program Files\WindowsApps.

• Check permissions: from elevated CMD run:

icacls "C:\Program Files\WindowsApps"
Community troubleshooting shows permissions issues in WindowsApps can prevent Store/SystemApps from launching; repairing ACLs is an advanced fix and should be done carefully.

• Re-register only SystemApps (safer/smaller scope):

Open PowerShell as admin and run:
Get-AppXPackage -AllUsers | Where-Object {$.InstallLocation -like "SystemApps"} | ForEach-Object { Add-AppxPackage -DisableDevelopmentMode -Register "$($.InstallLocation)\AppXManifest.xml" }
This narrows repairs to system packages and has resolved Start and flyout problems for many users. Community threads include this focused command as an effective intermediate step.
Risk: if system packages have been deliberately removed by OEM/debloat tools, re‑registering may not recreate the missing files.

---

7) Last resorts: in‑place repair (repair install) or reset​

If none of the above works, consider an in‑place repair (repair install) which reinstalls Windows while keeping files and apps. This fully refreshes system files, components and apps, and will repair the ms-actioncenter handler.

• Back up personal data.
• Perform an in‑place repair using the official Windows installation media (choose Upgrade / Keep personal files and apps). This is time‑consuming but solves deep servicing and component store corruption reliably when DISM/SFC fails.

If the machine is managed by an organization, coordinate with IT — corporate provisioning or custom images may require special handling.

---

Reproducible checklist (step‑by‑step)​

• Restart Explorer and reboot.
• Test another user account.
• Run PowerShell as admin and execute: Get-AppxPackage -AllUsers | ForEach-Object { Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml" } — reboot and test.
• Check registry policies at HKCU/HKLM\Software\Policies\Microsoft\Windows\Explorer for DisableNotificationCenter/DisableActionCenter and set values to 0 if present (exercise caution on managed PCs).
• If issue began after a Windows quality update, uninstall the latest quality/cumulative update and reboot. Pause updates afterward if the rollback fixed it.
• Repair the component store: DISM /Online /Cleanup-Image /RestoreHealth and then sfc /scannow — reboot and test.
• If needed, re-register just SystemApps or check WindowsApps permissions (icacls) before performing an in‑place repair.

---

Critical analysis — strengths, limitations, and risks​

Strengths of the approach:

• Non‑destructive first: the recommended sequence begins with low‑risk operations (Explorer restart, re‑registration and registry checks) that are often sufficient. Community evidence shows these fixes restore Notification Center/Quick Settings frequently.
• Re‑registering AppX is targeted: the PowerShell re‑register command specifically re‑applies app manifests and often fixes multiple UI problems in one go.
• DISM/SFC targets root cause: if registrations fail because of component store corruption, DISM + SFC repairs the underlying files rather than masking symptoms.

Limitations and risks:

• Re‑registration can be noisy: running Add‑AppxPackage for all users may produce red errors and may not succeed for packages intentionally removed; it can be slow and must be run as admin. Some community threads show users misinterpreting red lines as failures when they were harmless.
• Registry edits on managed devices: changing policy keys on corporate machines may conflict with IT policies and could be reverted. If the device is managed, changes may be temporary or trigger compliance alerts.
• Rollback of security updates reduces protection: uninstalling a cumulative update should be a temporary diagnostic step and not a permanent solution without further security assessment.
• Debloat tools create persistent changes: many debloat scripts remove or disable system apps and registry keys; simply re‑registering may not recover files that were deleted. In those cases, an in‑place repair or reinstall will be required. Multiple forum threads show users who had to perform deeper repairs after heavy debloating.

When to escalate:

• If Action Center is disabled via corporate policy, contact your admin rather than forcing changes.
• If DISM reports component store corruption it cannot fix with online sources, or if SFC fails repeatedly, plan for an in‑place repair or reinstall. Community troubleshooting commonly escalates to repair install in persistent cases.

---

Prevention and best practices​

• Avoid destructive “debloat” scripts unless you understand exactly what they remove. Many such scripts omit SystemApps or registry keys required by shell handlers. If you do use them, create a full system backup or a restore point first. Community reports show debloat tools are a common antecedent to Start/Action Center problems.
• Keep Windows updates installed, but test large quality updates on non‑critical machines first in managed environments. If a problematic update deploys widely, pause updates until Microsoft issues a fix or guidance. Insider and release notes often document fixes and regressions affecting taskbar flyouts.
• If you manage fleet devices, avoid policies that disable core UI components unless explicitly required. Document any registry or provisioning changes so they can be reversed.
• Maintain occasional full system backups or system images so you can recover quickly from failed updates or accidental removals.

---

Quick reference: commands and locations (copyable)​

• Re‑register all AppX packages (PowerShell as admin):
  Get-AppxPackage -AllUsers | ForEach-Object { Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml" }
• Re‑register SystemApps only (PowerShell as admin):
  Get-AppXPackage -AllUsers | Where-Object {$.InstallLocation -like "SystemApps"} | ForEach-Object { Add-AppxPackage -DisableDevelopmentMode -Register "$($.InstallLocation)\AppXManifest.xml" }
• DISM and SFC (elevated CMD):
  DISM /Online /Cleanup-Image /RestoreHealth
  sfc /scannow
  These are the canonical repair commands recommended for servicing/component store corruption.
• Check WindowsApps permissions (elevated CMD):
  icacls "C:\Program Files\WindowsApps"
  Permissions problems here have caused Store/SystemApps issues in troubleshooting threads.
• Registry paths to check:
  HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Explorer
  HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Explorer
  Look for DisableNotificationCenter and DisableActionCenter and set to 0 if present and you control the device.

---

Common pitfalls and how to avoid them​

• Misreading PowerShell red errors: many packages are per‑user or absent and will show errors when re‑registered for all users. Focus on whether the Notification Center starts working after reboot rather than on every red line.
• Blindly deleting policy keys on managed PCs: if your device is managed, policy keys will likely reapply — coordinate with IT to avoid compliance issues.
• Ignoring the possibility of update regressions: if the issue coincides with an update, rollback is an important diagnostic step. Several Windows flight notes and community reports show updates can temporarily break taskbar flyouts and related UI. If a rollback fixes the issue, pause updates until a vendor fix is available.

---

Real-world outcomes: what to expect​

• Most users who run the AppX re‑register command and then reboot will see their Notification Center / Quick Settings restored. Community threads and long‑running forum solutions confirm this behavior repeatedly.
• If the problem is policy‑based or caused by deliberate removal of SystemApps, re‑registration may not fully restore behavior — you may need to undo the policy, restore removed files, or perform an in‑place repair. Forum guidance consistently escalates to component repairs when re‑register and DISM/SFC don’t resolve the issue.

---

Conclusion​

The ms-actioncenter URI error is a symptom: Windows cannot locate the shell handler that opens Notification Center / Quick Settings. The pragmatic, low‑risk path to repair is sequential — restart explorer, re‑register AppX packages, check for disabling policies, roll back a problematic quality update if present, and run DISM + SFC if package registration fails. These steps are proven across community troubleshooting and Microsoft servicing guidance to recover the handler in the majority of cases.
If you’re on a managed device, coordinate with your administrator before changing policies or re‑registering system packages. If the fixes above don’t restore the flyouts, prepare a backup and plan for an in‑place repair — that will refresh the system components and reliably restore the ms-actioncenter handler.

---

Source: Appuals Fix: You'll need a new app to open this ms actioncenter link