Looking at the cbs log you will see things like this
Hashes for file member \SystemRoot\WinSxS\x86_microsoft-windows-u..ed-telemetry-client_31bf3856ad364e35_6.1.7601.18839_none_a1e9aa37653a7ea4\telemetry.ASM-WindowsDefault.json do not match actual file [l:66{33}]"telemetry.ASM-WindowsDefault.json" :
Found: {l:32 b:ddW/ziH5iRGiXQCN1UI4xhGYdCmRBwYaMf/LZiyKogk=} Expected: {l:32 b:EeQJzlVPvq9GNIcA2FEwrOjEeuDam1G+ol3x61gKasQ=}
Notice this part
Found: {l:32 b:ddW/ziH5iRGiXQCN1UI4xhGYdCmRBwYaMf/LZiyKogk=}
Expected: {l:32 b:EeQJzlVPvq9GNIcA2FEwrOjEeuDam1G+ol3x61gKasQ=}
What this is saying is the found one is the hash of the file and windows looks at the cat file to pull what the hash of the file should be and as you can see they dont match. If a file is changed even by 1 byte the hash changes.
So either the file is corrupted or the cat file is. Problem is we dont know which and the log doesnt give us much to go on. Sometimes the system readiness tool from MS can help but if it doesnt and there is file corruption in the winsxs folder you may have no option other than doing a repair install of windows because MS has no way of rebuilding the winsxs folder.
Depending how many files are found to be bad we could just manually replace the files from a good machine, but if there is a LOT of files then a repair install is going to be needed.
In this case you also had a mum file that was shown as bad, mainly because it was modified somehow and so the hash didnt match. Well now I am seeing that in a lot of other places, this doesnt normally happen unless something went and messed with them OR the hard drive has bad sectors and those files are on the bad sectors and so are getting corrupt.
Have you done a bad sector check on the drive yet?
The command for it is to open a cmd.exe window as administrator and put it
chkdsk C: /r
It will say the drive is in use and would you like to do it at next boot, hit Y and have it do it and then reboot and let the scan go, it will take a while but lets see what it shows.
Shane
