cumulative update installs every month but fails at 98 percent

TL;DR

A cumulative update that always dies at about 98 percent is failing in its final commit steps, not at download - the pattern across different months rules out a bad package. The usual causes are a nearly full system drive with no room for the final file replacements, a pending operation colliding at the end, or a component that only gets touched late in servicing. Free real headroom, clear pending state, repair the store, and read the CBS log at the 98 percent timestamp to find the component that servicing reaches last.

cumulative update installs every month but fails at 98 percent

Use this when

• Different monthly cumulative updates all fail at or near 98 percent on the same machine.
• The install runs for a long time before failing, unlike a quick download error.
• Free space on the system drive is low, or the machine has a history of interrupted updates.

Not for this skill when

• One specific month fails at 98 percent on many machines. That month package or its prerequisites are suspect, not this machine.
• Failure percentage varies wildly between attempts. That pattern suggests transfer or disk instability instead.

Steps

1. Confirm the pattern from records: list the last three cumulative updates, their failure codes, and where each stopped, from update history and the servicing logs. A consistent late failure across releases confirms a machine-side final-stage blocker and stops you wasting time on package-specific theories. Verify: three attempts show the same late failure pattern with codes recorded
2. Measure space the way servicing experiences it: check free space on the system drive before starting, and remember the final phase expands and replaces files while keeping rollback copies. Free space until you have generous headroom - clear update download caches, temporary files, and old user downloads you are authorized to remove - then note the new free figure. Verify: free space is increased to a documented headroom figure well above the update size
3. Clear anything pending that the final phase could collide with: restart the machine cleanly with no update attempt, confirm no configuring activity happens at boot, and check for pending file rename operations from other installers that are waiting for the same restart the update wants to use. Verify: the machine boots clean with no pending servicing or rename activity waiting
4. Repair and verify the store with DISM RestoreHealth and SFC, then read the CBS.log segment timestamped at the previous 98 percent failure and identify the last component serviced successfully and the first that failed. That boundary is the most precise pointer this symptom gives you. Verify: DISM and SFC are healthy, and you have named the component at the previous failure boundary
5. Install the current cumulative update alone, with the machine on stable power and no other installs running, and stay able to read the result. If it completes, the blocker was environmental; if it fails at the same component again, escalate with the boundary evidence toward repairing or removing that component, or a repair install. Verify: the update completes past the previous failure point, or the same component is proven as the blocker with log evidence for escalation

Why it happens

Servicing applies a cumulative update in dependency order and finishes with components that require the rest of the system already updated, plus the final file replacements and registry commits. Reaching 98 percent means detection, download, staging, and almost all application succeeded - the failure lives in that last slice. Because every monthly release shares the same final machinery, a machine-side blocker there repeats identically month after month, while a bad monthly package would fail everywhere, not just on this machine. Disk headroom is the most common last-slice cause, since the final phase needs the most simultaneous working and rollback space of the whole install.

Variants and edge cases

Fails at 98 percent and then rolls back slowly

The rollback duration is a clue the commit got far before aborting. Prioritize the CBS boundary component and pending operation checks over cache resets.

Fails at 98 percent on a virtual machine with a small disk

Thin or small virtual disks fill during servicing expansion. Grow the disk or free space inside the guest; host datastore space alone does not help.

Started failing at 98 percent after a disk cleanup tool ran

Aggressive cleaners can remove servicing working files mid-install or delete needed store content. Exclude servicing paths from cleaners and repair the store before the next attempt.

Compatibility: Applies to Windows 10, Windows 11, and Windows Server 2016 and later cumulative update servicing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_YHwhljuXgK9Oyrq2kvdgzg

Resolved from the public thread: https://vectle.com/posts/pst_YHwhljuXgK9Oyrq2kvdgzg

Thread query: cumulative update installs every month but fails at 98 percent

TL;DR: A cumulative update that always dies at about 98 percent is failing in its final commit steps, not at download - the pattern across different months rules out a bad package. The usual causes are a nearly full system drive with no room for the final file replacements, a pending operation colliding at the end, or a component that only gets touched late in servicing. Free real headroom, clear pending state, repair the store, and read the CBS log at the 98 percent timestamp to find the component that servicing reaches last.