0xC1900101 – 0x20004 and 0x8007042B: drivers and killed processes roll the upgrade back

Fix it now

0xC1900101 – 0x20004 is a SAFE_OS failure during the INSTALL_RECOVERY_ENVIRONMENT operation, and Microsoft’s published cause is out-of-date drivers. 0x8007042B is Win32 error 1067, ERROR_PROCESS_ABORTED – a process terminated unexpectedly. Both point at software with a kernel driver rather than at a broken Windows installation.

SetupDiag.exe /Output:C:\SetupDiag\Results.log
fltmc filters
reagentc /info

1. Work through Microsoft’s published mitigation for 0x20004 in order: uninstall antivirus applications, remove all unused SATA devices, remove all unused devices and drivers, and update drivers and BIOS.
2. Uninstall rather than disable. Read the fltmc filters output and confirm any third-party file system filter driver has actually gone, using the vendor’s own removal tool if the ordinary uninstall leaves it behind.
3. Read the reagentc /info output. Windows RE reported as Disabled, or an empty location line, explains why the operation that installs the recovery environment cannot complete.
4. If it is disabled or unregistered, run reagentc /disable then reagentc /enable, and confirm with reagentc /info that it reports enabled with a location.
5. Suspend BitLocker with manage-bde -protectors -disable C: -rebootcount 3, disconnect everything except mouse, keyboard and display, and restart.
6. Run the upgrade from mounted media so you can control it and read the logs: setup.exe /auto upgrade /dynamicupdate disable.

Take the recovery key off the machine before you touch BitLocker, and do not resize or recreate partitions mid-upgrade.

If the upgrade completes, you are finished. If it rolls back again, the next section explains what SAFE_OS is doing at that point and what kills a setup process.

Why it happens

Before an upgrade can boot the new build it runs a phase in a temporary offline environment. Microsoft calls it SAFE_OS, and the extend code 0x20004 is phase 2 with operation 0x04, INSTALL_RECOVERY_ENVIRONMENT: setup is servicing the recovery environment for the new installation. Microsoft’s published cause for that failure is out-of-date drivers, and the published mitigation is a list – uninstall antivirus applications, remove all unused SATA devices, remove all unused devices and drivers, update drivers and BIOS.

That list is more interesting than it first looks. Every item on it removes something from the driver set that the offline phase has to load. An antivirus product with a filter driver, a SATA channel with nothing attached to it, an obsolete driver package still registered in the store: each of them is a thing setup has to deal with in an environment that has none of the recovery paths a running Windows has.

0x8007042B is a different statement. Its low word is 1067, and the published Win32 text is ‘The process terminated unexpectedly.’ Nothing checked and failed – something was killed. Microsoft documents the pairing 0x8007042B – 0x4000D as a failure during the second boot phase attempting MIGRATE_DATA, caused by file system, application or driver issues, and the published mitigation is to read the logs to find the file, application or driver that could not be migrated, then disconnect, update, remove or replace it. Note the phase: the second boot phase, not SAFE_OS. The two codes on this page do not describe the same moment.

0xC1900106 and 0xC1900104 fill in the rest of the picture and both have published names. 0xC1900106 is MOSETUP_E_TERMINATE_PROCESS, ‘The installation process was terminated.’ 0xC1900104 is MOSETUP_E_PROCESS_TIMEOUT, ‘The installation process did not complete within the required time limit.’ Between them they distinguish a run that was stopped from a run that ran out of time – which is a genuinely useful distinction when you are deciding whether to blame an agent or a slow disk.

Full reference

What each code is, precisely

Commands worth having open

Where to read what actually happened

After a rollback the logs move to %windir%\Panther; during a run they are under %SystemDrive%\$Windows.~BT\Sources\Panther. setuperr.log holds the errors and setupact.log the full sequence. The rollback folder, $Windows.~BT\Sources\Rollback, is where a setupmem.dmp appears if setup crashed rather than stopping, and a dump names a module far more reliably than any of the setup logs do.

On the recovery partition

A recovery partition of a few hundred megabytes, or one that sits before the Windows partition rather than after it, cannot be extended to hold a new build’s recovery image. That is the same layout limitation that makes recovery environment patches fail on machines imaged years ago. Disabling Windows RE for the duration lets setup build its own rather than trying to service one it cannot grow. Repartitioning a system disk is a bigger job than an upgrade and deserves a full backup and its own maintenance window.

When everything above is clean

• Run the upgrade with /CopyLogs \\server\share\ on an unattended machine so you get the logs even from a failed run.
• Try /MigrateDrivers None so the new build does not inherit the current driver set.
• Check the firmware version against the manufacturer’s current release; Microsoft names updating the BIOS in its own mitigation.
• Confirm there is real free space on the system volume, because a slow, full disk is a common reason a run hits its time limit.
• If the failure is reproducible on several identical machines, treat it as a fleet driver problem and take it to the hardware vendor rather than repeating it.

Every code this article covers

Confirm the fix worked

1. winver reports the build number you were upgrading to.
2. reagentc /info reports Windows RE enabled with a valid location, whether or not you disabled it during the upgrade.
3. fltmc filters shows only the filter drivers you expect after any agents are reinstalled.
4. manage-bde -status C: shows protection on again if you suspended BitLocker.
5. %windir%\Panther\setuperr.log from the successful run contains no errors from the phase that previously failed.

Questions people ask about this