trouble installing Windows cumulative updates after an incomplete language pack removal

Williams Noah 20 Reputation points
2026-11-05T22:30:21.1+00:00

I'm having trouble installing Windows cumulative updates after an incomplete language pack removal. Could this be related to leftover language components, package dependencies, or corrupted system files?

How can I check what's still installed and figure out what went wrong? Any tips on troubleshooting the servicing logs would be greatly appreciated. Thanks!

Windows for business | Windows Client for IT Pros | User experience | Other
0 comments No comments

2 answers

Sort by: Newest
  1. Domic Vo 36,745 Reputation points Independent Advisor
    2026-11-06T00:33:11.6666667+00:00

    Hello,

    Yes. An incomplete language pack removal can leave behind language-related packages or pending servicing operations that interfere with cumulative updates. However, you should verify the package state and servicing errors before assuming language components are the cause.

    Start by checking installed language capabilities and packages from an elevated Command Prompt:

    DISM /Online /Get-Intl
    DISM /Online /Get-Packages /Format:Table
    

    Look for language-related packages with states such as Install Pending, Uninstall Pending, or unexpected remnants of the removed language. Do not manually remove packages just because their names contain a language identifier; some are dependencies of Windows features.

    Check the servicing logs immediately after a failed update. The most useful files are:

    C:\Windows\Logs\CBS\CBS.log
    C:\Windows\Logs\DISM\dism.log
    

    Search CBS.log for Error, Failed, 0x800f081f, 0x800f0831, and CBS_E_STORE_CORRUPTION. Pay attention to the package identity and timestamp surrounding the first failure, rather than focusing only on the final error.

    If component-store corruption is reported, run:

    DISM /Online /Cleanup-Image /ScanHealth
    DISM /Online /Cleanup-Image /RestoreHealth
    sfc /scannow
    

    Restart Windows and retry the cumulative update. If DISM reports 0x800f081f, it may require a matching Windows repair source.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    Domic Vo.

    Was this answer helpful?

    0 comments No comments

  2. AI answer

    2026-11-05T22:31:42.8666667+00:00

    Inventory the installed language packages and capabilities with DISM, then correlate any pending or residual items with the exact failure in CBS.log before removing anything else.

    1. Inventory what remains installed

    Open Command Prompt as administrator and save the current language, package, and capability inventories:

    mkdir C:\Temp 2>nul
    DISM /Online /Get-Intl > C:\Temp\International.txt
    DISM /Online /Get-Packages /Format:Table > C:\Temp\Packages.txt
    DISM /Online /Get-Capabilities > C:\Temp\Capabilities.txt
    DISM /Online /Cleanup-Image /ScanHealth > C:\Temp\ScanHealth.txt
    

    DISM reports package states such as Installed, Install Pending, and Staged. /Get-Intl lists installed languages, while /Get-Capabilities reports Features on Demand such as language Basic, Handwriting, OCR, Speech, and Text-to-Speech components.^1^^2^

    Search the output for:

    • The locale that was incompletely removed, such as fr-FR.
    • Package states including Install Pending.
    • Language capabilities still marked Installed.
    • Packages whose identity includes the removed locale.

    For details about one residual capability, copy its exact identity from Capabilities.txt:

    DISM /Online /Get-CapabilityInfo /CapabilityName:Language.Basic~~~fr-FR~[IP Address]
    

    Language.Basic~~~fr-FR~[IP Address] is only an example; do not assume that identity or version. Use exactly what /Get-Capabilities reports.

    Do not manually delete files from WinSxS, C:\Windows\servicing\Packages, or the registry. These are component-store resources managed by the servicing stack.

    2. Correlate the update failure with servicing logs

    Reproduce the cumulative-update failure once and note its time and error code. Then review:

    • C:\Windows\Logs\DISM\DISM.log — primary log for DISM operations.
    • C:\Windows\Logs\CBS\CBS.log — detailed component-based servicing failures.
    • C:\Windows\Servicing\Sessions\Sessions.xml — transaction state and session IDs.

    For online servicing, DISM.log normally points to the relevant CBS details; Sessions.xml helps identify the failed transaction.^3^

    Search near the failure timestamp for the update error code, removed locale, and terms such as:

    Failed to resolve package
    manifest missing
    CBS MUM Missing
    CSI Payload Corrupt
    CSI Manifest Corrupt
    Store corruption
    Install Pending
    0x800f081f
    0x800f0831
    0x80073712
    

    Interpret the evidence separately:

    • A language package or capability named immediately before the failure suggests an incomplete language-component transaction or dependency.
    • manifest missing or Failed to resolve package identifies a package dependency or metadata failure. For example, 0x800F0831 means the failing update requires a previous package manifest that is unavailable.^4^
    • Payload, manifest, or component-store corruption without a language identity indicates broader servicing corruption rather than proving that the language removal caused it.^5^

    3. Repair only after collecting the evidence

    Run DISM first, followed by SFC:

    DISM /Online /Cleanup-Image /RestoreHealth
    sfc /scannow
    

    DISM repairs the component store that SFC uses as its repair source. Restart if requested, then retry the cumulative update.^6^

    After SFC, extract only its [SR] records with:

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

    That extract diagnoses SFC repairs only; use the full CBS.log for language-package and cumulative-update failures.

    If /RestoreHealth reports that source files cannot be found, use a known-good repair source matching the installed Windows release, edition, architecture, and language—preferably also its servicing level:

    DISM /Online /Cleanup-Image /RestoreHealth /Source:C:\RepairSource\Windows /LimitAccess
    

    Replace C:\RepairSource\Windows with the actual matching Windows source. A mismatched source can leave DISM unable to locate the required components.^5^

    4. Persistent failures

    If DISM cannot repair the store, collect the complete servicing dataset before escalation:

    .\TSS.ps1 -CollectLog DND_SETUPReport
    

    Run this from an elevated PowerShell session after meeting the TSS prerequisites. The report collects CBS, Windows Update, servicing, policy, and related diagnostics for Microsoft Support.^7^

    At that point, use a supported in-place repair installation with matching Windows media, or contact Microsoft Support and provide the TSS package. An in-place repair is preferable to manually deleting packages or manifests.


    References

    1. Take Inventory of an Image or Component Using DISM
    2. DISM Capabilities Package Servicing Command-Line Options
    3. Deployment Troubleshooting and Log Files
    4. Error 0x800F0831 when you install an update
    5. Fix Windows Update corruptions and installation failures
    6. Use the System File Checker tool to repair missing or corrupted system files | Microsoft Support
    7. Collect data to analyze and troubleshoot Windows servicing, Updates, and Features on Demand scenarios
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

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.