Server 2025 - Pinned shortcuts to start menu causes system corruption according to SFC - File hash

Clement, Ronald (SSC/SPC) 0 Reputation points
2026-08-27T17:04:22.8033333+00:00

While doing testing of the new OS, I found as issue with pinning applications to the start menu.

Our build configuration is to have the start menu with a common look and feel. So after processing some app removals, I proceeded to pin the applicable apps to the start menu. Then one of my steps is to do a SFC /scannow to ensure all is good. before packaging for release to use. This is where the issue comes in and multiple testing has been done.

You can do this yourself and I wonder if it will show the same results. (I hope I just have a bad iso file) (which I need to do hash checks on - ok one step I skipped)

Install windows server 2025 on a new machine. (we have vmware - and configured the system with default vmware supported devices), however we do reconfigure the drives so that the recovery drive is in front of the OS drive (allows extending the C: drive in VMWare later (EFI, MSR, Recovery, OS)). After logging in with the administrator account, open PowerShell and run SFC /scannow. After confirming no issues, click on the start menu, type in an app (notepad perhaps), expand the options and select go to file location. Right click on the app (shortcut) and select pin to start menu. Repeat for anything else. Run sfc /scannow.

You should get store corruption.

If the system is not updated with any patch you can use DISM to do a repair, however you have to use the 2025 disk. there doesn't seem to be any local repair resource. At least DISM always says that (Can't find source files).

DISM.exe /online /cleanup-image /restorehealth /source:WIM:D:\Sources\Install.WIM:2 /limitaccess

Then run SFC /scannow. and the issue is gone. Update the system to the latest patch, pin an application to the start menu and bam the issue is back. Try to do DISM repair fails as it seems that it wants the information from the update and not the default config in Install.wim, but it always says resource files not found.

After looking at the CBS log files I found that it is actually complaining about the shortcut file hash. They do not match what is in the component store (that's where is compares right?)

So how do I make pinning shortcuts not cause errors with SFC or file hash or whatever and why does DISM not find source files?

Windows for business | Windows Server | Performance | Windows desktop and shell experience
0 comments

1 answer

Sort by: Oldest
Most helpful Newest Oldest
  1. Allan Solomon Mejia 8,585 Reputation points
    2026-08-27T20:39:59.5166667+00:00

    Hello @Clement, Ronald (SSC/SPC)

    This doesn't necessarily mean pinning an application is corrupting Windows. Based on the behavior you described, SFC appears to be detecting a hash difference in a shortcut (.lnk) that Windows modifies as part of Start menu customization.

    The important thing is to identify exactly what CBS is reporting. After reproducing the issue, run:

    findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log > "%userprofile%\Desktop\SFC-details.txt"

    If the only reported files are shortcuts that you intentionally pinned or modified, I would treat this differently from actual WinSxS/component-store corruption. There have also been other reports of Start menu pinning behavior on Windows Server 2025, so a shell/servicing interaction is plausible rather than a damaged ISO.

    For the DISM source-files-not-found issue, the ISO source needs to match the installed Windows Server edition closely. After cumulative updates, the installed OS can also be at a substantially newer servicing level than the original ISO, which can make the RTM install.wim unsuitable as a repair source.

    First, determine the correct WIM index:

    DISM /Get-WimInfo /WimFile:D:\sources\install.wim

    Then use the index corresponding to the installed edition, for example:

    DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:<index> /LimitAccess

    Using :2 without verifying the index isn't safe because the index depends on the media. Microsoft guidance similarly recommends checking the WIM contents before selecting the repair source.

    The fact that your original ISO repairs the unpatched installation but fails after Windows Server 2025 is updated is particularly significant. Windows Server 2025 cumulative updates also service the component store, so I would test with updated installation media that matches the server's servicing level, rather than assuming the original ISO remains a valid repair source. Microsoft documents servicing Windows Server 2025 installation media with cumulative update packages.

    I also wouldn't manually delete or replace files under WinSxS to satisfy SFC. If CBS consistently identifies the same .lnk files immediately after a supported Start menu pin operation, while DISM otherwise reports the image healthy, this is worth reporting to Microsoft as a Windows Server 2025 servicing/Start menu issue, with the CBS log and exact OS build attached.

    Sharing these references with you:

    Microsoft: Repair a Windows image with DISM ·

    Microsoft Q&A: Server 2025 Start Menu pinned items

    Windows Server 2025 servicing example

    Please "Accept the Answer" if this information helped you. This will help us and others in the community.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.