0xC1420127 and 0xC1900403: the upgrade rolls back every single attempt

Fix it now

Setup is failing part way through and reverting to the old build, and the two headline codes tell you almost nothing on their own. Read the SetupDiag report first: it names the rule that matched, and that is what decides which of the causes below is yours.

SetupDiag.exe /Output:C:\Temp\SetupDiag.xml /Format:xml
DISM /Cleanup-Mountpoints
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

1. Open the report. SetupDiag also writes to %WinDir%\Logs\SetupDiag\SetupDiagResults.xml and records the same result under HKLM\SYSTEM\Setup\MoSetup\Volatile\SetupDiag when it is run with /AddReg.
2. Read the matched rule name rather than the hex. Rules such as WimMountFailure, WimMountDriverIssue and PreReleaseWimMountDriverFound point at the image mount path; FindAbruptDownlevelFailure and similar rules point elsewhere entirely.
3. If DISM reported corruption and repaired it, retry the upgrade before changing anything else.
4. If the report names a mount driver, uninstall the third-party disk or backup software that installed it, then retry.
5. Retry with dynamic update off so setup uses only the payload on your media: setup.exe /auto upgrade /dynamicupdate disable.

Do not start by reinstalling drivers or clearing SoftwareDistribution. Both are guesses, and SetupDiag will tell you in a minute whether either is relevant.

If that fixed it you can stop here. If not, the next section explains what setup is doing when it gives up, and how to tell the five documented causes apart.

Why it happens

An in-place upgrade is not an installation. Setup builds the new Windows alongside the old one, migrates your accounts, settings and files, and only then switches the machine over. Every phase before that switch is reversible by design, so when anything goes wrong the safe answer is always to put the old build back. That is why the machine looks untouched afterwards and why nothing on screen tells you what happened.

The codes divide into two families. The 0xC19xxxxx values come from the setup platform itself. Microsoft publishes several of them: 0xC1900403 is MOSETUP_E_UA_CORRUPT_PAYLOAD_FILES, the payload files were corrupt; 0xC190011F is MOSETUP_E_PROCESS_CRASHED, the installation process crashed; 0xC1900101 is MOSETUP_E_SETUP_PLATFORM, an unspecified setup platform error that Microsoft treats as the generic rollback code usually caused by an incompatible driver.

0xC1420127 and 0xC1420117 are the other family, and this is the honest part: Microsoft publishes no meaning for either. They circulate with confident explanations attached, usually that an image could not be mounted or dismounted, and no vendor page says that. Treat them as a signal that setup stopped in the image-servicing area, then let SetupDiag name the rule that actually matched.

Full reference

Getting a real diagnosis out of SetupDiag

SetupDiag is the only tool here that turns a rollback into a sentence you can act on. It reads the setup logs, matches them against a set of published rules and names the rule that fired. Run it after the rollback, on the machine that failed, from an elevated prompt.

Without /LogsPath it looks at the local machine’s logs, which is what you want immediately after a rollback. It also drops SetupDiagResults.xml into %WinDir%\Logs\SetupDiag by default, so if someone else ran it before you, the answer may already be on the machine.

Where setup leaves its evidence

Codes that are published, and codes that are not

This matters more than it sounds. Microsoft publishes a table of setup platform errors with constant names against them, and it is worth checking your code against that table before you accept anyone’s explanation. 0xC1900403, 0xC190011F and 0xC1900101 are in it. 0xC1420127 and 0xC1420117 are not, and no other Microsoft page defines them.

The practical consequence is that you should not build a plan around what 0xC1420127 supposedly means. Build it around what SetupDiag matched, what the Panther logs show and which of the causes above your symptoms fit. An undocumented code is a place to start looking, not a diagnosis.

When every cause above has been ruled out

• Free real space on the system volume before retrying. Setup stages the new image and keeps the rollback data at the same time, so a disk that looks adequate at the start can be full at the point it fails.
• Remove any pending servicing operation. A machine with an update part-installed will not upgrade until that transaction is finished or discarded.
• Disconnect additional internal disks. A second disk that was once a system drive can confuse partition analysis in a way that looks like an unrelated rollback.
• Try the upgrade from mounted media rather than through Windows Update, so the payload is fixed and local for the whole run.
• If the machine is managed, check whether a servicing policy is redirecting setup at a source that does not have what it needs.

Licensing, and when it is genuinely the blocker

Nothing in this article is a licensing problem. A rollback is setup deciding it cannot safely finish; the edition you are entitled to is a separate question that setup asks earlier. The licence only enters the picture when the answer to the rollback is to stop repairing the current installation and do a clean install of a different edition, which is a decision about time rather than about error codes.

Every code this article covers

Confirm the fix worked

1. The machine boots into the new build and winver reports the version you were upgrading to.
2. DISM /Get-MountedImageInfo reports no mounted images left behind.
3. DISM /Online /Cleanup-Image /ScanHealth reports no component store corruption.
4. The $Windows.~BT and $Windows.~WS folders are gone, or are the current rollback set rather than a stale one.

Questions people ask about this