Windows 11 25H2 Devices Experiencing Servicing State Inconsistencies with Cumulative Updates

I'm looking for guidance on a Windows servicing issue that has been affecting a subset of devices in our environment for several months.

We manage approximately 3,000+ Windows 11 25H2 devices, and this issue is only occurring on a portion of them, roughly 100-300 devices. The remaining devices update normally and do not exhibit this behavior.

When reviewing Component Based Servicing (CBS) package states on affected systems, I consistently find that build 26100.6899 is marked as Superseded, build 26100.7840 is marked as Installed, and newer builds such as 26100.8037 and 26100.8246 are marked as Resolved. CBS logs also indicate that the RollupFix package for 26100.7840 is installed.

However, despite CBS reporting that 7840 is installed, the active operating system appears to still be running files from the older update level. For example, ntoskrnl.exe remains at version 10.0.26100.6899 on affected devices. This creates what appears to be a mismatch between the servicing state reported by CBS and the actual OS binaries that are active on the system.

Another consistent observation is that the newer update levels, such as 8037 and 8246, never seem to progress beyond the Resolved state. They are detected and considered applicable but never transition to Staged or Installed.

While reviewing CBS logs, I found entries indicating that TrustedInstaller had previously been interrupted:

"It looks like TI crashed or was interrupted last time it was started"

and

"Mark session as corrupt since it is neither complete nor pended"

CBS later appears to recover successfully and reports normal completion without an active reboot-pending state.

To troubleshoot, we have already performed the following actions on affected devices:

• DISM CheckHealth
• DISM ScanHealth
• DISM RestoreHealth
• SFC /SCANNOW
• Reset Windows Update components by renaming both the SoftwareDistribution and Catroot2 folders
• Multiple reboots
• Repeated update deployment attempts through NinjaOne OS Apply

Despite these remediation steps, affected devices continue to show the same behavior:

• 6899 marked as Superseded
• 7840 marked as Installed
• 8037 and 8246 marked as Resolved
• ntoskrnl.exe remaining at 26100.6899
• Newer cumulative updates never advancing beyond Resolved

Because this issue is impacting only a subset of devices across a large fleet and has persisted for months despite standard servicing remediation, I'm trying to determine whether this points to:

• A CBS servicing state inconsistency
• A partially committed cumulative update
• A component store issue that DISM is not detecting
• A known Windows servicing defect
• Some other condition that can leave CBS reporting a newer RollupFix package as installed while the active OS binaries remain at an older revision

Has anyone encountered a similar situation where CBS reports RollupFix 26100.7840 as installed, while ntoskrnl.exe remains on 26100.6899 and subsequent cumulative updates remain stuck in the Resolved state? If so, what logs, package states, or remediation steps would you recommend investigating before considering an in-place repair upgrade?

Has anyone encountered a similar situation where CBS reports RollupFix 26100.7840 as installed, while ntoskrnl.exe remains on 26100.6899 and subsequent cumulative updates remain stuck in the Resolved state? If so, what logs, package states, or remediation steps would you recommend investigating before considering an in-place repair upgrade?

As a side note: Doing a clean install of windows has managed to fix these issues before however we would like to figure out if there is a more efficient solution.