A feature update failed and setupact.log is 547 MB: read setuperr.log first

A feature update fails. Somebody opens CBS.log, finds nothing that looks like an upgrade, and moves on to Get-WindowsUpdateLog. That produces a few hundred thousand lines of ETW trace with no mention of the failure either. Two hours gone, no root cause.

Both files were the wrong file. Windows Setup keeps its own logs, in its own folders, in its own format, and it does not write to either of those places.

And when admins do find the right folder, the next mistake is worse: they open the biggest file in it.

The problem: the failure log is 547 MB and you have twenty minutes

Here is the actual state of C:\Windows\Panther on the Windows 11 Enterprise 25H2 device (build 26200.9168) I used to write this. Fifty-two files, 934.2 MB in total. I sorted by size and took the top of the list.

Two files account for 93 percent of it. setupact.log at 547 MB and MigLog.xml at 321 MB. Notepad will open the first one eventually. Ctrl+F in it will not be a pleasant experience.

And 9,099 bytes down the list is the file that actually names the failure.

By line count the gap is slightly less extreme and slightly more useful, because lines are what you actually read. I counted both with a StreamReader rather than Get-Content, because loading 547 MB into a PowerShell array is its own outage.

Look at the third row for a moment, because it is the one nobody expects. setupact.log contains 2,688,076 lines. Exactly 72 of them are logged at Error level. Everything else is Info (2,544,217) or Warning (6,802). You are hunting 72 needles in a 2.7-million-line haystack, and there is a 63-line file sitting next to it that already did the hunting.

So before any command, three questions need answers.

1. Which phase failed, because that decides which folder holds the relevant log?
2. What is the result code and the extend code, and where can I still recover them?
3. Which of the errors in the file is the one that actually killed the upgrade, as opposed to noise that a successful upgrade would also have produced?

Question three is not rhetorical. I will show you a setuperr.log from a successful upgrade that contains 0x8007042B — the exact result code Microsoft uses in its own failure walkthrough.

Why it happens: Setup has its own logging stack, and it moves

Windows Setup is a different program from Windows Update

A cumulative update is applied by the component-based servicing engine. It logs to CBS.log. A feature update is applied by Windows Setup, which orchestrates CBS as one of several subordinate engines and logs to its own files in its own format. The Windows Update agent's job ends when the payload is on disk and setup.exe is invoked.

That is why CBS.log looks unhelpful during a feature-update failure. It is not that CBS was silent; it is that CBS is one chapter and you are looking for the plot. In my 547 MB setupact.log, 1,302,873 lines carry the CBS tag — nearly half the file. Setup swallowed CBS's logging whole and inlined it. The interesting lines are the other half.

Microsoft documents four phases plus an uninstall phase, with a reboot between each, and each phase has its own failure signature.

The log locations, and why they move

This is the part that sends people to the wrong file. There is no single setupact.log. There are five documented locations, and the one you want depends on which phase failed. Here is Microsoft's table, condensed.

Read the mechanism behind that table and it stops being something to memorise. $Windows.~BT is Setup's working directory on the source OS. While the down-level phase runs, that is where logging goes. If the upgrade completes, the whole thing is migrated into C:\Windows\Panther on the new OS. If it rolls back, a Rollback sibling folder appears.

So the existence and freshness of these folders is itself diagnostic, before you read a single line.

The log entry format, including the field Microsoft does not document

Microsoft documents four elements in a setupact.log or setuperr.log entry: the date and time, the log level (Info, Warning, Error, Fatal Error), the logging component, and the message.

In practice there is a fifth, optional field. A bracketed hex message identifier can appear between the level and the component. Measured on my 50-entry setuperr.log: 16 entries carried one, in the form [0x0808fe]. Any regex you write to parse these files must treat that field as optional, or it will silently mis-assign the component tag on a third of your lines.

Those last two are worth noticing. Apply failed. Last error: 0x00000000 is untagged, and its "last error" is zero. A naive parser reads that as the fatal line and reports a success code as the cause. It is a summary line, not a diagnosis. This is precisely why you anchor on the result code from the phase, not on whatever line happens to say "failed".

The component tags, checked against reality

