system32 vs. syswow64 DLL hash errors I can't fix.

after doing sfc /scannow, CBS.log reports these hash errors I can't fix.

[590]2024-01-23 17:48:02, Info CSI 00000223 Hashes for file member [l:13]'srmclient.dll' do not match.
[594]2024-01-23 17:48:02, Info CSI 00000225 Hashes for file member [l:11]'srmscan.dll' do not match.
[598]2024-01-23 17:48:02, Info CSI 00000227 Hashes for file member [l:12]'srmshell.dll' do not match.
[602]2024-01-23 17:48:02, Info CSI 00000229 Hashes for file member [l:13]'adrclient.dll' do not match.
[606]2024-01-23 17:48:02, Info CSI 0000022b Hashes for file member [l:14]'srmstormod.dll' do not match.

The ownership, in system32 and syswow64 plus on another PC which does pass sfc /scannow all match including dates and file sizes.

I've tried the dism restorehealth with /ResetBase and componstorecleanup. I've tried an in place install that keeps my files.

As a last resort, I tried to copy from a good win 10 laptop where both have win10pro from the syswow64 directory to the laptop with the issue for these files, but it would require changing alot of permissions. I'm not sure that any user entries and settings such as give full control is in the registry that some how impacts the computation for the hashes. Since I dont know what hash calculation they are doing such as checksum, sha, or some other one, I wouldn't know which free program to get that would calculate these for the system32 and syswow64 for each dll file so that I could compare the computed values to validate what windows is calculating.

In the end, is the hash calculated upon sfc /scannow on the fly or are these values stored somewhere. Hopefully its not getting things from a restore point, since if the restore point is turned off, they wouldnt have any data to use for computation or replacement. What if I replace the winsxs windows store files for the bad dll filenames? The files in this directory are a different name and each have long number on the end of each one that could be the expected checksum that is being used.
So for example, adrclient.dll comes up with around 7matches in this directory when searched with *adrclient*

Hence one of the files found is,
C:\Windows\WinSxS\x86_microsoft-windows-fsrm-common_31bf3856ad364e35_10.0.19041.3636_none_e227a6e75dc6ede8

will contain adrclient.dll when windows explorer searches for the filename and within the file and then shows the various filesizes and it appears this one matches the filesize of the one in the system32 and syswow64 directory.
The CBS.log hash error for adrclient.dll is,
Expected: {l:32 ml:33 b:3cb523323b2a7d84df82908f7610ff8b9b949bfdf554a12bd98ee1e77d23a046}.
Actual: {l:32 b:3300568140cc4269662e0edd8b71c7ef4fbc92ba8e87c5293d6815ac1410dda0}.

Hence these long numbers don't match the above filename numbers.

Any ideas besides reinstalling the OS from scratch?

One thing would be to downgrade win10pro back to win10home since these filese pertain to win10pro. I could hope that on downgrade they'd be removed. Then upgrade back to win10pro to get them back and fix the problem. However, I don't see an option to downgrade unless changing the license to a win10home license would do the trick!

swegmike said:

Any ideas besides reinstalling the OS from scratch?

Yes, you could try an in-place repair install.

Repair Install Windows 10 with an In-place Upgrade

Hi I read through your first post. I may have missed it, but is there anything other than the hash thing that you're experiencing on the computer that's messing up?

Sometimes when I do the sfc check command, I get a bunch of stuff that isn't fixable either. I ignore them, and look for specific problems on the computer that I could fix.


But I have this excerpt from my computer notes that I have, that you could try out. Do note that this is a bit old, and some visual methods within the directions may have slightly changed over time. Or in other words, I haven't done the following in a long time, but it's worth checking out. It tells you a different, more Admin-style, method of running those "integrity" scans. It's what is written in the orange box:

I see. I would search the web for such, for example:
dism mount errors for wim images - Search

If you can get a screenshot / copy-paste text of the specific error. Maybe we can find a solution that might probably have nothing to do with the sfc error. It's possible. Not 100% sure.

I see. You've had this problem for a few weeks, and you're trying to figure out what the issue is. I skimmed through your earlier posts, and sorry if I write stuff that you have already tried or came across.
So I'm not too well at all this, but I'm searching the web for possibly relevant information that you can take a look at.

I'd search the web for stuff that has to do with:
dism "There is a mismatch between the tag specified in the request and the tag present in the reparse point"

