I recently suffered from some kind of MFT corruption that caused all permissions on my entire installation to be wiped. This made the disk "unaccessable" from another Windows installation which made me believe the disk was damaged in some kind of way. My goal is not to do an "in place upgrade", I know it's possible to repair Windows, even if it's severely broken and to most users completely unusable, especially since I know what the problem is but not how to properly fix it.
Symptoms of the problem:
- The computer booted but got stuck on the spinning dots with a black screen. After left on for a couple hours it would go to sleep and upon being turned back on display a black screen with a cursor. This is a typical indication of a problem accessing the disk, more specifically it indicates that the system is unable to write to the disk during boot (or that's what I assume since I have seen identical symptoms from having a 100% full disk. And I don't mean a disk that's full when inside Windows, I mean a disk that's filled to 100% while the system on it is offline.).
- The disk was not showing the amount of used storage when loaded in a different Windows installation. It also refused to load the contents of the disk if the user tries to open it. Oddly enough Windows 7 does show the contents of the disk (perhaps fully blocking disk access is a new feature on W8), but not a single folder or file on it can be opened.
- A warning that the recycle bin on the disk is corrupt.
- After resetting the permissions with icacls, all UWP apps fail to open, often the text is completely missing causing everything to be blank like dialogs without text and desktop icons with no name.
After a bit of messing around I found out it was just the permissions on the disk, I started by checking the permissions on the disk itself and it gave a message that the owner couldn't be displayed. After changing the owner to Administrators I could use icacls to "reset" all permissions on the disk to "default" and the system on the disk was bootable again. The problem is that the permissions by icacls are just some generic default permissions and NOT the actual permissions a stock installation would have. For example, the UWPs do not work anymore, since these run in special app containers that have special permissions for each container separately. There are also many problems with .NET and other apps like Visual Studio that don't work due to insufficient permissions.
I checked all the logs I could find and every time any app crashes again it's an error code 5 "Access is denied." or a "File not found." or "Permission denied" which I expect to be part of the same simple problem.
Clearly the guides online suggesting to use icacls * /t /c /q /reset are for generic circumstances but don't actually completely reset the permissions to the actual default.
From my understanding of icacls it's actually possible to back up the permissions and restore them. You can dot that with a command like this:
icacls C:\Windows\* /save C:\WindowsAcs.txt /T
This file contains the user permissions stored as paths relative to the path provided when running icacls with /save. If we for example provide "C:\Windows*" it will put all the folders with their full path but "C:\Windows" stripped from the full path. It also contains what I assume are the SID (Security Identifier) of each user that has permission and the attributes in the following format:
D:AI(A;OICIID;FA;;;BA)(A;OICIID;0x1200a9;;;BU)(A;OICIID;FA;;;AU)
This is what the default permissions look like in a backup where the permissions are defined by running icacls /reset.
A second way to restore the permissions I found out is to actually "delete" a system folder by renaming it or moving it to the trash or some other temporary directory for testing and then running sfc /scannow immediately afterwards. This puts back the deleted system files from the default module in WinSXS. If the module in WinSXS is damaged you can repair it using dism with /cleanup-image /restorehealth, which to my understanding repairs the component store with copies of the same version of the module from Microsoft's servers.
I tested this by renaming C:\Windows\SystemApps and running sfc. This resulted in the SystemApps folder being recreated and after checking the permissions on them they sure enough are all completely restored to normal judging by the UWP specific "all application packages" and also a specific application package for each app separately. I chose this folder since I know the container apps are very sensitive to file permissions but despite them being fully restored now, I still can't run apps like the shell experience host which keeps the start menu from working, suggesting to me that there must be some other libraries in a different directory that also require special permissions.
What I want to try now is to get a backup like this made from a working computer and restore it onto the damaged system. Is this the right way to do it or are there better ways to restore all permissions? Is there somewhere I can get official permissions from a stock installation or can I perhaps fetch them from the installation disk by mounting or extracting the wim/esd? If there are no tools for automating this process, I might have to make one myself.
I know there are permissions for the system files in the component store (C:\Windows\WinSXS) so is it possible to use the command line or anything else to restore all permissions from there?