Microsoft lists nine logging components: CONX, MOUPG, PANTHR, SP, IBSLIB, MIG, DISM, CSI, CBS. It then singles out three: "The logging components SP (setup platform), MIG (migration engine), and CONX (compatibility information) are useful for troubleshooting Windows Setup errors."

I histogrammed all 2,688,076 lines of my setupact.log against that list. All nine are real and all nine are present.

Microsoft's list is accurate. It is also incomplete. Four more tags appear in real volume and are not in the documented nine.

The binaries that write these lines

Tags are not abstractions. Each one is a component with a file on disk, and knowing which file lets you check versions when a phase misbehaves. Everything below I verified on the device rather than assumed.

Result codes and extend codes

An unsuccessful Setup returns two codes, and you need both. A result code, corresponding to a Win32 or NTSTATUS error, and an extend code carrying "information about both the phase in which an error occurred, and the operation that was being performed". They are reported as a pair, for example 0xC1900101 - 0x4000D.

The extend code decodes positionally: first digit is the phase, last two digits are the operation.

The operation is the low byte, from a documented list of 33 values. 0D is SP_EXECUTION_OP_MIGRATE_DATA, 0C is SP_EXECUTION_OP_APPLY_IMAGE, 07 is SP_EXECUTION_OP_INSTALL_DRIVERS, 02 is SP_EXECUTION_OP_DOWNLOAD_UPDATES. Microsoft's worked example: "An extend code of 0x4000D, represents a problem during phase 4 (0x4) with data migration (000D)."

How to verify: a triage order that starts at 9 KB

Here is the order. Each step is cheap, each step narrows the next, and nothing in it modifies the machine.

Step 1 — Establish the phase before you open any log

Test for the folders. This takes a second and tells you which of five setupact.log files matters.

That output is a diagnosis on its own. Down-level logs present, no rollback folder, and a $Windows.~BT tree stripped of everything except the log folders. Setup failed early, and Windows deliberately preserved the evidence while reclaiming the space.

Step 2 — Recover the result and extend code, from whichever source still has it

There are three documented places the code pair lives, and they decay at different rates. Try them in this order.

2a. The Windows Error Reporting event. Microsoft documents that when Setup fails, the result code and extend code "are recorded as an informational event in the Application log by Windows Error Reporting as event 1001. The event name is WinSetupDiag02." Ten parameters are listed; P5 is the result error code and P6 the extend error code.

Microsoft's own caveat on this route is easy to miss: "The following Event logs are only available if Windows was updated from a previous version of Windows to a new version of Windows." And there is a second, harsher limit that nobody documents — the Application log rolls.

2b. The SetupDiag registry key. This is the route that survived. A 20 MB circular event log wraps in weeks; a registry value does not.

2c. The log itself. If both of the above are gone, setupact.log records the code pair in plain text as Setup hands it to WER and to Windows Update. On my device the down-level log contains all three of these, and they agree.

Step 3 — Read setuperr.log end to end. All of it.

This is the step that does not exist in most people's process, because they have never noticed the file. It takes thirty seconds and it usually ends the investigation.

Microsoft's documented procedure is ten steps. Compressed, with the reasoning that makes each one make sense:

1. Get the Setup error code (step 2 above).
2. Use the extend code's phase digit to pick the folder.
3. Open the log in a text editor.
4. Search for the result code and find the last occurrence. Microsoft spells out the mechanics: go to the bottom of the file, then Find with Direction set to Up.
5. From that last occurrence, "scroll up a few lines from this location in the file and review the processes that failed before generating the result code".
6. Search for two specific strings: Shell application requested abort and Abandoning apply due to error for object.
7. Decode the Win32 errors in that region.
8. Write down the timestamps.
9. Search the other logs at those timestamps.

Step 4 is the one that matters most, and it is the opposite of instinct. You do not want the first error. Microsoft states it plainly in the SetupDiag documentation: "When SetupDiag indicates that there were multiple failures, the last failure in the log file is typically the fatal error, not the first one."

The reason is architectural. Setup unwinds. A failure deep in a migration plug-in propagates upward through the operation queue, and each layer logs the same code on its way out. The outermost frame is the last line written and the one that describes what Setup actually gave up on.

