Diagnose other 0xC1900101 Windows upgrade rollbacks by the proven blocker

Windows Setup begins an in-place feature update or version upgrade, restarts one or more times, then rolls back to the previous working installation and reports 0xC1900101 alone or with an extend code. 0xC1900101 is a generic rollback result most often associated with a driver, a device, or low-level third-party software. It does not identify which component failed.

This procedure preserves the rollback evidence, determines the failed Setup phase, identifies a driver, filter, device, or service when the logs support one, and changes only that blocker before another controlled attempt. It is the general 0xC1900101 procedure. Use FIX-063 when the complete result is 0xC1900101-0x30018.

Searchable Windows error codes and exact messages

The extend code matters. A successful repair for 0x3000D does not prove the same action will repair 0x20017, 0x30018, or an unsuffixed 0xC1900101.

Use this procedure when:

• the previous Windows 10 or Windows 11 installation starts normally after rollback;
• Setup, Windows Update history, SetupDiag, or a rollback log records 0xC1900101;
• the intended operation was an in-place feature update, version upgrade, or repair upgrade;
• the target version and upgrade path are supported for the computer; and
• important data is backed up before another attempt.

The procedure can be used when the suffix was not shown, but confidence remains lower until SetupDiag or the logs reveal the failed phase and component.

Do not use this as a generic cure for every Windows Update failure. It does not apply when the primary result is a hardware-eligibility code such as 0xC1900200, a disk-space code, a servicing-store code, an activation failure, or an ordinary cumulative-update error with no Setup rollback.

It also does not apply while rollback is still running, when the current Windows installation no longer starts, when the system disk is unstable or intermittently absent, or when Setup was started as a clean installation. A retry that selects Keep nothing is not an in-place-upgrade repair; it changes the operation and can remove apps, settings, and data.

Do not change AHCI, RAID, VMD, or another storage-controller mode merely because 0xC1900101 appeared. A storage-mode change is a separate, high-risk branch and requires direct evidence plus a proven bootable rollback path.

The exact Windows build that first introduced the conflict, the date the suspect driver was installed, and whether the blocker is a coding defect or an unsupported combination may remain unknown.

Before removing a driver or low-level application, the following may not remain unknown:

• the complete result and extend code, when recoverable;
• the last Setup phase and operation;
• the last fatal failure rather than the first warning;
• the device, published INF, service, filter, or module proposed as the blocker;
• why that component is being selected;
• how its current package or configuration will be restored; and
• whether the retry is intended to keep apps and files.

An exact target build becomes required when selecting installation media or a replacement driver. Firmware mode is not required unless the evidence points to a boot-path or storage branch.

• An administrator account in the rolled-back Windows installation
• A verified backup of important files and recovery keys or credentials that might be needed by installed software
• Stable power and enough free space for Windows Setup according to its compatibility check
• The latest Microsoft SetupDiag executable, or the SetupDiag result already generated by Setup
• An evidence folder on the system disk or a healthy external drive
• Official Microsoft installation media for the intended target version if Windows Update repeatedly fails
• Exact-model OEM driver and firmware sources when a replacement is required
• A record of enabled third-party services and startup applications before clean boot
• Installation media or recovery media in case the next retry does not roll back cleanly

Do not proceed with a firmware or storage-controller change without a separate, model-specific recovery plan.

Let rollback finish completely. Sign in to the restored Windows installation and confirm that ordinary files open. Do not immediately retry the upgrade; a retry can overwrite useful logs.

1. Open Terminal (Admin) or Command Prompt (Admin).

2. Create a unique evidence directory for this attempt on the detected online system drive:

   for /f %I in ('powershell -NoProfile -Command "Get-Date -Format yyyyMMdd-HHmmss"') do set "EVID=%SystemDrive%\UpgradeEvidence\FIX059-%I"
   md "%EVID%"
   echo %EVID%
   

3. Download the latest Microsoft SetupDiag and save SetupDiag.exe directly in the displayed %EVID% directory. Record its file version. If download is unavailable, preserve the automatic result and defer the manual run rather than substituting a third-party copy.

