Servicing Stack Update Before Cumulative Update: Why the Order Matters and What a Combined SSU+LCU Package Really Is

Every Windows update is installed by code. That code is itself shipped as an update. If you have never thought about that circularity before, this post is about the moment it bites you.

The component that installs Windows updates is called the servicing stack. Microsoft ships fixes for it as a servicing stack update, or SSU. A cumulative update, or LCU (latest cumulative update), is the monthly package of security and quality fixes. The SSU has to be current before the LCU can apply. Get that order wrong and Windows fails with an error code that names nothing helpful.

The problem: an update that refuses to install, and a rollback that does nothing

There are two failures in this story, and they look unrelated until you know the mechanism.

Failure one. You are servicing a Windows 11 reference image offline. You mount install.wim, inject this month's cumulative update with DISM, and it fails. Or a technician downloads an .msu from the Microsoft Update Catalog, runs it on a machine that has been off for six months, and it fails. The error code is 0x800f0823.

That code has a name. Microsoft documents it as CBS_E_NEW_SERVICING_STACK_REQUIRED, and the troubleshooting article tells you to search CBS.log for a line like this one:

Read that line slowly. The package is not corrupt. The disk is not full. The package is telling you it needs a newer version of the installer than the one you have. Microsoft's own wording for the cause is blunt: the error means the computer's servicing stack is out of date, and if it occurs the computer cannot process new updates correctly.

Failure two. A cumulative update goes out, something regresses, and you want it gone. You reach for the tool you have always used:

Both failures come from the same fact. The thing that installs updates is itself an update, and Microsoft has to be careful about the order in which those two things touch a machine.

Why it happens: the stack that installs updates has to update itself first

What the servicing stack actually is

Start with the plainest possible definition, which is Microsoft's own. Servicing stack updates provide fixes to the servicing stack, the component that installs Windows updates.

That component is bigger than it sounds. The same documentation says the servicing stack contains the component-based servicing stack, abbreviated CBS, and that CBS underpins several other things you use every week:

• DISM - Deployment Image Servicing and Management, the tool you use to service images.
• SFC - System File Checker, which is sfc /scannow.
• Changing Windows features or roles.
• Component repair.

So the servicing stack is not a small helper for Windows Update. It is the transaction engine for the entire component store. When it is out of date, every one of those operations is at risk.

The chain, from click to reboot

Here is what calls what, in order, when an update installs on a running device.

1. The Windows Update service (wuauserv) downloads the payload into C:\Windows\SoftwareDistribution\Download.
2. The update agent hands the package to the Windows Modules Installer service. Its short name is TrustedInstaller, and its binary is C:\Windows\servicing\TrustedInstaller.exe.
3. TrustedInstaller launches TiWorker.exe, the worker process that does the real work.
4. TiWorker loads CbsCore.dll, the CBS engine, and wcp.dll, the Windows component platform that reasons about manifests and component identities.
5. CBS evaluates applicability. This is where the servicing stack version check happens. If the package requires a newer stack than the one loaded, you get 0x800f0823 and nothing else happens.
6. Files that cannot be replaced while Windows is running are queued into a pending operations queue. At the next boot, poqexec.exe drains that queue before the session manager starts anything else. That is why so many updates need a restart.

Now the important part. If the package being installed is a servicing stack update, CBS has to swap out its own engine. It cannot overwrite CbsCore.dll underneath itself mid-transaction. So the new stack is installed side by side in the component store, and the next servicing operation loads the new one. You can watch this happen in CBS.log, and we will do exactly that later.

Why order matters, in Microsoft's words

Microsoft's servicing stack update FAQ states the rule without hedging: SSUs should always be installed before any new update for Windows, including the latest cumulative update, Monthly Rollup, or Security-only update.

Note what that sentence does not say. It does not say the SSU is optional if the LCU seems to install fine. It does not carve out an exception for offline images. It is an ordering rule for every delivery channel.

What a combined SSU+LCU package actually is

Before February 2021 the two packages were separate and you had to sequence them yourself. That produced a steady stream of support cases, so Microsoft changed the packaging.

The documented behaviour today: starting in February 2021, the cumulative update includes the latest servicing stack updates, providing a single combined cumulative update payload for Windows Update, WSUS and the Microsoft Update Catalog. It arrived on Windows 10 version 2004 and later with KB4601382.

Physically, a combined package is one .msu that contains both parts. When it installs, the update agent unpacks the SSU cab and applies it, then applies the cumulative payload. You can see the seam on a live device. On the machine I ran this on, the SSU's CBS registry key records its source as an SSU-26100.9156-x64.cab sitting inside the download folder of the cumulative update, and its InstallClient is UpdateAgentLCU. The SSU did not arrive on its own. It arrived inside the LCU.

Two consequences follow, and this is the part people get wrong.

Checkpoint cumulative updates, and the WinRE wrinkle

Two further behaviours matter if you service images on Windows 11 version 24H2 or later.