Step 4 — Only now open setupact.log, at the timestamp you already have

By this point you have a phase, a code pair, a component tag and a timestamp accurate to the second. That turns 2,688,076 lines into a twenty-line window. Open the big file, jump to that second, read the Info lines either side of it. The Info lines are where the context lives — which object, which plug-in, which registry hive.

The fix: anchor on the last result code, then widen

The fix in this post is a reading order, not a repair. That is deliberate. Every repair for a feature-update failure — remove the driver, delete the profile, uninstall the agent, free the disk — depends entirely on which one it is, and the logs are how you find out. Guessing the repair is how a two-hour job becomes a two-week one.

What setuperr.log leaves out, exactly

Before you trust the small file, you should know its blind spots. So I diffed them: every Error-level entry in setupact.log, checked for presence in setuperr.log.

The filter is not "level equals Error". Twenty-two entries were dropped, and every single one of them was DISM-tagged. Here is what they were.

So setuperr.log is a curated view, not a mechanical grep for the word "Error". On this device the curation was correct: it kept every SP, MIG, CONX, MOUPG and DU entry — including all three of the tags Microsoft names as the useful ones — and discarded a repetitive DISM provider channel that had nothing to do with the outcome.

Which log answers which question

This is the table I wish I had had the first time. It is the routing layer between a symptom and a file.

Decoding the codes you find

Microsoft's rule: first hex digit 8 means a Win32 error code, C means an NTSTATUS value; take the last four digits and look them up. In practice certutil -error does that lookup for you — for some families. I measured which.

That last point deserves emphasis. 0xC1900101 is the single most-searched Windows upgrade code and certutil cannot say a word about it. Microsoft documents it directly instead: "A result code of 0xC1900101 is generic and indicates that a rollback occurred. In most cases, the cause is a driver compatibility issue." The instruction is to analyse the extend code to find the phase — which brings you straight back to picking the right folder.

Proof it worked: two setuperr.log files from one device

Everything so far is documentation plus measurement. Now the two cases that make the argument, both from the same machine.

Case A — the failure, in 21 lines

C:\$Windows.~BT\Sources\Panther on my device holds logs from 2025-05-14. That is fifteen months after the successful upgrade whose logs sit in C:\Windows\Panther. Two different events, two different folders, and the small folder is the failure.

An admin investigating the May failure who opens C:\Windows\Panther\setupact.log — the obvious file, the biggest file, the one every article names — is reading 547 MB about a successful upgrade from two months earlier. Meanwhile the failure is fully described in a 2,666-byte file in a hidden folder.

Here is that file, essentially complete.

This is what "the last failure is typically the fatal error" looks like in the wild. Twenty-one lines, one component tag, and a single result code propagating up a call stack from OnCancel to CSetupHost::Execute. The last line is the outermost frame and confirms what Setup surfaced. The useful lines are the two named ones in the middle: CDlpActionDU::ExecuteDUSetup tells you it died in Dynamic Update, and CSetupManager::ExecuteDownlevelMode tells you the phase in plain English.

Note also that not every line carries the same code. Two lines report 0x8007139F (ERROR_INVALID_STATE) and two report the undecodable 0xC1800104 / 0xC180010A. If you had anchored on the first error, or on whichever error looked most exotic, you would have chased the wrong one. Anchoring on the last occurrence of the code the phase reported keeps you honest.

SetupDiag had already answered it, on disk, unprompted

And then the part that reframes the whole exercise. Setup ran SetupDiag itself when this failed, fifteen months ago, and left the answer in the registry and in a 1,081-byte XML file.

Three independent artefacts, in agreement: the registry key, the XML file, and the log line SetupHost: Reporting error event -> [0x800704C7, 0x40004]. All three say 0x800704C7 - 0x40004. And C:\Windows\Logs\Mosetup\BlueBox.log is timestamped 2025-05-14 11:24:44 — the same 27-second window, the documented log for the setup.exe-to-Windows-Update conversation, sitting there ready for the next question.

Case B — the success that contains a textbook failure code

Now the other file, and the reason you must never treat "errors present" as "upgrade failed".

