Understanding and Resolving In-Place Upgrade Failures Post Service Authentication Changes on Windows 11
Introduction
Upgrading from Windows 10 to Windows 11 via in-place upgrade is generally a smooth process. However, in certain scenarios, system administrators and power users encounter stubborn upgrade failures that appear related to specific service configurations. This article explores a particular case where a Windows 10 Pro system, configured with a third-party service, encounters consistent failures during the upgrade process after modifying the service’s authentication context.
System Overview
- Original OS: Windows 10 Pro 22H2 (Build 19045.6036)
- Target OS: Windows 11 Pro (latest ISO)
- Hardware Configuration: TPM 2.0 enabled, Secure Boot activated, UEFI firmware
- Networking Environment: Workgroup (local machines, no domain)
- Upgrade Method: Executed via setup.exe with /auto upgrade /eula accept parameters
The core issue manifests after configuring a third-party service with user account credentials and ultimately switching it back to the LocalSystem account. Despite thorough removal of the service, the upgrade process continues to fail during compatibility assessment, regardless of the service’s operational state.
Timeline of Service Configuration & Its Impact
- Initial State (Successful Upgrade):
- Service: ThirdPartyService
- Log On As: Local System account
-
Outcome: Windows 11 upgrade proceeds without issues
-
Modified State (Failure Triggered):
- Service: ThirdPartyService
- Log On As: A specific local user account with username and password
-
Outcome: Upgrade begins but fails during compatibility check
-
Restored State (Persistent Failure):
- Service reverted back to LocalSystem
- Service stopped, disabled, and completely uninstalled
- Outcome: Upgrade still fails consistently
Troubleshooting Efforts
Despite extensive troubleshooting—covering system file checks (sfc /scannow), DISM repairs (/RestoreHealth), Windows Update troubleshooting, registry cleans, disk cleanup, antivirus disabling, hardware diagnostics, and multiple upgrade command options—the failure persists. Event logs have been scrutinized, and network debugging during upgrade attempts has yielded no definitive clues.
Underlying Technical Question
The persistent problem points towards subtle artifacts related to service authentication states that interfere with Windows 11’s compatibility assessment. The key question is:
*What residual authentication artifacts or configuration states remain within
Share this content:
