"We couldn't complete the updates, undoing changes": reconstructing a rollback from what it leaves behind

"We couldn't complete the updates. Undoing changes. Don't turn off your computer." It is the politest failure message Windows produces, and operationally it is the worst one, because it hands the user nothing to write down. No code, no KB number, no log path. Just a progress screen that counts backwards.

The user waits, the device returns to the build it was already on, and the ticket that lands in your queue says update failed, rolled back. That is the entire technical content of it.

So the reflex is to redeploy and hope. That reflex is why the same device fails a second time in exactly the same way, on exactly the same night, and appears in the same report the following month.

A rollback is not a black box. It is a documented exit path that writes a specific set of files, in specific directories, and posts a specific event carrying the error code the user never saw. This post is about reconstructing what happened from those artefacts — after the fact, on a device that now looks perfectly healthy.

The problem: a friendly sentence, a reverted device, and a ticket with no error code

The message is not an error dialog. It is a progress screen shown by a process that has already decided to reverse itself, and progress screens do not carry error codes. That is not an oversight; the code exists, it is simply written somewhere the user is never shown.

What makes this failure genuinely hard is that the same sentence is produced by two mechanisms that share almost no diagnostic surface.

The first is Component-Based Servicing. A monthly cumulative update stages its payload while Windows runs, then defers the operations it cannot perform against files in use to the next boot. If that boot-time transaction cannot be committed, the servicing stack reverses it and Windows comes up on the old revision. Nothing about Windows Setup is involved.

The second is Windows Setup. Anything that changes the build — a feature update, an enablement package promotion, an in-place repair install — runs the setup platform through four phases, and setup has a rollback branch it can take at almost any point after the first reboot.

Both end with a reverted device and a user who saw the word "undoing". They do not end with the same files on disk. Deciding which one you are holding is the whole first step, and it is the step that gets skipped.

The second difficulty is time. By the time the ticket reaches you the device has been running normally for days, and every live check you can think of — service states, pending-reboot markers, component-store health — comes back clean, because it is clean. The device really is fine. It is fine at the version it was already on.

So you are not troubleshooting a broken machine. You are reconstructing an event from residue, which means the goal is not "find the fault" but something more specific.

You need four facts, and they are the same four facts every time:

1. When did it start. The moment the attempt began, not the moment the user noticed.
2. Which phase did it reach. The furthest point it got before turning around.
3. When did it revert. The moment the rollback branch was taken, and how long it took.
4. What was the code. The result and extend pair the user never saw.

With those four you have a root cause candidate and a defensible next action. Without them you have a retry.

Why it happens: the rollback is a planned branch, not a crash

The most useful thing to understand about a setup rollback is that it is prepared in advance. Microsoft's description of the SafeOS phase is explicit about it: a recovery partition is configured, Windows files are expanded, updates are installed, and "an OS rollback is prepared if needed".

In operational terms: before setup ever risks the boot that could fail, it has already built the road back. There is a dedicated operation code for it — SP_EXECUTION_OP_PREPARE_ROLLBACK, operation 09 in the extend-code table. Which is why a rollback produces tidy evidence rather than wreckage: setup is not improvising after a disaster, it is executing a branch it provisioned earlier, and that branch includes writing its own log directory.

Phase names and the prepare-rollback operation are from Microsoft's documented phase and extend-code tables. The rollback directory is the documented location of the rollback-phase log set.

The extend code is the part practitioners under-use. An upgrade failure returns two codes, and Microsoft documents how to decompose the second one: the first digit is the phase, the last two are the operation. An extend code of 0x4000D is therefore phase 4 (SP_EXECUTION_OOBE_BOOT) during operation 0D (SP_EXECUTION_OP_MIGRATE_DATA).

That single value answers question two on your list before you open a log at all.

On the servicing side the mechanism is different but the logic is the same: a transaction that could not be closed gets reversed. Microsoft's own corruption-error table contains the code that describes it almost literally — 0x8007371B, ERROR_SXS_TRANSACTION_CLOSURE_INCOMPLETE, "One or more required members of the transaction are not present".

Now the part that explains the identical second failure. A rollback restores the operating system; it does not remove the reason the operating system could not be replaced. If the cause was a filter driver, the filter driver is still loaded. If it was a corrupt profile object, the object is still on disk. Setup will reach the same phase, hit the same object, and take the same prepared branch.

Worse, the retry can fail differently, which sends people chasing the wrong thing. Microsoft documents two result codes specifically for this state: 0xC1900107 (MOSETUP_E_CLEANUP_PENDING, "A cleanup operation from a previous installation attempt is still pending. A system reboot is required") and 0xC1900216 (MOSETUP_E_ROLLBACK_PENDING, "Found pending OS rollback operation"). Neither is the original fault. Both are the residue of the attempt you did not diagnose.

How to verify: build the timeline before you touch anything

Everything below is read-only until the final step. That ordering is not fussiness — the standard remediation reflexes for this symptom are unusually good at destroying the only copy of the evidence.

Step 1 — Decide which mechanism you are looking at

