How to change expected hash in Component store?

[chrcol]

So I change the default command prompt link properties, mainly to enable UAC elevation by default but also some other parameters, in turns out this freaks out SFC.

SFC detects my default command prompt link is customised and tries to fix (or reports in verifyonly mode), however then also states the one in component store is also corrupt as the hash is wrong value compared to the expected value. (The store also has my customised version)

Path here.

C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\System Tools\\Command Prompt.lnk

Store is 'Microsoft-Windows-CommandPrompt-Shortcut'

Apparently I need to fix a manifest with the hash value of my customised link, how do I do that or am I completely on the wrong track to fix this issue?

 

[garlin]

To pass a clean SFC scan, you need to overwrite the file's original copy in the matching WinSxS folder.

Matching as to find the last WinSxS component folder which contains your file, because there can be multiple versions after Monthly Updates are installed. Whether or not you've run DISM cleanup, it's the last folder version that matters.

Command Prompt.lnk lives in one of the WinSxS\amd64_microsoft-windows-commandprompt-shortcut_31bf3856ad364e35_* folders.

Using PowerRun or NSudo, open a CMD shell with TrustedInstaller rights and replace the file.

Keep in mind, Windows might replace this file in a future CU and you will have to repeat this process on a live system. But something like the Command Prompt shortcut is less likely to be updated.

 

[chrcol]

To pass a clean SFC scan, you need to overwrite the file's original copy in the matching WinSxS folder.

Matching as to find the last WinSxS component folder which contains your file, because there can be multiple versions after Monthly Updates are installed. Whether or not you've run DISM cleanup, it's the last folder version that matters.

Command Prompt.lnk lives in one of the WinSxS\amd64_microsoft-windows-commandprompt-shortcut_31bf3856ad364e35_* folders.

Using PowerRun or NSudo, open a CMD shell with TrustedInstaller rights and replace the file.

Keep in mind, Windows might replace this file in a future CU and you will have to repeat this process on a live system. But something like the Command Prompt shortcut is less likely to be updated.

This is the thing, it was already in there , the modified file.

There was 2 errors.

The one in the OS was a mismatch (this triggered a SFC failure).
The one in the WinSxS already matched the one in the main OS install, but that generated a warning if /scannow was used because its hash was a mismatch to the expected hash (question in the thread), the expected hash matched the one on the original unmodified ISO.

So it seems if you just replace the WinSxS file the manifest also needs updating with the correct hash for the new file.

I have ended up putting the original one back in the users/default path, this has made SFC say no integrity violations even though it now mismatches WinSxS, and will sometime this weekend with elevated permissions put the original back in WinSxS as well, as a working solution I added yet another command in my post install script to handle this by copying it to the first account whilst leaving the default alone to keep SFC happy.

There is also only one folder for the shortcut. I did consider the possibility of being multiple versions.

So to summarise.

It looks like there is a hash stored somewhere (the manifest?), if the hash on the live file mismatches, it generates a SFC violation.
If the copy stored in WinSxS also doesnt match the hash, then it will make SFC refuse to do the repair, as it then considers the WinSxS copy corrupt.
If the live file has a matching hash to the expected hash, then the state of the file in WinSxS doesnt matter and no violation will be reported.