4. Copy every Setup folder that still exists. A missing folder is recorded as missing; it is not created or fabricated:

   robocopy "%SystemDrive%\$Windows.~BT\Sources\Rollback" "%EVID%\Rollback" /E /COPY:DAT /R:1 /W:1
   set "RC_ROLLBACK=%ERRORLEVEL%"
   robocopy "%SystemDrive%\$Windows.~BT\Sources\Panther" "%EVID%\Panther" /E /COPY:DAT /R:1 /W:1
   set "RC_PANTHER=%ERRORLEVEL%"
   robocopy "%SystemRoot%\Panther" "%EVID%\Windows-Panther" /E /COPY:DAT /R:1 /W:1
   set "RC_WINDOWS_PANTHER=%ERRORLEVEL%"
   if exist "%SystemRoot%\Logs\SetupDiag\SetupDiagResults.xml" (copy "%SystemRoot%\Logs\SetupDiag\SetupDiagResults.xml" "%EVID%\SetupDiagResults-automatic.xml") else (echo MISSING: automatic SetupDiag result>"%EVID%\SetupDiagResults-automatic-MISSING.txt")
   echo Rollback=%RC_ROLLBACK% Panther=%RC_PANTHER% Windows-Panther=%RC_WINDOWS_PANTHER%>"%EVID%\robocopy-exit-codes.txt"
   

   Robocopy exit codes 0–7 are nonfatal result classes; 8 or higher means at least one copy failure. Record a missing source directory explicitly. Do not merge a later attempt into this directory.

5. Capture the current system and driver inventory:

   msinfo32 /nfo "%EVID%\msinfo32-before.nfo"
   driverquery /v /fo csv > "%EVID%\driverquery-before.csv"
   pnputil /? > "%EVID%\pnputil-help.txt"
   pnputil /enum-drivers /files > "%EVID%\pnputil-drivers-before.txt"
   systeminfo > "%EVID%\systeminfo-before.txt"
   

   If /enum-drivers /files is unsupported, rerun pnputil /enum-drivers and save that output, then capture file details for the exact suspect package in Device Manager. Do not interpret an unsupported switch as an empty Driver Store.

6. Photograph or save the complete error as shown in Settings > Windows Update > Update history and record the target version.

7. Download the replacement driver or official media before disconnecting network access. Do not obtain a driver from an unaffiliated driver-download site.

1. Run the current SetupDiag from the evidence directory in an elevated prompt:

   "%EVID%\SetupDiag.exe" /Output:"%EVID%\SetupDiagResults.log"
   

   If SetupDiag reports multiple failures, treat the last failure as the likely fatal failure until other evidence disproves it.

2. Open SetupDiagResults.log and the automatic XML result, if present. Record:

   • matching rule;
   • result code and extend code;
   • last phase and last operation;
   • named file, INF, service, driver, device, application, or compatibility block; and
   • the log path and timestamp supporting the finding.

3. Open the rollback setupact.log and setuperr.log. Search upward from the final occurrence of 0xC1900101, then correlate the same timestamp in both files. Useful search strings include:

   findstr /i /n /c:"0xC1900101" /c:"Shell application requested abort" /c:"Abandoning apply" "%EVID%\Rollback\setupact.log"
   findstr /i /n /c:"0xC1900101" /c:"error" /c:"fatal" "%EVID%\Rollback\setuperr.log"
   

   Warnings earlier in a long log are not automatically the cause.

4. If the extend code is 0x30018, stop this procedure and use FIX-063. Preserve Rollback\setupapi\setupapi.dev.log.

5. If the extend code is 0x3000D, inspect the migration logs and the display-device portion of setupapi.dev.log. A display driver is plausible, but proceed against it only if the log names its INF/device, SetupDiag names it, or the failure began immediately after that driver changed.

6. If setupmem.dmp exists, preserve it. Record any stop code and named module extracted by SetupDiag or a qualified dump analysis. Do not infer a module name from the numeric stop code alone.

