![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(96, 36%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMD%3C/text%3E%3C/svg%3E)
WORKAROUND / UPDATE
I eventually found a workaround that fixed the Store pause function for me:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\InstallService
→ Permissions → Users → enable “Full Control”
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\InstallService\State
→ Permissions → Users → enable “Full Control”
After changing those permissions in Regedit while signed in with my normal user account, I could immediately pause Microsoft Store updates without any error. I did not even have to select a pause duration first.
There is another important detail that may help explain what is happening. If I enable and sign in to the built-in Windows Administrator account, without linking it to my Microsoft account, pausing Store updates works normally without changing these registry permissions.
My normal Microsoft-linked account and the built-in Administrator account both have administrative privileges, but they do not run applications with exactly the same effective security token under UAC. A normal administrator account normally runs applications such as Microsoft Store with a filtered, non-elevated token until elevation is explicitly required, while the built-in Administrator account can behave differently depending on Admin Approval Mode.
That may explain why the Store operation succeeds under the built-in Administrator account but receives Access denied under my normal administrator account.
However, that does NOT explain the actual regression.
The same personal Microsoft-account setup worked normally for years, and this problem only started appearing recently. It also returns after clean Windows installations. Therefore, UAC behavior by itself cannot explain why Store / InstallService suddenly no longer has the effective permissions it previously had.
This makes me suspect a regression somewhere in the interaction between Microsoft Store, InstallService, UAC/effective permissions, or the default permissions applied to the InstallService registry keys. I cannot confirm which component is responsible.
In my case:
- My normal Microsoft-linked account is correctly a member of
Administrators. - Store / InstallService still receives
Access deniedfor the pause-update operation. - The built-in Administrator account does not have the same problem.
- Granting
UsersFull Control on the two affected InstallService registry keys immediately makes the pause function work again. - The issue returns after clean Windows installations.
- The registry workaround only fixes this specific Store pause problem.
- Other Store / Store-SDK / InstallService / LiveID / CloudStore errors remain present and are not fixed by this workaround.
Because of that, I consider the registry change a workaround and diagnostic clue, not a permanent fix. Windows should not require users to manually grant broad write permissions to system registry keys just to use a normal Microsoft Store function.
The other Store / InstallService / LiveID / CloudStore errors may or may not share the same root cause. I am including them for reference because they may help Microsoft correlate what changed, but I do not want to claim that they are all caused by the same bug without evidence.
If you have the same error, it may be worth checking the effective permissions on those two InstallService registry keys and comparing your Store / InstallService logs with the ones in that thread.
For Microsoft, I think the important part is to reproduce this on a clean Windows installation and compare:
- a normal Microsoft-linked administrator account;
- a normal local administrator account;
- the built-in
Administratoraccount; - the effective access tokens and integrity levels used by Microsoft Store / InstallService;
- the default ACLs and ownership of
InstallServiceandInstallService\State; - why
PauseAutoUpdateAsyncreceivesAccess denied; - which Windows / Store / InstallService component creates or restores these permissions during setup and servicing;
- whether a recent Windows, Store, InstallService or account/security change altered the expected permissions or token handling.
Until Microsoft identifies the underlying cause, I would treat the registry permission change only as a temporary workaround.
If you can reproduce the same behavior, it is worth reporting it through Feedback Hub as well and including the exact Store / InstallService errors and reproduction steps so Microsoft has more comparable reports.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(60.8, 33%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ELN%3C/text%3E%3C/svg%3E)