Resolve a Windows upgrade rollback in the SECOND_BOOT phase

A Windows 10 or Windows 11 feature upgrade installs far enough to reboot into the new operating system, then fails during the SECOND_BOOT phase and rolls back to the previous working version. The useful identifier is the complete pair: a result code such as 0xC1900101 plus an extended code such as 0x40017. The extended code locates the setup phase and operation; it must not be discarded.

This is usually an upgrade compatibility, driver, migration, servicing, space, or unexpected-process failure—not a reason to rebuild the normal Windows BCD after rollback. Use boot repair only if the rollback itself leaves Windows unable to boot and produces independent boot evidence.

Searchable Windows error codes and exact messages

Adjacent driver-phase searches include 0xC1900101 - 0x30018, 0xC1900101 - 0x30017, 0xC1900101 - 0x3000D, 0xC1900101 - 0x20017, and 0xC1900101 - 0x2000C. Keep them in the broader upgrade catalog, but do not label them SECOND_BOOT unless the extended code and SetupDiag do.

Use this procedure after Windows successfully rolls back to the prior Windows 10/11 installation and reports a SECOND_BOOT failure or one of the complete phase/operation pairs above. It is designed to turn logs into one targeted correction before the next attempt.

Do not use it for ordinary monthly cumulative-update errors without a feature-upgrade rollback, a clean install, a computer that cannot boot after rollback, unsupported hardware bypasses, or an enterprise deployment controlled by task sequences without incorporating its deployment logs. Do not classify a bare 0xC1900101 as SECOND_BOOT without the extended code.

The exact root cause may remain unknown until SetupDiag and logs are reviewed. The full result/extended code, current and target versions, attempt time, setup method, SetupDiag result, named driver/application/process, free space, and retry outcome may not remain unknown.

• The rolled-back Windows installation starts normally
• Administrator access
• At least several gigabytes of space for copied logs and dumps
• Microsoft's current SetupDiag tool
• Current supported Windows installation media or Windows Update path
• A verified system backup before the next upgrade attempt
• Vendor-supported driver or application update when a component is identified

Do not immediately rerun Setup. Log folders in $WINDOWS.~BT can be replaced by another attempt or cleanup. While the rolled-back system is stable, create an evidence folder and preserve the current attempt first.

1. Record the exact message and complete code pair from Settings > Windows Update > Update history, the Setup failure dialog, or Event Viewer. Do not record only 0xC1900101.

2. Record the running version:

   winver
   

   Also save system information:

   md C:\UpgradeEvidence
   msinfo32 /nfo C:\UpgradeEvidence\system-before-retry.nfo
   

3. Copy the key setup-log trees before cleanup or retry:

   robocopy C:\$WINDOWS.~BT\Sources\Panther C:\UpgradeEvidence\Panther /E /COPY:DAT /R:1 /W:1
   robocopy C:\$WINDOWS.~BT\Sources\Rollback C:\UpgradeEvidence\Rollback /E /COPY:DAT /R:1 /W:1
   robocopy C:\Windows\Panther C:\UpgradeEvidence\Windows-Panther /E /COPY:DAT /R:1 /W:1
   

4. Preserve dumps created during the attempt:

   robocopy C:\Windows\Minidump C:\UpgradeEvidence\Minidump *.dmp /R:1 /W:1
   copy C:\Windows\MEMORY.DMP C:\UpgradeEvidence\
   

5. Run the current Microsoft SetupDiag from an elevated Command Prompt:

   SetupDiag.exe /Output:C:\UpgradeEvidence\SetupDiagResults.log
   

6. Preserve all additional SetupDiag files it creates. Open SetupDiagResults.log and record:

   • Matching profile or rule
   • Result and extended code
   • Phase and operation
   • Named device, driver, application, service, migration object, or plug-in
   • Referenced log and line/time

7. Search the copied setuperr.log, setupact.log, and rollback setupapi.dev.log around the final failure time. Work backward from the rollback trigger; isolated earlier errors may be benign.