7. Map a named third-party INF to its provider and devices:

   pnputil /enum-drivers /files
   pnputil /enum-devices /drivers
   

   Match the exact oem##.inf, provider, class, version, and hardware ID. Do not remove every package from the same vendor.

8. Check installed low-level applications: third-party antivirus, anti-ransomware, disk utilities, encryption filters, tuning tools, VPN filters, virtualization storage/network filters, and OEM management agents. Presence alone is not proof. Give priority to a component named in Setup evidence or installed immediately before the first repeatable failure.

9. Meet one of these thresholds before a component-specific removal:

   • SetupDiag names the component and the underlying log agrees;
   • setupapi.dev.log records the failing device/INF at the fatal timestamp;
   • a rollback dump names the driver and the phase agrees;
   • the same component is named across two independent Setup logs; or
   • a reversible isolation test removes only that component and the same upgrade then succeeds.

10. If no component meets the threshold, classify the case as unisolated 0xC1900101 and use only the minimal-retry branch. Do not invent a blocker.

Choose the narrowest supported branch. Make one material change per retry whenever practical so a success remains attributable.

Branch A — A third-party security, filter, or tuning application is identified

1. Record the product name, version, license information, configuration, and associated driver/service names.
2. Download the vendor's current installer and documented removal tool before uninstalling.
3. Open Settings > Apps > Installed apps and uninstall the identified product normally.
4. Restart Windows. If the vendor documents a cleanup tool for remnants and the Setup logs still show that product's filter, run only that vendor's exact tool.
5. Verify the identified service or driver no longer loads. Do not manually delete .sys files.
6. Keep Microsoft Defender and Windows Firewall enabled unless Microsoft or the exact product vendor documents a specific, temporary requirement. Uninstalling a proven third-party filter is different from broadly disabling Windows security.
7. Retry the in-place upgrade from official media while selecting the intended Keep personal files and apps option.

Branch B — A specific device driver or INF is identified

1. Download a target-version-compatible driver from the computer OEM first, or the device manufacturer when the OEM directs that path.
2. Disconnect nonessential external devices. Keep only power, keyboard, pointing device, and one display.
3. Open Device Manager, locate the hardware ID that matches the evidence, and record provider, version, date, and published INF.
4. If Roll Back Driver is available and the failure began after a driver update, use it and restart.
5. Otherwise uninstall the device package through Installed apps or Device Manager only after the replacement package is local. Start by leaving Attempt to remove the driver for this device unchecked so the previous package remains available for rollback.
6. Restart, install the approved replacement, restart again, and confirm the device has no warning icon.
7. Retry Setup. Permanently deleting the driver-store package is reserved for a package that is positively identified, reinstalling itself, and safely replaceable.

Branch C — The extend code is 0x3000D and the display driver is supported by the evidence

1. Follow Branch B using the exact display adapter and OEM-approved package.
2. On switchable-graphics laptops, prefer the laptop OEM's matched integrated/discrete driver set.
3. Disconnect docks, USB display adapters, and secondary displays for the retry.
4. Do not disable an integrated or discrete adapter unless another known-working display path exists.
5. Retry and preserve the new rollback logs if it fails again.

Branch D — No blocker is isolated

1. Disconnect nonessential peripherals.
2. Run msconfig and select Services.
3. Select Hide all Microsoft services, then Disable all. Record the disabled services.
4. On Startup, open Task Manager and disable each enabled third-party startup item, recording each one.
5. Restart and confirm Windows is in a clean-boot state.
6. Retry once with the clean boot and disconnected nonessential peripherals as the only material change. Do not simultaneously update chipset, storage, display, network, and firmware packages; that would make any success unattributable.
7. Mount current official Microsoft media from within the running Windows installation and run setup.exe.
8. Keep the intended apps/files option. Allow Setup to obtain recommended updates unless a documented failure specifically requires an offline attempt.
9. If it fails, preserve the new logs in a new unique attempt directory before restoring normal startup. Compare the fatal timestamp and component to the previous attempt. Only then apply one evidence-supported exact-model driver/package per later attempt. Treat firmware as its own model-specific maintenance procedure with applicability, stable power, and vendor rollback/recovery instructions.