Read the build identity. If the installed build and revision are unchanged from before the maintenance window, and the KB in question was a cumulative update, you are on the servicing path and there will be no $Windows.~BT\Sources\Rollback to find. If the release changed, or was meant to, you are on the setup path.

Step 2 — Read the Setup event log and pin the servicing timeline

The Setup channel is where the servicing stack records each package state transition, and Microsoft's update-corruption guidance points at it directly: "You can check the Setup event log for errors." It is the cheapest timeline you will get, because every record carries a timestamp and a package identity.

Provenance, stated plainly: Microsoft publishes no event-ID catalog for the Microsoft-Windows-Servicing provider. There is no Learn page listing these IDs and their messages. Every semantic in the table above was read off a real Windows 11 25H2 device (build 26200.9168) in this lab, or inferred from its position in an observed sequence — Event 1's exact string is described rather than quoted for exactly that reason. Treat the IDs as reliable and the wording as version-dependent, and always read the state name in the message body rather than trusting the ID alone. What is documented by Microsoft is that the Setup event log is the place to look.

Note what you have now: the start time (Event 1), the point it reached (Event 4, deferred to boot), and a hard fact about the outcome (no Installed transition). Three of your four facts, from one log, on a device that looks healthy.

Step 3 — Recover the error code the user never saw

This is the step almost nobody does, and it is the one that turns a codeless ticket into a diagnosable one. When Windows Setup fails, Microsoft documents that the result code and extend code are recorded as an informational event in the Application log by Windows Error Reporting, as event 1001 with the event name WinSetupDiag02.

Microsoft's Windows Error Reporting article documents all ten parameters, and notes the legacy event name was WinSetupDiag01. It also warns that these event logs are only present if Windows was actually updated from one version to another.

Step 4 — Collect the rollback log set, then analyse it offline

Now go to disk. The rollback phase has its own directory, and Microsoft's log-file table is unambiguous about what belongs where. Copy the tree off the device before you read it — a copy is a preserved exhibit, a live read is one Disk Cleanup away from gone.

Then let the tool read it. SetupDiag.exe ships with Windows Setup in all currently supported versions of Windows; setup extracts it to %SystemDrive%\$Windows.~bt\Sources, and if the upgrade has a problem, SetupDiag runs automatically. When setup invokes it, the documented parameters are /ZipLogs:False /Format:xml /Output:%windir%\logs\SetupDiag\SetupDiagResults.xml /RegPath:HKEY_LOCAL_MACHINE\SYSTEM\Setup\SetupDiag\Results.

Which means the analysis may already be sitting on the device, in a file nobody opened.

Three other documented rules matter here. FindDebugInfoFromRollbackLog extracts bug-check detail from a rollback log without needing a debugger package installed. DebugSetupMemoryDump handles setupmem.dmp when the Windows Debugging Tools are present — and Microsoft is clear that memory dumps cannot be debugged in online mode, so this is an offline-only path. FindSuccessfulUpgrade exists too, which is a useful reminder that SetupDiag will also tell you the attempt worked.

Step 5 — Read the rollback log the way Microsoft says to read it

Microsoft's documented procedure is specific, and it is worth following literally: find the last occurrence of the result code in the file, then read upwards. SetupDiag's documentation makes the same point in stronger terms — when multiple failures are reported, the last failure is typically the fatal one, not the first.

Two search strings are documented as high-value: Shell application requested abort and Abandoning apply due to error for object. Both mark the moment setup gave up on a specific object, and both sit next to the object's name.

Log lines carry a component tag, and the useful ones are documented too: SP (setup platform), MIG (migration engine) and CONX (compatibility information), alongside PANTHR, IBSLIB, MOUPG, DISM, CSI and CBS. A rollback narrated by MIG is a data-migration problem; one narrated by SP around a crash is a driver problem.

That last line is the one to internalise. The splash window is logged as an event in setup's own narrative, which means the user-visible message has a timestamp you can pin. Subtract it from Event 1 in the Setup channel and you have the duration of the whole attempt, which is your fourth timeline fact and often the tell for a timeout rather than a fault.

Step 6 — Correlate against the servicing events

Now put the two logs side by side. This is the step that converts artefacts into a narrative you can put in a ticket.

Worked example, assembled from the documented fields and the real observed event sequence. The clock values are illustrative; the sources, event IDs and record types are the ones you will actually be reading.

Notice that no step above required the device to be in a failed state, and no step required a change to the machine. That is what makes it repeatable across a fleet.

The fix: what the rollback undid, and what it left exactly as it was

Before choosing an action, be precise about what the rollback actually accomplished, because the gap between what people assume and what is documented is where the second failure lives.

What it undid: the operating system. The device is back on the previous build and revision, bootable, and serviceable. On the setup path that reversal was pre-provisioned in SafeOS; on the servicing path the transaction was reversed and the old component versions remain current. Verify it rather than assume it — CurrentBuild and UBR are two registry reads away.

What it did not undo:

• The cause. The driver, filter driver, encryption product, corrupt profile object or bad driver package that stopped the upgrade is untouched. This is the whole reason retries reproduce.
• The pending state. Microsoft documents 0xC1900107 (cleanup from a previous attempt still pending, reboot required) and 0xC1900216 (pending OS rollback operation found) precisely because state survives.
• The disk condition. If the attempt failed on space, the residue of the attempt has made the space problem worse, not better.
• The evidence. Which is good news, briefly. The logs are still there — until someone runs a cleanup.

So the fix is never "roll back, retry". It is: read the extend code, take the documented remediation for that phase and operation, then retry once with the cause removed. Microsoft's resolution table maps several of these directly.

That last row is a nice closing of the loop: the residue of attempt one becomes the documented cause of attempt two.

There is exactly one documented command that reverses pending servicing actions, and its scope is far narrower than its reputation. DISM /Image:<path> /Cleanup-Image /RevertPendingActions is described as a recovery option for a boot failure, reverting all pending actions from previous servicing operations. Microsoft states it is "not supported on a running operating system or a Windows PE or Windows Recovery Environment (Windows RE) image", and that it should be used "only in a system-recovery scenario on a Windows image that did not boot".

Your device booted. It is not a candidate. This is not a button for clearing a rollback you have not diagnosed.

The binaries you are actually reasoning about

Naming the executables correctly is not pedantry — half the bad advice on this symptom comes from people who think one component's log describes another component's work.

One more correction while we are here: C:\Windows\WindowsUpdate.log exists but is a roughly 276-byte stub pointing at Get-WindowsUpdateLog. It is not the real log and never contains rollback detail. The real traces are ETW .etl files under C:\Windows\Logs\WindowsUpdate\ — 99 files totalling 42.5 MB on the lab device.

Proof it worked: the same three places, on a device that finished

The only honest way to close this ticket is to show the successful sequence in the same artefacts you used to characterise the failure. Same channels, same fields, different shape.

First, the Setup channel completes its transition. The failure signature was the absence of a transition to Installed; success is its presence, and the state name is in the message body.

Second, the WER event records a result rather than a reversal: on a completed upgrade the WinSetupDiag02 event carries P4 = 0 (Success) and P2 is not 5. Microsoft's article illustrates exactly this — the sample event it shows is one from a successful upgrade, which is a useful reminder that 1001/WinSetupDiag02 is not an error-only event.

Third, and this is where people go wrong: do not use Get-HotFix as your proof.

That last block is the honest baseline for this whole class of investigation. A device that rolled back last Tuesday, on a fleet where the component store has quietly repaired itself five times over its life, will show Corrupt : 0 and AutoRepairNeeded : 0 today. Those values are not evidence that nothing happened. They are evidence that the mechanisms designed to recover did their job, and that your answer has to come from the timeline, not from a live health check.

Which is the whole argument. A rollback leaves a start time, a phase, a reversal time and a code. Recover those four and "it just rolled back, try again" stops being a plan and becomes what it always was: a decision to fail again on schedule.

References

• Log files and resolving upgrade errors — the log-file table (including the rollback-phase location and supplemental rollback logs), log entry structure and component tags, and the documented procedure for analysing a setup log.
• SetupDiag — automatic execution by Windows Setup, the output and registry paths, the offline folder list including \Windows\Panther\NewOS, setupmem.dmp locations, and the full rule catalogue including FindRollbackFailure.
• Windows error reporting — Application log event 1001, event name WinSetupDiag02, and the ten documented parameters including P2 Setup Mode = 5 (Rollback).
• Upgrade error codes — result codes, extend codes, and the phase and operation tables used to decompose the extend code.
• Upgrade issues troubleshooting — the four phases, what each does, what Microsoft attributes failures in each phase to, and the volatile SetupProgress registry key.
• Upgrade resolution procedures — the 0xC1900101 section, the extend-code mitigation table, the published rollback-log sample, and the mosetup error list containing MOSETUP_E_ROLLBACK_PENDING and MOSETUP_E_CLEANUP_PENDING.
• Fix Windows Update corruptions and installation failures — "You can check the Setup event log for errors", the corruption error-code table including ERROR_SXS_TRANSACTION_CLOSURE_INCOMPLETE, and the CBS log paths.
• DISM operating system package servicing command-line options — /Cleanup-Image /RevertPendingActions and its documented restrictions, and the pending-online-actions limitation.
• Windows Setup log files and event logs — setup log locations and %WINDIR%\Panther\setup.etl, the Windows Setup performance trace that is not the Setup event log.
• Upgrade quick fixes — the basic fix list, and the Disk Cleanup step that removes previous Windows installations.

Device measurements in this post (build 26200.9168, DisplayVersion 25H2, servicing stack 10.0.26100.9156, the ProductName quirk, Setup events 2 and 4 for KB5120708, the Get-HotFix versus package-inventory gap, and the component-store self-repair history) were captured read-only from a live Windows 11 25H2 corporate device. Illustrative timestamps and assembled sample output are labelled as such at the point of use.