An idea:
Also, I see stuff in the results that have to do with OneDrive. Do you use it? If not, maybe temporarily disable it.
But before doing that, look at the links below.

Links:
Fixed: How To Fix Windows Error 0x8007112A - RespawnFirst

[FIXED] OneDrive "The tag present in the reparse point buffer is invalid" Error

windows - Can't remove, rename or copy old OneDrive folder (0x8007016B) - Super User

windows - Cannot delete a folder that have the "The tag present in the reparse point buffer is invalid" - Super User

I tried to downgrade by entering a valid win10 Home license in the field that says enter license. It will not activate and gives error code 0xc004f050.

Next try, is to deactivate the license and hopefully the registry is marked such that windows thinks it is a fresh install. Then reenter a win10home license to get rid of the files associated with win10pro. Then I'll try to run sfc /scannow and if it passes, upgrade to win10pro again with a valid license to see if my issues disappear. This can be thought of as kinda like an in-stall upgrade....

- - - Updated - - -

====
Here's a slightly different way to do an inplace upgrade
https://answers.microsoft.com/en-us/...c-a890775e7907

== reactivate and already activated win10pro ====
Since my laptop already is activated to win10pro, I thought I try and see what happens if a reenter the win10pro license.
It accepted it and activated my win10pro even though it is already activated. It didn't give a message stating it was already activated.....
Then reran sfc /scannow and no change on the same 6 dlls that have hash errors.

======
Tell microsoft that my machine is new hardware even though its the same hardware.....!

I couldn't get Microsoft to display this selection for new hardware.

=====
I deactivated my win10Pro digital license from the computer, then rebooted. I then reassigned the same license
and it reactivated but sfc still shows hash errors. I probably should've run sfc after deactivation then reactivate and rerun again.
The number of combinations is alot. So I'll stop for now.

- - - Updated - - -

=====
I deleted the problem dlls in both the syswow64 and for the directory in winsxs that contains all of them
C:\Windows\WinSxS\x86_microsoft-windows-fsrm-common_31bf3856ad364e35_10.0.19041.3636_none_e227a6e75dc6ede8.

I then copied from another laptop same model and win10pro with the patches for these and put them in the respectived directories above. I then rebooted ran dism restorehealth, StartComponentCleanup, and ValidateComponentStore options.
Then rebooted again and ran sfct /scannow. Still errors on the has in syswow64

- - - Updated - - -

======
I deleted only one problematic dll to narrow down whats happening.
1). I deleted the adrclient.dll in system32,
2). I reran sfc /scannow and it pulled from winsxs the missing dll thats in the winsxs subdirectory for "amd64......". Since it put the 136k adrclien.dll back in system32, I then reran sfc but its complaining about the syswow64 hash.
3). I deleted the adrclient.dll in the syswow64 directory.
4).I reran sfc /scannow and it pulled from winsxs the 136k adrclient.dll from winsxs which is in the "amd64....." subdirectory. Originally this was 98k which matches the one in the winsxs "x86...." subdirectory. Then reran sfc /scannow a second time thinking the hashes should match the one in system32, and it still complained about the hash in syswow64.
5). To make sure I reran sfc /scannow a third time, and now the 100k file is copied from the winsxs "x86...." subdirectory. but the hashes still don't match.

Summary,
when sfc /scannow is run it is matching the hash of a file in syswow64 with the one it finds in winsxs. The same goes for matching the hash of the file in system32 with the one it finds in winsxs. It appears that system32 file on a x64 OS matches the "Amd64...." subdirectory in winsxs and the one in syswow64 matches the one in "x86...." subdirectory in winsxs. For the syswow64 one would assume that due to the directory name having "64" that it should match the x64 bit file in winsxs "amd64...." and not the 32bit one in "x86.....".
If this is the case, then why aren't there more errors?

swegmike said:

... For the syswow64 one would assume that due to the directory name having "64" that it should match the x64 bit file in winsxs "amd64...." and not the 32bit one in "x86.....".

No, they should be x86.The 'WoW' stands for 'Windows on Windows', it's the subsystem for running 32-bit software on a 64-bit OS.

WoW64 (Windows 32-bit on Windows 64-bit) is a subsystem of the Windows operating system capable of running 32-bit applications on 64-bit Windows.

WoW64 - Wikipedia