Question: Where can I find logs from Win10 upgrade and how to interpret them? I've attempted to apply the upgrade three times, and I'm trying to get a clue if there's anything I can fix, so that it succeeds next time. In particular, if the failures are caused by an incompatible driver, a HW error, by missing files or dirs, I can try to fix that.
Details: Windows Update offered me Win10 upgrade from version 1909 to 20H2. The upgrade failed - twice - with error 0x8007001f. Then Windows Update stopped offering the upgrade. Hence, the third time I used the Upgrade Assistant, but the upgrade failed again. By "failing" I mean that the update had been installed, the Windows rebooted and was finishing the installation, but at the end everything was rolled back. (One round took about an hour.)
I was able to find some logs in C:\Windows\Panther\NewOs
, but these logs are from the second upgrade attempt only. I cannot find any logs from the third attempt, they seem to be lost/rolled back. In the Windows Event logs, there is a single line: installation failed with error 0x8007001f, nothing else. Should I look somewhere else?
The setupact.log
in C:\Windows\Panther\NewOs\Panther
contains 450 error lines in total, but this is probably normal as the installation went on. Most of the errors are in setuperr.log
, too. I cannot tell what error caused the installation to stop and roll back. These are the last errors (with several important Info lines):
Info SP SPExecuteFirstBootApply: Begin run. WinOld: C:\Windows.old
Info SP pSPExecuteApply: Starting the engine online
2020-11-15 11:15:55, Error MIG Ignoring replacement manifest with no settingsVersionRange or versionRange attribute in migration element: Microsoft-Windows-Container-Manager
2020-11-15 11:16:03, Error [0x080831] MIG CSIAgent: Invalid xml format: FormatException: Component with display name: Plugin/{C939EC0F-2F56-4CE8-AF56-2336596A5FA7} already loaded __cdecl Mig::CMXEMigrationXml::CMXEMigrationXml(class Mig::CPlatform *,class UnBCL::String *,class UnBCL::XmlDocument *,class UnBCL::String *,class UnBCL::String *)
2020-11-15 11:16:04, Error Mig::CUpgradeTransportPlatform::SetUserContext: Store platform failed to find the user with ID: USER00000005, SID: S-1-0-0[gle=0x000000cb]
2020-11-15 11:16:04, Error MIG Mig::CKnowledgeManager::BeginProcessingContext: Source platform failed to set the user context USER00000005[gle=0x000000cb]
2020-11-15 11:16:04, Error MigApply caught exception: Win32Exception: Can't switch to requested user context: USER00000005.: A device attached to the system is not functioning. [0x0000001F] int __cdecl Mig::CKnowledgeManager::Apply(class Mig::CPlatform *,class Mig::CPlatform *,class Mig::CPlatform *,class Mig::CUserMappingList *,class UnBCL::Hashtable<class UnBCL::String *,class UnBCL::String *> *,class Mig::CAgentManager *,class Mig::CMigrationLogger *,int *,struct IMigExecuteProgress *)[gle=0x000000cb]
2020-11-15 11:16:04, Error SP pSPExecuteApply: Apply operation failed. Error: 0x00000004[gle=0x000000cb]
Info SP SPExecuteFirstBootApply: End run. Result: 0x00000004
2020-11-15 11:16:05, Error SP Apply (first boot apply, online phase): Migration phase failed. Result: 4, no specific error[gle=0x00000002]
2020-11-15 11:16:05, Error SP Operation failed: First boot apply. Error: 0x8007001F[gle=0x000000b7]
2020-11-15 11:16:05, Error SP Operation execution failed: 13. hr = 0x8007001F
2020-11-15 11:16:05, Error SP ExecuteOperations: Failed execution phase Post First Boot. Error: 0x8007001F
2020-11-15 11:16:05, Error SP Operation execution failed.
2020-11-15 11:16:05, Error SP CSetupPlatformPrivate::Execute: Failed to deserialize/execute post-FirstBoot operations. Error: 0x8007001F
Was the upgrade failure caused by the error Store platform failed to find the user with ID: USER00000005, SID: S-1-0-0 (Nobody)
? In that case I'd have to wait for the fix by Microsoft.
Edit:
SetupDiag found the logs from the third attempt in C:\$WINDOWS.~BT\Sources\Panther
. It tested plenty of thing, most of them were "No match", unfortunately it found nothing. Here is the content of the SetupDiagResults.log
:
Matching Profile found: FindRollbackFailure - 3A43C9B5-05B3-4F7C-A955-88F991BB5A48
SetupDiag version: 1.6.0.0
System Information:
Machine Name = XXXXX
Manufacturer = LENOVO
Model = 20MAS0P900
HostOSArchitecture = 1033
FirmwareType = UEFI
BiosReleaseDate = 20200620000000.000000+000
BiosVendor = N2CET54W (1.37 )
BiosVersion = N2CET54W (1.37 )
HostOSVersion = 10.0.18363
HostOSBuildString = 18362.1.amd64fre.19h1_release.190318-1202
TargetOSBuildString = 10.0.19041.568 (vb_release_svc_prod1.200929-2208)
HostOSLanguageId =
HostOSEdition = Enterprise
RegisteredAV = Windows Defender
FilterDrivers = FileInfo
UpgradeStartTime = 15.11.2020 15:30:11
UpgradeEndTime = 15.11.2020 16:13:43
UpgradeElapsedTime = 00:43:32
CV = 4zV5tAA0J0Oq5Zcl
ReportId =
Error: SetupDiag reports rollback failure found.
Last Phase = Post First Boot
Last Operation = First boot apply
Error = 0x8007001F-0x3000D
LogEntry: 2020-11-15 16:13:42, Error SP Operation failed: First boot apply. Error: 0x8007001F[gle=0x000000b7]
Refer to "https://docs.microsoft.com/en-us/windows/desktop/Debug/system-error-codes" for error information.
Last Setup Phase:
Phase Name: Post First Boot
Phase Started: 15.11.2020 16:13:31
Phase Ended: 01.01.0001 0:00:00
Phase Time Delta: 00:00:00
Completed Successfully? False
Last Setup Operation:
Operation Name: First boot apply
Operation Started: 15.11.2020 16:13:31
Operation Ended: 01.01.0001 0:00:00
Operation Time Delta: 0:00:00:00,0000000
Completed Successfully? False
The problem was caused by a bug in the Windows Upgrade script, that is there for years, and it is still not resolved. It occurs on computers where user profiles are not on the system disk. In my case, my system disk is C:, and user profiles are on D:.
To resolve this problem, open RegEdit and navigate to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
. Here, change ProfilesDirectory
to the default value C:\Users
. In my case, this was sufficient for the upgrade to succeed. After the successful upgrade, change ProfilesDirectory
back to the previous value. Compare e.g. here.
Big thanks to @Ramhound! I hope Microsoft addresses this problem soon, because it causes headaches to many people (try searching internet).
User contributions licensed under CC BY-SA 3.0