Beta build 28020.2298 unfixable errors after running sfc /scannow

Question

Beta build 28020.2298 unfixable errors after running sfc /scannow

Bert22306 150

Feature Update 28020.2298 installed fine and seems to run fine too. I am not noticing problems. But from an overabundance of obsessive thinking, I ran sfc /scannow. It claims there are unfixable errors. Sigh.

I went to the \Windows\Logs\CBS\CBS.log file and found a long series of entries. Luckily, it seemed very clear that the only mentions of errors that couldn't be fixed had to do with Windows-cleanmgr. I'll copy just a couple of these lines from the log file.

2026-06-17 21:26:09, Info CSI 00000214 Hashes for file member 'Disk Cleanup.lnk' do not match.

Expected: {b1085da2d41e01be689d6b1b22d0e89d80bb045d76b53969d5d8ae89de38ef92}.

Actual:   {6aaf2fdfa74612f67e37b075702cd690a3ce4c0ac777319eacc4c2d73f6c7b85}.

2026-06-17 21:26:09, Info CSI 00000215 [SR] Cannot repair member file [l:16]'Disk Cleanup.lnk' of Microsoft-Windows-cleanmgr, version 10.0.28000.2298, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, hash mismatch

2026-06-17 21:26:09, Info CSI 00000216 Hashes for file member 'Disk Cleanup.lnk' do not match.

Expected: {b1085da2d41e01be689d6b1b22d0e89d80bb045d76b53969d5d8ae89de38ef92}.

Actual:   {6aaf2fdfa74612f67e37b075702cd690a3ce4c0ac777319eacc4c2d73f6c7b85}.

2026-06-17 21:26:09, Info CSI 00000217 [SR] Cannot repair member file [l:16]'Disk Cleanup.lnk' of Microsoft-Windows-cleanmgr, version 10.0.28000.2298, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, hash mismatch

??? Hash mismatch why? Anyone have a clue?

The only odd thing I notice is mention of "arch amd64." I'm on the Beta channel, with the 26H1 build selected, but with an Intel Corei7 CPU. It's supposed to work, from what I've read. I can understand that if Winodws thinks I'm using an AMD CPU, depending how these hashes are built, there could be a problem.

Any thoughts appreciated. Again, all seems to run well, even disk cleanup seems to run just fine, so at least, this is more curiosity than anything urgent.

Thanks, guys.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

The CBS.log entries indicate that System File Checker detected a hash mismatch for the shortcut file Disk Cleanup.lnk that belongs to the Microsoft-Windows-cleanmgr component and could not repair it from the component store. This is the same pattern as other known cases where SFC reports hash mismatches or “corrupt” files even though the system is functioning normally.

Key points from the log:

Hashes for file member 'Disk Cleanup.lnk' do not match.
[SR] Cannot repair member file 'Disk Cleanup.lnk' of Microsoft-Windows-cleanmgr ... in the store, hash mismatch

This means:

The hash SFC expects for that shortcut (from the original component definition) does not match the hash of the copy in the component store.
SFC treats this as a corruption of that component, but it does not necessarily mean the OS is unstable or that Disk Cleanup is actually broken.

Similar documented behavior:

There are known scenarios where SFC flags files as corrupted because they were legitimately updated or changed out-of-band, or because they are not protected in the way SFC expects. For example:
- Windows Defender PowerShell module files updated via a separate channel were flagged as “Hashes for file member do not match” even though they were valid, trusted files. This was later fixed in an engine update so SFC would stop flagging them.
- Static or non–Windows Resource Protection files can be logged as changed in CBS.log even when the system reports “All files and registry keys listed in this transaction have been successfully repaired,” and no actual repair is required.

The arch amd64 in the log does not indicate that Windows “thinks” the CPU is AMD. In this context, amd64 is simply the standard architecture name for 64‑bit x86 (used on both Intel and AMD processors). It is not related to the hash mismatch and is expected on a 64‑bit Intel Core i7 system.

As long as:

SFC only reports this shortcut as unrepairable, and
The system and Disk Cleanup run normally,

this is consistent with a benign SFC/CBS logging issue rather than a functional problem with the OS.

If desired, the usual supported repair sequence is:

Run DISM to repair the component store:

   DISM.exe /Online /Cleanup-Image /RestoreHealth

Then run SFC again:
```
   sfc /scannow
```

This is the documented approach for cases where SFC reports corruption but the system otherwise appears healthy.

References: