Windows Server 2025 Azure Edition: DISM 0x800f0915 and SFC hash mismatch in RDS Licensing components

Question

Windows Server 2025 Azure Edition: DISM 0x800f0915 and SFC hash mismatch in RDS Licensing components

Dan Adrian Cherciu 0

We are experiencing persistent Windows Component Store corruption on a production Azure VM running Windows Server 2025 Datacenter: Azure Edition.

System information

Edition ID: ServerTurbine

OS build: 10.0.26100.33438

DISM version: 10.0.26100.5074

Server roles: Active Directory Domain Services, DNS, Remote Desktop Services (Session Host and Licensing)

The VM is running and accessible through RDP.

Problem

DISM /Online /Cleanup-Image /ScanHealth reports that the component store is repairable.

DISM /Online /Cleanup-Image /RestoreHealth fails with:

0x800f0915 - CBS_E_REPAIR_CONTENT_MISSING

sfc /scannow reports that corrupt files were found but some could not be repaired.

CBS.log identifies corruption in the following components:

Microsoft-Windows-TerminalServices-LicenseServer-LRWIZDLL

Microsoft-Windows-TerminalServices-LicenseServer-TLSBrand

The affected files include LServer_PKConfig.xml and tls_branding_config.xml.

For LServer_PKConfig.xml, component version 10.0.26100.33158, CBS reports:

Expected SHA-256:

13bf8ca71a639aa2fd30e16a97c603eac597bc79706c0bc21403d1fa5444b8bb

Actual SHA-256:

cfa5c1d46b882f7980fbacca01c6cfe80aad5ec96392d3f839dbd7ef27f40321

CBS also reports:

Could not reproject corrupted file C:\Windows\System32\LServer_PKConfig.xml; source file in store is also corrupted

We confirmed that the copies under WinSxS component versions 26100.33158 and 26100.4652, and the System32 file, are hard links to the same underlying file.

Troubleshooting already performed

Windows Update issues were resolved, and subsequent cumulative updates installed successfully.

No WSUS policy or explicit servicing repair-source restriction was identified.

DISM ScanHealth confirms corruption; RestoreHealth fails because replacement content is missing.

SFC cannot repair LServer_PKConfig.xml.

CBS logs identify the affected components, versions, and expected/actual hashes.

Attempts to locate replacement files in Microsoft Update packages did not yield a usable repair source.

A similar case with the exact same incorrect file hash has been reported here:

https://www.sysnative.com/forums/threads/lserver_pkconfig-xml-hash-mismatch-with-server-2025.43087/

Request

We are looking for a Microsoft-supported repair procedure for these components on Windows Server 2025 Datacenter: Azure Edition (ServerTurbine).

Specifically:

Is this a known component servicing issue affecting Windows Server 2025?

Is there a specific cumulative update or supported repair source containing the correct component payloads?

Can the component store be repaired without manually modifying WinSxS, deploying a second VM, or performing an in-place OS upgrade?

Because this is a production server and domain controller, we would prefer a non-disruptive repair method.

Thank you.We are experiencing persistent Windows Component Store corruption on a production Azure VM running Windows Server 2025 Datacenter: Azure Edition.

System information

Edition ID: ServerTurbine

OS build: 10.0.26100.33438

DISM version: 10.0.26100.5074

Server roles: Active Directory Domain Services, DNS, Remote Desktop Services (Session Host and Licensing)

The VM is running and accessible through RDP.

Problem

DISM /Online /Cleanup-Image /ScanHealth reports that the component store is repairable.

DISM /Online /Cleanup-Image /RestoreHealth fails with:

0x800f0915 - CBS_E_REPAIR_CONTENT_MISSING

sfc /scannow reports that corrupt files were found but some could not be repaired.

CBS.log identifies corruption in the following components:

Microsoft-Windows-TerminalServices-LicenseServer-LRWIZDLL

Microsoft-Windows-TerminalServices-LicenseServer-TLSBrand

The affected files include LServer_PKConfig.xml and tls_branding_config.xml.

For LServer_PKConfig.xml, component version 10.0.26100.33158, CBS reports:

Expected SHA-256:

13bf8ca71a639aa2fd30e16a97c603eac597bc79706c0bc21403d1fa5444b8bb

Actual SHA-256:

cfa5c1d46b882f7980fbacca01c6cfe80aad5ec96392d3f839dbd7ef27f40321

CBS also reports:

Could not reproject corrupted file C:\Windows\System32\LServer_PKConfig.xml; source file in store is also corrupted

We confirmed that the copies under WinSxS component versions 26100.33158 and 26100.4652, and the System32 file, are hard links to the same underlying file.

Troubleshooting already performed

Windows Update issues were resolved, and subsequent cumulative updates installed successfully.

No WSUS policy or explicit servicing repair-source restriction was identified.

DISM ScanHealth confirms corruption; RestoreHealth fails because replacement content is missing.

SFC cannot repair LServer_PKConfig.xml.

CBS logs identify the affected components, versions, and expected/actual hashes.

Attempts to locate replacement files in Microsoft Update packages did not yield a usable repair source.

