0xC1900101 is not one error: the extend code after it names the phase that killed your feature update

A feature update fails on eleven machines overnight. Every one of them reports the same thing: 0xC1900101. So you do what everybody does. You tell the user to unplug their dock, you get approval to disable the endpoint agent, and you queue the update again. Four of them work. Seven fail again.

You have learned nothing, because you never read the second half of the error.

0xC1900101 is not the error. Microsoft's own words are blunt about it: "A result code of 0xC1900101 is generic and indicates that a rollback occurred." Generic. It tells you Windows Setup gave up and put the old OS back. It does not tell you where, when, or why. That information lives in a completely separate number that Setup returns alongside it, and most reporting surfaces throw it away.

The problem: one code, nine documented root causes

Microsoft documents nine distinct 0xC1900101 pairs, each with its own cause and its own mitigation. They are not variations on a theme. One is a recovery-environment build failure. One is a WIM apply failure. One is a display driver hanging during data migration. One is a filter driver from a virtualisation agent blocking disk writes. The remediation for those four has almost nothing in common - yet if your reporting captured only the result code, all four look identical on your dashboard.

Why the extend code goes missing

Setup returns both codes, but not every consumer of that data keeps both. Microsoft calls this out directly on the error codes page: "If only a result code is returned, this can be because a tool is being used that was not able to capture the extend code."

So the first diagnostic act is not troubleshooting at all. It is recovery of a number you were supposed to have been given. The documented place to find it is the Application event log, where Windows Error Reporting writes an informational event 1001 named WinSetupDiag02.

That absence is itself a diagnostic result, and a useful one. Microsoft documents that "Devices updating from Windows 11, version 24H2 use an enablement package" - a small switch that activates dormant features rather than swapping the OS. An enablement package is a servicing operation. It has no downlevel phase, no WinPE pass and no second boot, so it cannot produce a setup phase code.

The reflex that destroys the evidence

The standard advice for 0xC1900101 is to uninstall antivirus, disconnect every peripheral, and clean boot. Microsoft does publish those steps and they often work. But look at what a clean boot does: it changes the loaded driver set wholesale. If the update then succeeds, you know only that something in the difference was responsible - not what. Next month the same driver ships to the same fleet and you start over, because you never wrote down a filename.

Why it happens: the extend code is a phase plus an operation

Windows Setup does not perform an upgrade in one pass. It runs four phases, with a reboot between each, and Microsoft states that "Progress is tracked in the registry during the upgrade process" using a volatile key that exists only while the upgrade is running.

Each phase runs in a different environment, with a different set of drivers loaded. That is the whole reason the phase digit is diagnostic: it tells you which driver environment was live when the wheels came off.

What 0xC1900101 actually is

The result code has a name. In Microsoft's modern setup error table, 0xC1900101 is listed as MOSETUP_E_SETUP_PLATFORM, described as "The Setup Platform has encountered an unspecified error." That is a component reporting its own failure to continue, not a description of a fault.

Splitting the extend code

Microsoft's decoding rule has exactly three steps: use the first digit for the phase, use the last two digits for the operation, and match both against the published tables.

That is the entire trick. And it is checkable: Microsoft's rollback guidance says separately that "The device install log is helpful if rollback occurs during the sysprep operation (extend code 0x30018)". The arithmetic and the prose agree.

The phase table

These are the six documented phase values. The fourth column is Microsoft's own list of example extend codes seen in each phase, which is a useful sanity check on your decode.

Note the naming collision, because it will confuse you when you cross-reference Microsoft's own pages. Phase 4 is SP_EXECUTION_OOBE_BOOT in the constants table, but the resolution procedures article calls it "the second boot phase". The troubleshooting article reconciles them explicitly: "Second boot phase: Final settings are applied. This is also called the OOBE boot phase." Same phase, two names.

There is also a hard rule buried in the docs that saves time. Microsoft states 0xC1900101 "can be thrown at any stage of the upgrade process, with the exception of the downlevel phase." So a reported pair of 0xC1900101 - 0x1xxxx is self-contradictory. If you see one, distrust the capture rather than the machine.

The operation table

The last two digits identify what Setup was doing. This is the full published list.

How to verify: recover the pair, then name the driver

Here is the order. Each step either produces the answer or narrows the next step. Nothing here changes the machine.

Step 1 to 3: recover the code pair

1. Read the SetupDiag result from the registry. Windows Setup runs SetupDiag automatically when an upgrade fails, and Microsoft documents the exact parameters it uses, including /RegPath:HKEY_LOCAL_MACHINE\SYSTEM\Setup\SetupDiag\Results. That key is the fastest read on the box and it is remotely queryable, which makes it the right first move across a fleet.

Here is that key read on my own device. It is a real record, and it is a worked example of why you check DateTime first.

Four independent signals in one key all say the same thing, and none of them is "driver". Had I skipped straight to the extend code and decoded phase 4, I would have gone looking for a filter driver in the second boot phase and found nothing, because there was nothing to find.

2. Cross-check the Application log. The event is the authoritative record of the pair as Setup reported it.

The parameter positions matter, because the raw event data is an unlabelled list of ten strings.

P4 is worth a second look. If it reads 2 (Cancel), you are not chasing a driver, whatever P5 says. That single field would have short-circuited the stale record above.

3. If both are empty, run SetupDiag yourself. Microsoft ships it inside Windows Setup, extracted to %SystemDrive%\$Windows.~bt\Sources during the upgrade, and recommends downloading the current build for manual runs. Note that when you run it by hand without /RegPath, results land at HKLM\SYSTEM\Setup\MoSetup\Volatile\SetupDiag - a different key from the automatic one. Two keys, two provenances; do not read one and think you are seeing the other.

