Combined SSU+LCU package (KB5099540) — cumulative update not listed in installed updates, only the SSU (KB5120210) appears

Question

Combined SSU+LCU package (KB5099540) — cumulative update not listed in installed updates, only the SSU (KB5120210) appears

Daniel Reuveni 0

On Windows Server 2019 (OS Build 20348), we installed the July 14, 2026 cumulative update KB5099540. As documented, this combined package implicitly applies the servicing stack update (SSU) KB5120210 as part of the installation.

After the installation completes, Windows' list of installed updates shows only the SSU (KB5120210) and does not show the cumulative update (KB5099540).

Can you confirm the following:

Is this the expected behavior for combined SSU+LCU packages — i.e., the SSU is registered as its own listed/permanent update entry while the LCU (cumulative update) is not shown as a separate KB entry?
What is the authoritative way to confirm that the cumulative update KB5099540 itself was successfully applied? Should we rely on the OS build number (20348.5386) via winver / Get-ComputerInfo rather than the installed-updates list?
Is there a supported command (e.g., DISM /online /Get-Packages or Get-HotFix) that will reliably report the LCU portion as installed?

0 comments

2 answers

Your answer

Answer 1

Daniel Reuveni 0

answered removed

0 comments

Answer 2

Brian Huynh 3,650 Microsoft External Staff Moderator

Hello Daniel, thank you for posting in the Microsoft Q&A community.

To answer your questions directly:

While visually this can occasionally happen depending on the installation method (such as WSUS vs. Standalone Installer), ideally, the LCU should also appear in the installed updates list. If it does not, it is not the intended behavior, but rather a known quirk of the WMI Win32_QuickFixEngineering class (which feeds the Control Panel list) or an indication of an LCU installation failure.
Relying on the OS Update Build Revision (UBR) is the absolute and most authoritative method to confirm if the LCU applied successfully. Because cumulative updates directly increment the core OS build revision, verifying this number is foolproof. You can safely rely on winver, Get-ComputerInfo, or by querying the registry directly. If your UBR reflects your target build (such as .5386), the LCU is completely installed and active, regardless of what the GUI reports.
Since Get-HotFix relies on the same WMI class that populates the Control Panel, it might miss the LCU if there is a CBS display issue. The most robust command to check the true package state in the CBS store is using the DISM tool to query the packages directly, as officially documented by Microsoft.

I will follow up on this thread to ensure your issue is resolved. If this information helps clarify the behavior, please consider clicking "Accept Answer" so that other community members can benefit from it.

For official Microsoft documentation on verifying and managing packages with DISM, you can refer to: DISM Operating System Package (.cab or .msu) Servicing Command-Line Options | Microsoft Learn

Daniel Reuveni 0 Reputation points

2026-07-28T08:07:10.5233333+00:00

If "it is not the intended behavior, but rather a known quirk of the WMI Win32_QuickFixEngineering class", does it mean it's a known bug? Is there a plan to fix it?
Brian Huynh 3,650 Reputation points Microsoft External Staff Moderator

2026-07-29T01:24:20.0233333+00:00
Thank you for following up.

To be completely transparent, Microsoft generally classifies this behavior as an architectural limitation of a legacy component rather than an active, critical "bug" that impacts system health or security.

When Microsoft transitioned to modern servicing models and introduced combined SSU/LCU packages, the update payloads became much more complex. Because the Servicing Stack Update (SSU) must be extracted and staged before the Latest Cumulative Update (LCU) can be applied, this legacy WMI class will occasionally only parse and register the first component (the SSU) it sees during the transaction.

Because this limitation is tied to legacy WMI architecture, there is currently no publicized roadmap or timeline from the Windows product group to overhaul the Win32_QuickFixEngineering class. The engineering focus remains strictly on the Component-Based Servicing (CBS) engine to ensure updates are securely applied, and that the underlying OS Update Build Revision (UBR) increments accurately. Microsoft's stance is that the UBR and the CBS store are the single source of truth for update compliance.

If you are writing automation scripts to query update history programmatically without using Get-HotFix, the recommended practice is to query the Windows Update Agent (WUA) API directly using COM object.

You can run this PowerShell snippet to pull an accurate list of successfully installed updates directly from the Windows Update engine:

$UpdateSession = New-Object -ComObject "Microsoft.Update.Session" $UpdateSearcher = $UpdateSession.CreateUpdateSearcher() $HistoryCount = $UpdateSearcher.GetTotalHistoryCount() $UpdateSearcher.QueryHistory(0, $HistoryCount) | Where-Object { $_.ResultCode -eq 2 } | Select-Object Title, Date, SupportUrl

(Note: A ResultCode of 2 indicates that the update was installed successfully).