8. Capture driver and application inventory:

   pnputil /enum-drivers > C:\UpgradeEvidence\third-party-drivers-before-retry.txt
   driverquery /v /fo csv > C:\UpgradeEvidence\driverquery-before-retry.csv
   powershell -NoProfile -Command "Get-AppxPackage | Select Name,Version,PackageFullName | Out-File -Width 300 C:\UpgradeEvidence\appx-before-retry.txt"
   

9. Record free space on the Windows, ESP/system, and Recovery partitions. Use Disk Management or DiskPart to detect the layout; do not ask the reader to guess firmware mode or partition placement.

10. Choose a resolution branch only when SetupDiag, logs, dumps, compatibility output, or a direct retry comparison identifies it.

Branch A — 0xC1900101 - 0x40017 or another named driver/device failure

1. Identify the exact .sys, device instance, service, or oem#.inf cited near the final failure.

2. Prefer the following in order:

   1. Install a newer vendor-supported driver specifically correcting upgrade compatibility.
   2. Roll back the driver if the failure began after its update.
   3. Uninstall the owning nonessential application or device package.
   4. Physically disconnect a nonessential external device for the upgrade.

3. Export a third-party package before removal:

   pnputil /export-driver <oem-number.inf> C:\UpgradeEvidence\DriverBackup
   

4. Remove it only when exact identity and nonessential status are established:

   pnputil /delete-driver <oem-number.inf> /uninstall
   

5. Do not mass-update every driver. Do not assume 0xC1900101 specifically means storage.

6. Disconnect nonessential USB devices, docks, external storage, and extra displays during the retry. Keep required input and network only if the selected setup path needs it.

Branch B — 0xC1900101 - 0x4000D or 0x8007042B - 0x4000D during MIGRATE_DATA

1. Search rollback logs for the last named migration object, profile, service, shell extension, filter, or process.

2. For a named third-party process or service, uninstall or update its owning product.

3. If logs show a background-process collision but do not justify removal, perform a documented clean boot:

   • In msconfig, hide all Microsoft services before disabling remaining non-Microsoft services.
   • Disable nonessential startup applications in Task Manager.
   • Record everything disabled.

4. Temporarily uninstall third-party antivirus or endpoint filter software only when the logs or vendor guidance support it and its reinstall package/license is available. Merely turning off its interface may leave kernel filters loaded.

5. Check profile and data paths named by migration. Repair permissions or file-system issues only when the log identifies them.

6. Retry once. If the same migration object fails, preserve the new logs and escalate rather than adding more generic cleanup.

Branch C — 0xC1900208 - 0x4000C or 0x800F0923 compatibility block

1. Use SetupDiag, the compatibility report, and setup logs to identify the exact application, driver, or feature.

2. Update it to a version explicitly supporting the target Windows version, or uninstall it through its supported uninstaller.

3. Remove abandoned low-level utilities and filters only after confirming ownership and backup.

4. Restart and rerun the compatibility scan before starting the full upgrade.

5. Do not bypass a compatibility hold without understanding the blocked component and recovery consequences.

Branch D — Space codes 0x80070070 - 0x50011, -0x50012, or -0x60000

1. Determine which partition Setup says lacks space. Do not assume it is only C:.

2. Back up and remove ordinary temporary files through Settings > System > Storage > Temporary files or Disk Cleanup.

3. Move personal data to another backed-up volume when necessary.

4. Confirm Windows, ESP/system, and Recovery partitions are healthy and meet the target upgrade's current requirements.

5. Do not shrink, delete, or retype partitions as an improvised first response. Partition resizing requires a separately imaged procedure.

6. Record free space before the retry.

Branch E — Component-store or assembly codes 0x80073712, 0x800F081F, or 0x800736B3

1. From elevated Command Prompt, check and repair the running component store:

   dism /Online /Cleanup-Image /ScanHealth
   dism /Online /Cleanup-Image /RestoreHealth
   sfc /scannow
   

2. Preserve C:\Windows\Logs\DISM\DISM.log and C:\Windows\Logs\CBS\CBS.log.