The 63-line setuperr.log in C:\Windows\Panther is from an upgrade that completed successfully. It contains 0x8007042B — the exact result code Microsoft uses in its own worked failure example on the log-files page.

How do I know it succeeded? Because of what happened after that timestamp.

Setup hit an access-denied writing a security agent's HKCU key during offline migration, logged it with both of Microsoft's canonical abort strings and a genuinely fatal-looking result code, then carried on and completed. The migration engine is designed to tolerate that. A single object failing to apply is not a failed upgrade.

Which is exactly why the procedure says to find the last occurrence of the result code Setup actually reported — not the last scary line in the file. Without a code from step 2, 0x8007042B at 16:48:50 looks like your answer. With one, you know there is no failure to explain.

The full component histogram of a 63-line file

One last measurement, because it closes the loop on the tag documentation. Here is the complete component breakdown of the successful upgrade's setuperr.log — all 50 timestamped entries.

Microsoft says SP, MIG and CONX are the three that matter for troubleshooting Windows Setup errors. On a real device, those three are 46 of 50 entries — 92 percent of the error log. The documentation is not being vague. It is telling you precisely where to look.

The whole thing, as a runbook

1. Do not retry. Copy C:\$Windows.~BT, C:\Windows\Panther and C:\Windows\Logs\Mosetup somewhere safe first.
2. Check which phase folders exist. No Rollback folder means it never got that far.
3. Read HKLM\SYSTEM\Setup\SetupDiag\Results. Setup may have diagnosed it for you already.
4. If that is empty, look for Application event 1001 named WinSetupDiag02 and read P5 and P6. If the log has rolled, grep setupact.log for Reporting error event.
5. Use the extend code's first digit to pick the folder — then let the log's own phase text overrule the table.
6. Get-Item every setuperr.log in every phase folder. Zero bytes eliminates a phase for free.
7. Read the non-empty setuperr.log end to end. It is measured in tens of lines.
8. Find the last occurrence of the result code from step 4. Look for Shell application requested abort and Abandoning apply due to error for object.
9. Decode the Win32 codes with certutil -error. Expect it to fail on 0xC18xxxxx and 0xC19xxxxx; use the documented tables for those.
10. Take the timestamp into setupact.log and read the Info lines either side. That is where the object, plug-in or hive is named.
11. Only now widen: miglog.xml for MIG failures, BlueBox.log for payload and WSUS problems, setupapi.dev.log for drivers, CBS.log at the same timestamp for servicing.
12. Only now decide on a fix.

Twelve steps, and the first ten are read-only. The 547 MB file does not get opened until step 10, and by then you know exactly which second of it you need.

References

• Log files and resolving upgrade errors — the per-phase log location table, setupact.log versus setuperr.log, the log entry structure and component list, and the ten-step "Analyze log files" procedure including the last-occurrence search and the two abort strings.
• SetupDiag — "the last failure in the log file is typically the fatal error, not the first one", the automatic-invocation parameters and registry path, the offline log folders to copy, and the full rule catalogue including FindAbruptDownlevelFailure.
• Upgrade error codes — result codes versus extend codes, the phase and operation tables, the 1607 versioning caveat, and the 0xC1900101 guidance.
• Troubleshooting upgrade errors — the four phases plus uninstall, the failure character of each phase, the SetupProgress volatile registry key, and "Use the SetupDiag tool before you begin manually troubleshooting".
• Windows Error Reporting — Application log event 1001, event name WinSetupDiag02, and the P1–P10 parameter table where P5 is the result code and P6 the extend code.
• Resolve Windows upgrade errors — the index for this whole section, with the 100 to 400 level ordering that makes a sensible escalation path.
• Win32 error codes (MS-ERREF) — the lookup table behind ERROR_CANCELLED, ERROR_PROCESS_ABORTED, ERROR_FILE_CORRUPT and the rest.

All measurements in this article were taken read-only from a live Windows 11 Enterprise 25H2 device, build 26200.9168, on 23 August 2026. No log file was modified, and no repair action was performed. File sizes, line counts, component histograms and registry values were re-measured for this article rather than quoted from memory.