Checkpoint cumulative updates. Microsoft now periodically publishes a cumulative update as a "checkpoint". Subsequent monthly updates compute their binary differentials against the last checkpoint rather than against the original release, which makes packages smaller. If checkpoints precede your target update, the device or image needs those checkpoints before it can take the target. Devices updating from Windows Update and WSUS handle this seamlessly, so update processes involving those channels remain unchanged. Microsoft Update Catalog users have to handle it, and the documented way is to drop every relevant .msu into one folder and let a single DISM call discover and sequence them.

WinRE. The Windows Recovery Environment is serviced differently, and the checkpoint documentation is explicit about it: WinRE is serviced by applying the servicing stack update from a cumulative update, because the latest cumulative update itself does not apply, plus the SafeOS Dynamic Update. Microsoft adds that applying servicing stack update then SafeOS Dynamic Update is the only way to ensure WinRE is serviced. That is the clearest statement in the docs of why the servicing stack is a separable, orderable thing even inside a combined package.

The binaries involved

These are the files that do the work. Knowing them turns "the update failed" into "which layer failed".

Notice the pattern in the middle three rows. TiWorker.exe, CbsCore.dll and wcp.dll do not live in System32. They live in a version-stamped folder inside the component store, named amd64_microsoft-windows-servicingstack_<keytoken>_<version>_none_<hash>. That is the side-by-side mechanism that lets the stack replace itself. On the device I tested, two such folders existed: the original release version and the current one.

How to verify: build, UBR, servicing stack version and package state

You cannot get the order right if you cannot read the current state. There are four surfaces worth knowing, and they answer different questions.

Registry

Two parent keys carry everything. The first is where the build and revision live:

The second is the component-based servicing hive, where package state lives:

Microsoft's DISM repair documentation confirms that this hive is one of the three places DISM checks for integrity, alongside %SYSTEMROOT%\Servicing\Packages and %SYSTEMROOT%\WinSxS\Manifests. That is a good sanity check that you are looking at the right key.

PowerShell: the read you actually want

This first block answers "what build and revision is this machine on, and which servicing stack is loaded". Run it elevated - the CBS hive denies access to standard users.

Read the output as a pair. The servicing stack version and the UBR come from different packages and will not match. On my test device the stack was 10.0.26100.9156 while the UBR was 9168. That is normal: the SSU that shipped inside the August cumulative update was built at revision 9156, and the cumulative payload took the OS to 9168.

This second block uses DISM, which is the supported way to read package state and, critically, the only way to see which client installed a package.

Why Get-HotFix is not the answer

The instinct is to run Get-HotFix. It is the wrong tool here, and Microsoft's documentation says why.

Get-HotFix is a wrapper over the Win32_QuickFixEngineering WMI class. That class documentation states that it returns only the updates supplied by Component Based Servicing, that those updates are not listed in the registry, and that updates supplied by Windows Installer or the Windows Update site are not returned. It also warns that because updates are stored in two places, an enumeration of the class can result in duplicates.

In practice that means three limitations for our purposes:

1. It reports KB numbers, not servicing stack versions. It cannot tell you which SSU build you are on.
2. Its Description field is generic. A servicing stack update shows up as "Security Update", indistinguishable from a cumulative update.
3. Its InstalledOn field is date-only in practice, so it cannot show you that the SSU applied before the LCU on the same day.

Event Viewer

Servicing writes to one channel, and everything relevant carries one provider name.

Older Microsoft documentation for CBS also describes events 4371, 4372, 4373, 4374 and 4376, covering package state transitions and the not-applicable case. Those are documented against Windows Server 2008. On current Windows 11 builds the IDs I actually observed in the Setup log were 1, 2, 4, 1013 and 1014.

Log files

Three files, and the exact strings to grep for.

Microsoft's own troubleshooting article confirms the two CBS paths, and points at the Windows Update log files documentation for the wider picture. The healthy Loaded Servicing Stack line from my test device looks like this, and it is the single most useful line in the whole file:

Services and scheduled tasks

If TrustedInstaller is Disabled, nothing about servicing works and no amount of correct ordering will help. Microsoft documents the StartComponentCleanup task and notes that running the DISM equivalent deletes previous component versions immediately, without the grace period and without the one hour timeout the task carries.

The fix: the documented order, online and offline

Online devices: there is nothing to configure

This is the part that surprises people, so let me say it plainly. There is no Group Policy setting and no Intune or CSP setting that controls servicing stack update ordering. None. It is not that the policy is hard to find; it does not exist.

The ordering is a property of the package and the update client, not of policy. Since February 2021 the SSU and LCU travel together in a single payload, and Microsoft's guidance for on-premises deployment is that if you use an endpoint management tool backed by WSUS, such as Configuration Manager, you only have to select and deploy the monthly cumulative update, and the latest servicing stack updates are automatically applied correctly.