3. If 0x800F081F says source files cannot be found, use a compatible source for the installed edition, language, architecture, and build. Exact version matters here.

4. Restart and confirm DISM/SFC are clean before retrying Setup.

5. Treat 0x800736B3 as a missing side-by-side assembly/component-store problem, not a generic “app missing” message.

Branch F — 0xC0000005 access violation or changing crash modules

1. Preserve SetupDiag and crash dumps. 0xC0000005 means access violation, not ordinary access denied.

2. Analyze any dump and identify the faulting process/module.

3. Return CPU and memory settings to documented defaults and disable XMP/EXPO for the retry.

4. Run FIX-028 when crashes or named modules vary.

5. Update or remove only the component supported by the dump/log. Do not apply file-permission resets to the whole Windows tree.

Branch G — Prepare one controlled retry

1. Confirm the prior Windows installation is healthy and fully backed up.

2. Install current servicing-stack/cumulative updates required for the supported upgrade path.

3. Correct exactly the demonstrated blocker from Branch A–F.

4. Disconnect nonessential external devices.

5. Preserve at least 30 GB of working free space on the Windows volume unless Microsoft's current requirement or Setup's own calculation calls for more.

6. Use one supported upgrade path and current media. Record whether Dynamic Update is enabled.

7. Do not change controller mode, firmware architecture, Secure Boot keys, BCD, multiple drivers, and multiple applications at the same time.

8. Run the upgrade once. If it fails, preserve the new logs before another attempt and compare the final failure with the prior attempt.

• The corrected component is named and the upgrade completes: The causal mapping is strong.
• The phase/code changes: The original blocker may be cleared; diagnose the new complete pair independently.
• The same driver or migration object returns: The correction was incomplete or the wrong package copy remains. Do not broaden changes blindly.
• SetupDiag reports no match: Manually review the final rollback chronology and device-install log; retain an unknown-cause label if no mechanism is defensible.
• Rollback no longer boots: Switch to the boot-failure writeup that matches the new screen. Do not continue the upgrade procedure.
• A RAID/VMD/IRST component is named: Retain the case but move it to the deferred specialist branch.

• Do not discard the extended code or phase/operation wording.
• Do not call every 0xC1900101 a storage-controller error.
• Do not rebuild BCD after a successful rollback unless independent boot evidence requires it.
• Do not delete $WINDOWS.~BT before copying its logs.
• Do not run registry cleaners, driver-updater utilities, or broad permission resets.
• Do not disable every service without hiding Microsoft services and recording the baseline.
• Do not repeatedly retry Setup without preserving and comparing each attempt's logs.
• Do not bypass a compatibility safeguard merely to force installation.

Windows Setup normally performs the primary rollback automatically. Before retrying, create or verify a system image. Re-enable clean-boot services and startup items after the upgrade succeeds or testing ends. Reinstall an exported driver package only if it was wrongly removed and is known compatible:

pnputil /add-driver C:\UpgradeEvidence\DriverBackup\<driver.inf> /install

Restore third-party security software immediately after the upgrade test if it was deliberately removed and the system is otherwise stable.

• winver shows the intended target Windows version and build.
• Windows completes two normal restarts and one cold start without rollback.
• Device Manager has no unexplained devices or problem codes.
• The component corrected before the retry functions with a supported version.
• DISM and SFC are clean when servicing corruption was involved.
• Windows Update completes a scan after upgrade.
• Pre- and post-retry SetupDiag results, logs, inventories, and code pairs are archived.
• Clean-boot settings and security software are restored deliberately.

Confidence is high when SetupDiag/logs identify one component, that component is corrected, and the next upgrade succeeds. It is moderate when a clean boot or device disconnection succeeds without naming the exact participant. Stop after a repeated identical failure with no stronger evidence, when SetupDiag/logs are unavailable, hardware is unstable, the target version is unsupported for the device, a safeguard hold remains, or the repair enters deferred RAID/VMD/IRST territory.