## TL;DR
Retrying a cumulative update against the same corrupt cached download just replays the same failure. Teach the agent a retry ladder: first failure retries as-is once, second failure clears the Windows Update download cache and forces a fresh download, third failure runs DISM and SFC health checks before any further attempt, and a defined maximum stops the loop and escalates. Log which ladder step each attempt used so the pattern is visible instead of a wall of identical failures.

```text
agent retried failed cumulative update without clearing windows update cache and looped
```

## Use this when
- The agent has retried the same cumulative update on a host several times with the same error code and similar short durations.
- Each retry fails at the same stage, suggesting the same cached payload or state is reused.
- Manual cache clearing on a similar host made the same update install successfully.

## Not for this skill when
- The failure code is a component store corruption code. Go straight to DISM repair; cache clearing will not help.
- The update fails on every host in the fleet identically. That is a package or source problem, not per-host cache.

## Steps
1. Stop the current loop and preserve its evidence: pause retries for the host, and export the attempt history with error codes, durations, and stages. Identical code plus identical quick duration is the fingerprint of a replayed corrupt cache, while varying results suggest a different cause you should not cache-clear blindly. Verify: retries are paused and the attempt fingerprint is documented before any state is cleared
2. Perform the manual recovery once, end to end, to prove the ladder works on this failure class: stop the update services, rename the SoftwareDistribution download folder, restart services, run a fresh download and install, and if it still fails, run DISM RestoreHealth and SFC before the next attempt. Note which step actually unlocked the install. Verify: the update installs manually, and you know whether cache clearing or store repair was the step that fixed it
3. Encode the ladder in the agent with explicit attempt classes: attempt one is a plain retry, attempt two is cache clear plus fresh download, attempt three is store health check and repair then install, and there is no attempt four - the host is parked as blocked with its full history attached for a human. Each attempt records its class in the run log. Verify: a code review or test run shows the ladder classes in the agent logic and in the logs it produces
4. Add loop detection independent of the ladder: if the agent sees the same host, same update, and same error code beyond the ladder limit across any time window, or sees total elapsed retry time exceed a threshold, it stops and alerts instead of continuing quietly in the background. This catches ladder resets caused by agent restarts. Verify: a simulated repeated failure triggers the loop alert and the host is parked rather than retried indefinitely
5. Roll the ladder out and measure: enable it for one wave, then compare first-attempt, post-cache-clear, and post-repair success rates across hosts. Those rates tell you which failure class dominates your fleet and whether an upstream fix, such as download source health, deserves attention next. Verify: one wave completes under the ladder with per-class success rates reported and no host looping beyond the limit

## Why it happens
A failed cumulative update leaves state behind: partial downloads, a datastore record of the attempt, and sometimes a damaged payload that the client will reuse because resuming is cheaper than restarting. A naive agent retry treats the install as a pure function and runs it again against that same state, so it fails the same way quickly, forever, while consuming windows and masking the signal in noise. Human engineers instinctively escalate their retries - retry, clear cache, repair store, investigate. Encoding that escalation as an explicit ladder with a hard stop gives the agent the same judgment and guarantees every loop terminates in either success or a human-readable blocked state.

## Variants and edge cases
### Loop is on the download stage, not install
The ladder should clear the BITS job as well as the download folder for download-stage codes, since a wedged transfer job survives a folder rename in some cases.

### Agent restarts reset its attempt counting
Persist attempt history in the tracker outside the agent process, keyed by host and update, so a restarted agent resumes the ladder where it left off instead of starting a fresh infinite loop.

### Cache clearing is disruptive on shared or metered hosts
Gate the cache-clear step to approved windows for hosts where a full re-download is expensive, and park the host for a window rather than clearing immediately.

Compatibility: Applies to patch agents managing Windows Update on Windows 10, Windows 11, and Windows Server, with equivalent cache concepts for WSUS and Configuration Manager clients.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hihr6jRZ6co_Y51bR-P8Kw