Finally in this build 10049, I can run SFC /SCANNOW completely. I've extracted just the SR results from cbs.log showing repairs, but one did not fix. Has something to do with powershell. I've rebooted and rerun 3 times, the recommended. Any thoughts?
sfcdetails.txt
Yeah ! It's good to see SFC working again !
Why do you want to run it? All this is telling you is one file doesn't match what is in the store and what is in the store is corrupt. It says:You could repair the store by running dism. Most likely this will not work as MS haven't uploaded these versions to their servers.Could not reproject corrupted file [ml:140{70},l:138{69}]"??C:WINDOWSSystem32WindowsPowerShellv1.0ModulesSmbShareen-US"[l:40{20}]"SmbLocalization.psd1"; source file in store is also corrupted
You can force dism through by specifying a /source .wim and then sfc will work. The question is whether forcing the version of SmbLocalization.psd1that happens to be on the .wim you extract from your esd is either required or sensible.
I think on the whole I would not bother as I know of no way to say which is correct. That's my 2c.
Adam, there was no particular thing I was trying to fix. I just knew in previous builds it would not run correctly, and was just testing. I've done the DISM routine before, on 10041 using the ISO as source, but did not repair anything in store. Got the exact same results I got this time. Just wondering if the non-repairable component was anything to be concerned about. Testing only, no big deal.Why do you want to run it? All this is telling you is one file doesn't match what is in the store and what is in the store is corrupt. It says:
You could repair the store by running dism. Most likely this will not work as MS haven't uploaded these versions to their servers.
You can force dism through by specifying a /source .wim and then sfc will work. The question is whether forcing the version of SmbLocalization.psd1that happens to be on the .wim you extract from your esd is either required or sensible.
I think on the whole I would not bother as I know of no way to say which is correct. That's my 2c.
SmbLocalization.psd1 is part of the language pack and these things have been an issue for most of the TP, nothing to worry about.Just wondering if the non-repairable component was anything to be concerned about. Testing only, no big deal.
The two json files, utc.app.json & telemetry.ASM-WindowsDefault.json were successfully repaired on my machine with
Dism /Online /Cleanup-Image /RestoreHealth /WIM:<ISO mounted drive letter>:Sourcesinstall.wim:1 /LimitAccess
The LimitAccess parameter just tells Dism to not use Windows Update.
SmbLocalization was not reported on my machine, so I don't know which index of the WIM the file is located.
Try running the Dism command with each index as the source
wim:1
wim:2
wim:3
wim:4
Then run SFC again
Thanks for the reply. Already had done the DISM and SFC and fixed same as you. This was the SR detail before I had run DISM. Only thing that was left was the SmbLocalization.psd1, so I'm not concerned a bit! It had something to do with powershell, which is fine, and I'm not running in Korean or anything but EN-US. Have a good one!SmbLocalization.psd1 is part of the language pack and these things have been an issue for most of the TP, nothing to worry about.
The two json files, utc.app.json & telemetry.ASM-WindowsDefault.json were successfully repaired on my machine with
Dism /Online /Cleanup-Image /RestoreHealth /WIM:<ISO mounted drive letter>:Sourcesinstall.wim:1 /LimitAccess
The LimitAccess parameter just tells Dism to not use Windows Update.
SmbLocalization was not reported on my machine, so I don't know which index of the WIM the file is located.
Try running the Dism command with each index as the source
wim:1
wim:2
wim:3
wim:4
Then run SFC again