Step 4 to 6: turn the phase into a log, and the log into a filename

4. Let the phase choose the log. This is the payoff of decoding. Microsoft's log table is indexed by phase, and says so plainly: "The log files are located in a different folder depending on the Windows Setup phase. Recall that the phase can be determined from the extend code."

5. Read setuperr.log, not setupact.log. Both files exist in the same folder. One of them is readable.

6. Find the last occurrence, not the first. Microsoft's documented procedure is specific about direction: search for the result code, then "find the last occurrence of the code", searching upward from the bottom of the file. Then look for two exact strings: Shell application requested abort and Abandoning apply due to error for object. SetupDiag's own documentation carries the same warning: "When SetupDiag indicates that there were multiple failures, the last failure in the log file is typically the fatal error, not the first one."

Here is why that discipline is not optional. This is real content from that 9 KB setuperr.log, from a device that upgraded successfully.

Step 7 to 8: name the driver

7. For a device install failure, open setupapi.dev.log. This is where a driver stops being a category and becomes a file. Microsoft's published example ends with the exact marker you are looking for.

8. If it bug-checked, get the stop code. For a 0x4000D failure, Microsoft's instruction is to look for setupmem.dmp and "Review the rollback log and determine the stop code", and it publishes a sample crash block showing Crash 0x0000007E detected with four bugcheck parameters. SetupDiag can debug that dump for you if the Windows Debugging Tools are installed and you pass /LogsPath, since memory dumps cannot be debugged in online mode.

The binaries and files in this path

Knowing where these actually live saves a detection script that silently never fires.

The fix: what each phase actually tells you to do

Now the extend code earns its keep. Each documented pair carries its own cause and its own first move, and they are not interchangeable.

Read down the "decodes to" column and the pattern is the point. Phase 2 failures are WinPE-environment problems - storage stacks, disk encryption filters, firmware. Phase 3 failures are the new OS meeting your hardware for the first time - device and display drivers. Phase 4 failures are filter drivers and security agents now loaded under the new kernel.

That is the inference the extend code buys you. 0x20017 and 0x40017 are the same operation - BOOT - in two different phases, pointing at two entirely different families of software. Disabling your antivirus is reasonable for 0x40017. It is close to irrelevant for 0x20017, where the antivirus filter driver is not even loaded yet.

The one thing to do before any of it

Harvest first. Copy the whole folder, then remediate. Microsoft's guidance for offline SetupDiag analysis is to copy one of \$Windows.~bt\sources\panther, \$Windows.~bt\Sources\Rollback, \Windows\Panther or \Windows\Panther\NewOS, and notes that if you copy the parent folder and all subfolders, SetupDiag searches every subdirectory itself. That is a one-command capture that survives every retry the user makes while you are still reading.

Proof it worked: real setup artefacts from a live device

Everything below was read from one live Windows 11 25H2 corporate device, build 26200.9168, read-only. It shows what the diagnostic surface looks like on a machine that is currently healthy - which is exactly what you need to recognise the abnormal.

The setupdiagresults.xml file on disk carried the same failure as the registry key, byte for byte in substance: <FailureDetails>ErrorCode = 0x800704C7, ExCode = 0x40004</FailureDetails>, matched by rule FindAbruptDownlevelFailure. Microsoft documents both destinations for the same run, and having the pair agree is how you confirm you are reading a genuine record rather than a leftover.

Three findings from this device are worth carrying into your own environment.

The stale record is real and it is dangerous. A May 2025 SetupDiag result was still sitting in the registry in August 2026 - fifteen months and one whole feature release later. Nothing cleared it. Fleet reporting that reads HKLM\SYSTEM\Setup\SetupDiag\Results without filtering on DateTime will raise tickets for upgrades that failed over a year ago and have long since been superseded.

A successful upgrade leaves 63 error lines behind. The setuperr.log from the March 2025 run sits in the post-upgrade location, meaning that run completed - and it still holds fifteen SP errors, including 0x8007042B, the very code Microsoft uses in its own documented failure walkthrough. Error lines are not evidence. The last occurrence of your specific result code is evidence.

Log sizes decide your method. setupact.log at 547 MB and miglog.xml at 321 MB are not files you open and read. setuperr.log at 9 KB is. A runbook that says "review setupact.log" without giving a search string is one nobody will follow at 2am.

References

• Windows upgrade error codes - the result code versus extend code split, the three-step decoding rule, and the complete phase and operation tables reproduced above.
• Windows upgrade resolution procedures - the 0xC1900101 section with every documented variant, cause and mitigation, plus the modern setup (mosetup) error table where MOSETUP_E_SETUP_PLATFORM is defined.
• Log files and resolving upgrade errors - the phase-indexed log location table, the log entry structure and component tags, the last-occurrence search procedure, and the worked setupapi.dev.log example.
• Windows error reporting - Application log event 1001, the WinSetupDiag02 event name, and the P1 to P10 parameter map.
• SetupDiag - the automatic run parameters, both registry destinations, the full published rules table, and the setup bug check analysis procedure.
• Windows upgrade issues troubleshooting - what each of the four phases does, the example extend codes per phase, and the volatile SetupProgress registry key.
• Resolve Windows upgrade errors - the hub article and the 100 to 400 level map of this whole documentation set.
• Windows Setup Log Files and Event Logs - the %WINDIR%\Panther and %WINDIR%\Inf\Setupapi*.log locations, and how to open setup.etl.
• System Error Codes (1000-1299) - ERROR_CANCELLED, 1223 (0x4C7), "The operation was canceled by the user."
• What's new in Windows 11, version 25H2 - the enablement package delivery path for devices already on 24H2, and why those devices produce no setup phase codes.