Windows Server 2022 KB5087545 fails with 0x80073701 due to missing pl-PL ServerStandard language pack component

Question

Question:

Answer 1

Matěj Vajnar 21

Hi, I went through almost identical issue just now. It was just that I have a WS 2022 Datacenter installed from en_US ISO, but I have a region etc... set to Czech. Tried all the fixes you tried with the same result. And what fixed it was going to windows settings - language and region and there install the Czech Language pack.

Hope it helps you also.

Microsoft should get its act together, like Bro its not your first day shipping updates. Microsoft365 I wont even talk about how much that is broken.

BZ 0

Thank you for the input. That is useful, but I would like to clarify an important difference in my case.

This does not look like a simple case where the affected language pack was never installed.

On this server, the current pl-PL Server Language Pack is already installed:


Microsoft-Windows-Server-LanguagePack-Package~31bf3856ad364e35~amd64~pl-PL~10.0.20348.3453

State: Installed

There is also an older pl-PL package still present as superseded:


Microsoft-Windows-Server-LanguagePack-Package~31bf3856ad364e35~amd64~pl-PL~10.0.20348.3328

State: Superseded

The actual CBS failure, however, is not against the currently installed 20348.3453 pl-PL language pack. It points to this older superseded ServerStandard package/component chain:


Microsoft-Windows-Editions-ServerStandard-Package~31bf3856ad364e35~amd64~pl-PL~10.0.20348.3328

DISM can query this exact package:


Package Identity:

Microsoft-Windows-Editions-ServerStandard-Package~31bf3856ad364e35~amd64~pl-PL~10.0.20348.3328

Release Type: Language Pack

State: Superseded

Install Client: UpdateAgentLCU

Install Time: 2025-03-14

Restart Required: Possible

The package metadata files also exist under:


C:\Windows\servicing\Packages

For example:


Microsoft-Windows-Editions-ServerStandard-Package~31bf3856ad364e35~amd64~pl-PL~10.0.20348.3328.mum

Microsoft-Windows-Editions-ServerStandard-Package~31bf3856ad364e35~amd64~pl-PL~10.0.20348.3328.cat

The .mum file references this component:


<assemblyIdentity

  name="Microsoft-Windows-Editions-ServerStandard-Deployment-LanguagePack"

  version="10.0.20348.3328"

  processorArchitecture="amd64"

  language="pl-PL"

  buildType="release"

  publicKeyToken="31bf3856ad364e35"

  versionScope="nonSxS" />

This matches the CBS failure exactly:


HRESULT_FROM_WIN32(ERROR_SXS_ASSEMBLY_MISSING)

from Windows::ServicingAPI::CCSITransaction::ICSITransaction_PinDeployment

a = Microsoft-Windows-Editions-ServerStandard-Deployment-LanguagePack

version 10.0.20348.3328

arch amd64

culture pl-PL

CBS then fails while resolving:


Microsoft-Windows-Editions-ServerStandard-Package~31bf3856ad364e35~amd64~pl-PL~10.0.20348.3328.Microsoft-Windows-Editions-ServerStandard-Package

HRESULT = 0x80073701 - ERROR_SXS_ASSEMBLY_MISSING

And the KB5087545 LCU fails afterward:


Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.5139.1.14

Identifier: KB5087545

HRESULT = 0x80073701 - ERROR_SXS_ASSEMBLY_MISSING

I also checked WinSxS directly.

There are many pl-PL WinSxS components on the server:


(Get-ChildItem "C:\Windows\WinSxS" -Filter "*pl-PL*").Count

3208

However, I do not find any WinSxS directory matching the failing Editions / ServerStandard / pl-PL component:


Get-ChildItem "C:\Windows\WinSxS" |

Where-Object {$_.Name -like "*pl-PL*" -and $_.Name -like "*dition*"} |

Select-Object Name

This returns no result.

A broader WinSxS search shows several pl-PL resource components, and some ServerStandard/Datacenter-looking entries at 10.0.20348.3453, but not the failing 10.0.20348.3328 Editions/ServerStandard deployment component.

So the current state appears to be:


- Current pl-PL Server Language Pack 10.0.20348.3453 is installed.

- Older pl-PL 10.0.20348.3328 package chain is still present as superseded.

- CBS registry and DISM know about the failing 20348.3328 ServerStandard package.

- The .mum and .cat metadata files exist in C:\Windows\servicing\Packages.

- The referenced WinSxS deployment component/payload appears to be missing.

- KB5087545 fails during CBS Resolve / PinDeployment with 0x80073701.

I also ran:


dism /online /cleanup-image /StartComponentCleanup

It completed successfully.

Afterward:


dism /online /cleanup-image /AnalyzeComponentStore

reported:


Number of Reclaimable Packages : 0

Component Store Cleanup Recommended : No

But the failing superseded package is still present and still queryable by DISM.