A similar case with the exact same incorrect file hash has been reported here:

https://www.sysnative.com/forums/threads/lserver_pkconfig-xml-hash-mismatch-with-server-2025.43087/

Request

We are looking for a Microsoft-supported repair procedure for these components on Windows Server 2025 Datacenter: Azure Edition (ServerTurbine).

Specifically:

Is this a known component servicing issue affecting Windows Server 2025?

Is there a specific cumulative update or supported repair source containing the correct component payloads?

Can the component store be repaired without manually modifying WinSxS, deploying a second VM, or performing an in-place OS upgrade?

Because this is a production server and domain controller, we would prefer a non-disruptive repair method.

Thank you.

0 comments

2 answers

Your answer

Answer 1

Welcome to Microsoft Q&A!

Thank you for taking the time to provide such detailed CBS findings, including the component information and file hashes.

Based on the information you have provided, this does not appear to be a typical RDS licensing or role-configuration issue. Instead, the CBS findings indicate that an RDS Licensing component contains a file that no longer matches the hash recorded in its component manifest, while DISM is unable to obtain suitable repair content.

The hard-link relationship you observed between the System32 file and its WinSxS locations is also important. Because these locations reference the same underlying file, they should not be treated as independent healthy copies that can simply be copied over one another.

1. Is this a known Windows Server 2025 issue?

At the time of writing, I could not identify a published Windows Server 2025 known issue specifically documenting hash corruption involving these RDS Licensing components or files:

Microsoft-Windows-TerminalServices-LicenseServer-LRWIZDLL
Microsoft-Windows-TerminalServices-LicenseServer-TLSBrand
LServer_PKConfig.xml
tls_branding_config.xml

The report you found from another administrator showing the same incorrect hash is certainly useful supporting information. However, a matching community report by itself would not be enough to confirm that Microsoft has identified this as a Windows Server 2025 servicing defect.

I would therefore recommend continuing to monitor the Windows Server 2025 release-health documentation for any related servicing advisory or resolution.

2. Supported non-upgrade repair approach

Microsoft's documented approach for component-store corruption is to use DISM to repair the Windows image. When Windows Update cannot provide the required content, DISM can be directed to a known-good repair source.

For example:

DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:<valid-repair-source> /LimitAccess

If the repair completes successfully, run:

sfc /scannow

Then verify the component store again:

DISM.exe /Online /Cleanup-Image /ScanHealth

For this scenario, particular care should be taken when selecting the repair source. It should appropriately match the affected deployment, including:

Windows Server 2025 Datacenter: Azure Edition
Architecture
Installation type, such as Server Core or Desktop Experience
Language
The applicable component and servicing state

I would not automatically assume that a standard Windows Server 2025 Datacenter ISO is a suitable repair source for a Windows Server 2025 Datacenter: Azure Edition installation.

Likewise, installing or extracting a cumulative update does not necessarily provide the missing payload that CBS requires. Therefore, I would avoid identifying a particular cumulative update as a fix unless Microsoft specifically documents that it resolves this component corruption.

If you have appropriate matching media containing install.wim, you can first determine the available image indexes:

DISM /Get-WimInfo /WimFile:<drive>:\sources\install.wim

After confirming the correct matching image, the WIM can be specified as the repair source:

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

I would only proceed with this approach after confirming that the image is appropriate for the installed Azure Edition, architecture, language, and installation type.

3. What I would avoid

Given that this is a production server, I would not recommend manually replacing files inside WinSxS, rebuilding hard links, taking ownership of component-store files, or manually copying the XML files into the component directory.

These changes would bypass the normal Windows servicing mechanism and could make the component-store state more difficult to service afterward.

Similarly, removing and reinstalling the RDS Licensing role should not be treated as a component-store repair. The underlying issue identified by CBS needs to be resolved at the servicing/component level.

4. Recommended next step

Considering the troubleshooting you have already completed, I believe you have reached the point where opening a Microsoft Support case would be the safest next step.

Windows Update is functioning and cumulative updates can be installed, but DISM still cannot obtain the content necessary to repair the affected components. At the same time, there does not appear to be a publicly documented corrective update or confirmed Azure Edition repair source for this exact hash mismatch.

I recommend providing Microsoft Support with:

CBS.log and DISM.log
msinfo32 output
Output of DISM /Online /Get-CurrentEdition
Output of DISM /Online /Get-Packages /Format:Table
Output of DISM /Online /Get-Features /Format:Table
Azure Marketplace image publisher, offer, SKU, and original image version
Whether Hotpatch is enabled
Installed language and language-pack information
Affected component identities and versions
Expected and actual SHA-256 hashes
Complete DISM error information, including 0x800f0915
Confirmation that the VM is a production domain controller and RDS Licensing server
The other report showing the identical hash mismatch

Since Microsoft Q&A is a public community forum, I do not have access to Microsoft's internal servicing investigations or unpublished fixes. Microsoft Support would be in a better position to determine whether the component metadata or payload is affected by a confirmed servicing issue and whether an appropriate repair package or Azure Edition repair source is available.

In short:

I could not find public confirmation that this exact RDS Licensing hash mismatch is a known Windows Server 2025 servicing issue.
I would not identify a particular cumulative update as the fix without Microsoft documentation confirming it.
DISM using a genuinely compatible repair source remains the preferred non-upgrade repair approach.
If an appropriate source cannot repair the component store and 0x800f0915 persists, I would recommend escalating the case to Microsoft Support rather than manually modifying WinSxS.
Before attempting further servicing or recovery work on this production VM, make sure you have a verified backup or Azure OS-disk snapshot and that your Active Directory recovery procedures are available.

References:

I hope this helps clarify the safest path forward

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.

Dan Adrian Cherciu 0 Reputation points

2026-10-13T04:26:16.71+00:00

Thank you for your assistance and detailed explanations.

Following the recent Windows updates and corrective actions, our production server appears to be operating normally, and the RDP freezing issue has not reoccurred so far.

Although DISM still reports component store corruption, we have decided to postpone further repair attempts to avoid unnecessary risks to a currently stable production server.

We will continue monitoring the system and revisit the issue if any problems arise.

Thank you again for your support.

Answer 2

There is currently no Microsoft-published known issue, cumulative-update fix, or confirmed repair payload specifically for the LServer_PKConfig.xml/tls_branding_config.xml hash mismatch; the remaining supported non-upgrade attempt is DISM against a correctly indexed, fully patched Windows Server 2025 Datacenter: Azure Edition source.

What is—and is not—documented

As of October 11, 2026:

The Windows Server 2025 release-health page does not list this file/hash mismatch or CBS_E_REPAIR_CONTENT_MISSING as a known servicing issue.^1^
Build 26100.33438 is the September 8, 2026 update level, KB5122871. Its RDS known issue concerns RDS instability and unresponsive tools, not component-store hash mismatches. That issue was resolved by updates released on or after September 14, 2026.^2^
The identical third-party hash report is useful correlation, but it does not establish a Microsoft-recognized defect or a supported payload.
No supplied Microsoft update note identifies a CU that replaces these two RDS Licensing files with the expected hashes.

Installing the latest update is still appropriate because the server is on the affected September build and later updates resolve the documented RDS instability. However, there is no evidence that this will repair the XML hash mismatch.

Final supported repair-source attempt

Do not copy files into WinSxS, break the hard links, alter manifests/catalogs, or take ownership of component-store paths. That would place the installation in an unsupported servicing state.

A source must be:

Windows Server 2025 Datacenter: Azure Edition, not ordinary Datacenter.
The same architecture, installation type, and languages.
Patched to at least the target’s CU level. Microsoft warns that repair can fail when the target is patched higher than the source.^3^

Because the original media will normally be older than build 26100.33438, mount and service a copy of the correct Azure Edition WIM to the target’s current—or newer—CU first. Then identify its exact index:

dism /Get-WimInfo /WimFile:E:\sources\install.wim

Mount the matching Datacenter: Azure Edition index read-only or use the indexed WIM directly. For example:

mkdir C:\RepairMount
dism /Mount-Image /ImageFile:E:\sources\install.wim /Index:<AzureEditionIndex> /MountDir:C:\RepairMount /ReadOnly
dism /Online /Cleanup-Image /RestoreHealth /Source:C:\RepairMount\Windows /LimitAccess
dism /Unmount-Image /MountDir:C:\RepairMount /Discard
sfc /scannow
dism /Online /Cleanup-Image /ScanHealth

DISM officially supports a mounted Windows directory as /Source; /LimitAccess prevents fallback to Windows Update.^4^ Microsoft’s Azure VM procedure likewise calls for the same OS version and build, followed by SFC.^5^

If servicing the WIM is impractical, Microsoft also supports a shared Windows directory from a working installation running the same OS version.^6^ That technically requires another installation, which you have excluded.

If the matching source still fails

At that point, no documented non-disruptive command-line procedure remains for this exact corruption. Open an Azure/Microsoft Support case and provide:

C:\Windows\Logs\CBS\CBS.log
all CbsPersist_*.cab
C:\Windows\Logs\DISM\dism.log
C:\sfcdetails.txt, generated with:

findstr /c:"[SR]" C:\Windows\Logs\CBS\CBS.log > C:\sfcdetails.txt

Include the component identities, both hashes, hard-link findings, exact WIM edition/index/build used, and the complete matching-source DISM result. Microsoft’s Azure guidance explicitly recommends collecting these logs when the documented steps do not resolve the corruption.^5^

Recovery boundary for this domain controller

Microsoft’s generic Azure VM guidance makes an in-place upgrade the fallback after DISM and a known-good source fail; it preserves applications, settings, and data but requires multiple restarts.^5^

However, current Windows Server guidance says not to use an in-place upgrade for servers running AD DS; the preferred recovery is a clean OS installation, promotion of a replacement domain controller, and demotion of the affected DC.^7^ Therefore:

Try the exact-edition, fully patched source once.
If it fails, escalate for a Microsoft-provided payload or servicing fix.
If Support cannot provide one, plan role separation and DC replacement rather than manually repairing WinSxS or performing an unsupported/no-longer-recommended repair upgrade on this DC.

References