A VMD/RAID/storage-controller change is not part of Branch D. If logs directly identify that path, stop and use a storage-specific procedure with a proven rollback plan.

• Upgrade completes after removing one identified blocker: record the exact component, old and replacement versions, Setup code, and successful build. This is the strongest result.
• Upgrade completes only after a broad clean boot: the conflict class is supported, but the individual blocker remains unknown. Re-enable items in groups until the conflicting item is isolated.
• The same code and component return: restore the removed component if needed, preserve the new evidence, and test the next log-supported hypothesis.
• The extend code changes: treat it as a new failure stage. Do not keep applying the old remedy because the base code remains 0xC1900101.
• The computer fails to roll back or the system drive becomes unstable: stop retries and move to recovery/storage diagnosis.
• Setup succeeds only after choosing Keep nothing: classify the result as a clean installation, not a validated repair of the in-place-upgrade blocker.

• Do not delete $Windows.~BT, Windows.old, Panther, or rollback logs before evidence is copied.
• Do not use 0xC1900101 alone to blame a display, storage, antivirus, or firmware component.
• Do not uninstall every driver, delete arbitrary oem##.inf packages, or remove Microsoft services.
• Do not disable Defender, Windows Firewall, Secure Boot, VMD, AHCI, or RAID as a generic experiment.
• Do not flash firmware selected by a similar product name.
• Do not run registry cleaners, tuning utilities, or third-party driver updaters.
• Do not retry repeatedly without preserving each attempt's logs.
• Do not call a destructive Keep nothing installation an upgrade repair.

1. If a replacement driver worsens normal Windows operation, use Device Manager > Properties > Driver > Roll Back Driver, or reinstall the recorded previous OEM package.
2. If a removed third-party product is still required, reinstall its current supported version only after Windows is stable. Restore its documented configuration and confirm its filter versions support the new Windows build.
3. Restore normal startup after clean-boot testing from the complete pre-test ledger. Restore each non-Microsoft service and each startup item to its recorded original enabled/disabled state; do not use blanket Enable all, which can activate items that were intentionally disabled before the test. Restart and compare the final state to the saved ledger.
4. Reconnect peripherals one at a time, testing between additions.
5. If Setup rolled back, Windows normally restores the prior build automatically. Confirm it with winver; do not assume the rollback was complete merely because the sign-in screen appeared.

1. Run winver and record the installed edition, version, and OS build.

2. Open Settings > System > Activation and confirm the prior activation state remains valid.

3. Open Device Manager and confirm no new unknown or disabled device exists.

4. Restart twice and perform one full shutdown/start cycle.

5. Test the device or security function affected by the change.

6. Confirm Windows Update history shows the target feature update installed successfully.

7. Reopen an elevated Command Prompt and set EVID to the exact unique attempt path recorded in section 6; environment variables do not survive the upgrade restarts. Then export a new driver inventory and compare the changed package:

   driverquery /v /fo csv > "%EVID%\driverquery-after.csv"
   pnputil /enum-drivers /files > "%EVID%\pnputil-drivers-after.txt"
   

8. Retain the before/after evidence until the new build has completed ordinary use, restart, shutdown, sleep/resume, and update checks.

Confidence is approximately 80% when the full Setup code is recorded, two pieces of evidence identify the same blocker, that blocker is changed reversibly, and the same in-place upgrade then completes while keeping the intended apps and files. Confidence is materially lower when success follows a broad clean boot or multiple simultaneous changes.

The three underlying records include reporter-confirmed success after removing third-party security software, disabling a third-party antivirus, and changing a storage/VMD path. Only the first two support a general low-risk branch. The VMD result remains a storage-specific case and is deliberately not generalized here.

Stop when logs do not identify a blocker after two controlled attempts, the disk becomes unstable, a firmware or controller-mode change would be required without a proven rollback path, the target upgrade path is unsupported, or rollback no longer restores a working system. Escalate with the SetupDiag result, complete code, phase, operation, logs, device inventory, and list of changes already tested.