So my concern is that this is not simply “install the missing language pack”. The current pl-PL language pack is already installed. The issue appears to be an incomplete or orphaned superseded pl-PL ServerStandard component chain from 10.0.20348.3328.

My question is:

What is the safest supported remediation path for this exact state?

Specifically:

Should I try DISM /RestoreHealth first, allowing Windows Update to provide repair content?


dism /online /cleanup-image /RestoreHealth

If a source is required, what source can contain the missing 10.0.20348.3328 pl-PL ServerStandard deployment payload? It seems to originate from an older LCU / KB5053603-era package, not from the base Windows Server 2022 ISO.
Is it supported to remove the exact superseded package with DISM?


dism /Online /Remove-Package /PackageName:"Microsoft-Windows-Editions-ServerStandard-Package~31bf3856ad364e35~amd64~pl-PL~10.0.20348.3328" /NoRestart

Or would that likely fail as well because CBS may need to resolve the same missing WinSxS deployment component during removal?
Is there any supported way to repair or remove this orphaned superseded pl-PL component chain without doing an in-place repair install?

I would like to avoid manual CBS registry editing or direct WinSxS manipulation. I am looking for a supported repair sequence.

Answer 2

Hello,

Thank you for posting question on Microsoft Windows Forum!

Based on the detailed issue description. I would like to share my thought on the plausible explanations to your queries.

While using dism /Online /Remove-Package is a supported command, attempting to run it against this specific package will almost certainly fail with the exact same 0x80073701 (ERROR_SXS_ASSEMBLY_MISSING) error. When the Component Based Servicing (CBS) engine processes an uninstallation transaction, it evaluates the package's components to roll them back cleanly. Because the underlying physical directory in C:\Windows\WinSxS for Microsoft-Windows-Editions-ServerStandard-Deployment-LanguagePack version 10.0.20348.3328 is missing, the uninstallation transaction will choke and abort. On the other hand, since your CBS log shows a missing Microsoft-Windows-Editions-ServerStandard-Deployment-LanguagePack assembly for pl-PL, it is not recommended to start by deleting that exact superseded package with dism /Online /Remove-Package. Microsoft does support package removal as a servicing operation, but that is a package-removal action, not the documented repair path for a broken language-pack dependency chain.

Regarding dism /online /cleanup-image /ScanHealth returning no corruption. Well! It is normal in this scenario. As /ScanHealth and /CheckHealth primarily validate the structural integrity and cryptographic signatures of the package manifests (.mum) and catalogs (.cat) found inside C:\Windows\servicing\Packages. Since those files are fully intact on your system, DISM assumes the component store manifest structure is healthy. The actual error only triggers during a execution/pinning transaction when the servicing engine tries to cross-reference those healthy manifests with their corresponding physical payload directories inside WinSxS and finds an unexpected omission.

You can refer to the following articles for more information about troubleshooting for this issue.

Hope the above information is helpful!

BZ 0 Reputation points

2026-05-27T13:57:05.3066667+00:00

Thank you for the explanation.

I understand that removing the superseded package directly may fail because the WinSxS payload for Microsoft-Windows-Editions-ServerStandard-Deployment-LanguagePack 10.0.20348.3328 pl-PL is missing.

However, I still need the supported remediation path.

Could you please clarify the exact next supported step?

Should I run DISM /Online /Cleanup-Image /RestoreHealth without /Source first, allowing Windows Update to be used as the repair source?

If a repair source is required, what source can contain the missing 10.0.20348.3328 pl-PL component, considering that it appears to come from KB5053603 / an older LCU and not from the base Windows Server 2022 ISO?

Is there a supported way to repair this superseded pl-PL component chain without an in-place repair install?

If not, is in-place repair install the only supported remediation?

I am not looking for a general CBS explanation, but for the safest supported repair sequence for this exact condition.

Windows Server 2022 KB5087545 fails with 0x80073701 due to missing pl-PL ServerStandard language pack component

System:

Windows Update event:

MoSetup / UpdateAgent.log shows:

Relevant ActionList.xml:

After extracting the relevant CbsPersist logs, I found the actual CBS failure:

DISM sees the problematic package:

Result:

The package .mum and .cat files exist under C:\Windows\servicing\Packages.

The .mum references this component:

However, the corresponding WinSxS component directory for:

I also ran:

After that:

However, the problematic package:

Question:

2 answers

Your answer

Windows Server 2022 KB5087545 fails with 0x80073701 due to missing pl-PL ServerStandard language pack component

System:

Windows Update event:

MoSetup / UpdateAgent.log shows:

Relevant ActionList.xml:

After extracting the relevant CbsPersist logs, I found the actual CBS failure:

DISM sees the problematic package:

Result:

The package .mum and .cat files exist under C:\Windows\servicing\Packages.

The .mum references this component:

However, the corresponding WinSxS component directory for:

Installed / related pl-PL packages include:

I also ran:

After that:

However, the problematic package:

Question:

2 answers

Your answer