The policies that do exist govern where and when updates come from, not their internal order. Those are worth setting deliberately, so here are both consoles.

Group Policy Editor - point devices at WSUS so the combined package flows correctly.

1. Open Group Policy Management, or gpedit.msc for a local test.
2. Expand Computer Configuration, then Policies if you are in the domain editor.
3. Expand Administrative Templates, then Windows Components, then Windows Update.
4. Open Manage updates offered from Windows Server Update Service.
5. Open Specify intranet Microsoft update service location and set it to Enabled.
6. Enter your WSUS server URL for both the detection service and the statistics server.
7. Select OK, then run gpupdate /target:computer /force on a test device.
8. Confirm with Get-WindowsPackage -Online after the next patch cycle that exactly one Package_for_RollupFix is Installed and the rest are Superseded.

Intune admin center - deploy the monthly cumulative update and nothing else.

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Select Devices in the left navigation.
3. Select Windows updates.
4. Open the Update rings for Windows 10 and later tab.
5. Select Create profile, name the ring, and continue to Update ring settings.
6. Set Quality update deferral period (days) to your pilot value, for example 0 for the pilot ring and 7 for broad deployment.
7. Set Microsoft product updates and Windows drivers to match your standard.
8. Assign the profile to your pilot device group, then Create.
9. After the next cycle, check Reports, then Windows updates, and confirm devices moved to the expected build and revision.

Notice that neither list contains a servicing stack setting. That absence is the point.

Offline image servicing: this is where the order is yours to get right

Microsoft publishes a full sequence for updating installation media, and it is a table of 28 numbered tasks across four targets. The three that matter here are task 1 for winre.wim, task 9 for install.wim and task 17 for boot.wim. All three are the same task: add servicing stack update via latest cumulative update. It is task number one in the whole sequence, before language packs, before Features on Demand, before the cumulative update itself.

The documentation is explicit that for those three steps you should use the combined cumulative update, because since February 2021 the SSU and LCU are distributed together. It also gives the general ordering rule in words: first apply servicing stack updates, followed by language additions, then by feature additions, and finally the latest cumulative update.

Here is the shape of that, reduced to the calls that carry the ordering.

Read that carefully. The same .msu is applied twice to the same image on purpose. The first call is there for the servicing stack it contains. The last call is there for the cumulative payload, after your customisations, so that newly added languages and features are brought current.

Rolling back a bad month

When a cumulative update has to come off, this is the only supported path.

Proof it worked: a real device, read end to end

The companion script for this post reads every surface above and prints one report. It installs nothing, removes nothing and repairs nothing. It reads the registry, the file system, CBS.log, DISM package state and the two services, then refuses to give you a clean verdict if any read failed.

The output below is a genuine run on a Windows 11 25H2 device. Only the download folder hash and the component store hash are replaced.

That is the whole picture in one screen. The stack is at 9156, the OS is at 9168, the SSU arrived inside the LCU, the SSU applied first, and nothing is pending. This machine will take next month's cumulative update without an ordering problem.

The script exits 0 when every read succeeded and 1 when any read failed or the session was not elevated. It deliberately never prints a clean verdict off a failed read, because a false "all clear" before an offline servicing run is worse than no check at all.

You can find it at Windows-11-Scripts/servicing-stack-update-vs-lcu-ordering/Get-ServicingStackState.ps1. It runs on Windows PowerShell 5.1 and PowerShell 7, needs no modules beyond the inbox DISM module, and is ASCII-only so a 5.1 host on a non-UTF8 codepage cannot mangle it.

References

Microsoft official

• Servicing stack updates - what an SSU is, what CBS covers, and the February 2021 combined package change.
• Update Windows installation media with Dynamic Update - the 28 task servicing sequence, and the sample scripts that show the servicing stack going in first.
• Checkpoint cumulative updates and the Microsoft Update Catalog - checkpoints, and the WinRE servicing rule.
• Troubleshoot Windows Update Error Code 0x800f0823 - the CBS.log line and the documented cause.
• Fix Windows Update corruptions and installation failures - CBS log paths, the CBS registry hive, and the error code table.
• Win32_QuickFixEngineering class - the documented limits behind Get-HotFix.
• Clean up the WinSxS folder - the StartComponentCleanup scheduled task and its DISM equivalent.
• Event ID 4374 - Package Installations or Removals - the archived CBS event catalogue and the Component Based Servicing Packages key.
• Servicing stack updates (SSU): frequently asked questions - the ordering rule stated as a rule.
• Simplifying on-premises deployment of servicing stack updates - the WSUS and Configuration Manager behaviour.

Community deep-dives

Both of these were fetched and confirmed to be on topic before citing.

One thing to take away

The servicing stack is the only part of Windows that installs itself. That single fact explains the ordering rule, the combined package, the one-way removal, the extra DISM step for WinRE, and the error code that names none of them. Read the stack version before you service an image, and most of this class of failure disappears.