"C:\ProgramData\Packages" folder is also permission-sensitive

[EyeDeck]

Quick foreword, I managed to hose my OS permissions while trying to clean up some old backups. Took ownership of a folder from an old drive that was refusing to delete, which hit a symlink "mine" that made the script work itself onto C:\, and of course I dug my hole even deeper while trying to fix whatever that broke. Oops.

Anyway, this script fixed most of everything I broke, which went from all UWP things refusing to work and/or install with a 0x80070005 error, into just some things refusing to install (test case was MS's Xbox app). Some related errors from the event viewer that hopefully some search engine will pick up on and lead here some poor soul who fell into the same circle of hell that I did:

5282 Creation of the secure system app data folder failed with error code : 0x800700B7.
5252 An internal error occurred with error 0x800700B7. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.
306 error 0x800700B7: While processing the request, the system failed to register the windows.stateExtension extension due to the following error: Cannot create a file when that file already exists.
316 error 0x800700B7: Cannot register the request because the following error was encountered during the registration of the windows.stateExtension extension: Cannot create a file when that file already exists.
5252 An internal error occurred with error 0x800703FA. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.
331 error 0x800703FA: While reverting the request, the system failed to de-register the windows.stateExtension extension due to the following error: Illegal operation attempted on a registry key that has been marked for deletion.

The final problem ended up being the C:\ProgramData\Packages folder, which doesn't seem to have nearly as complicated permissions as C:\Program Files\WindowsApps and %localappdata%\Packages, but it's similarly sensitive and will break a ton of UWP things if its permissions are changed slightly.

Ultimately I fixed my own issue by going into a full system backup from a few days prior, and using icacls /save and /restore to copy the old permissions back over. "Just restore a backup", while not bad advice, is also generally not useful, so perhaps it would be appropriate to write some extra code into this script that could programmatically fix this folder up too. I could try to describe what the permissions should be, but you probably have a better understanding of this than I do, so it would probably be much more informative to just look at the folder permissions yourself.

Thanks and stuff, the script is very useful.

[AgentRev]

I see, I will look into adding this. Thanks for the report.

[EyeDeck]

Nice, thanks.

[AgentRev]

2 years late but better than never 😆