[SOLVED] Win10 - refuses to update to 22H2

seems difficult to diagnose!
It is certainly a difficult issue, we could try to run the update again with Process Monitor and Boot Logging enabled.

Capture Process Monitor BootLog
1. Download and run Process Monitor. Leave this running while you perform the next steps.
2. Select the Options....Enable Boot Logging option. A Enable Boot Logging dialog will come up. Just click OK.
3. Create a folder on your desktop named BootLog.
4. Attempt to install the update just like you have in the past. Let the machine reboot and revert just like it has in the past.
5. After the machine has rebooted and come back up to the desktop, open Process Monitor again. A message box will come up telling you that a log of boot-time activity was created and ask if you wish to save it. Click Yes and save to the BootLog folder on your desktop.
6. This may take some time as it converts the boot-time data. Allow it to finish.
7. Zip up the entire BootLog folder on your desktop and upload to a file sharing service of your choice for my review. Examples of services to upload to are Dropbox or OneDrive or SendSpace
 
It's done. BUT... during the update, procmon died twice from lack of RAM. The process grew beyond 2 gig and crashed. I restarted it but it died again. Did make a boot log though, so maybe we are ok.

I'll post a link to the big log file in a bit
 

Attachments

Thanks, please check if the developer mode is enabled in the settings screen under "Update & Security > For Developers".
 
Ok, it seems the migration process is using the F:\ drive, does this drive contains (old) system files?
 
Ok, it seems the migration process is using the F:\ drive, does this drive contains (old) system files?
The f: drive contains only pagefile and backups

The e: drive also contains a page file.

There is no page file on ç:
 
Hmm, does this folder exists F:\$WINDOWS.~BT\NewOS?
Nothing there that I can see, not even with "show hidden files" on. I have no idea what that would even be. This drive has had nothing but backup folder for years
 
It is unclear why this location is being used during the update proces, in particular because it has only 8 GB of free space. I would suggest to move the pagefile back to the C:\ drive, and then disconnect all the other hard drives and the Gmail drives. And then attempt to update again.
 
The following drive:

Drive c: () (Fixed) (Total:930.32 GB) (Free:343.36 GB) (Model: ST1000DM003-1CH162) NTFS
Drive e: (Backups) (Fixed) (Total:1863.01 GB) (Free:635.2 GB) (Model: ST2000DM001-1ER164) NTFS
Drive f: (PageFile) (Fixed) (Total:596.17 GB) (Free:8.47 GB) (Model: SAMSUNG HD642JJ) NTFS
Drive g: (**********@gmail.com - Google Drive) (Fixed) (Total:15 GB) (Free:5.57 GB) (Model: ST1000DM003-1CH162) FAT32
Drive i: (**********@gmail.com...) (Fixed) (Total:15 GB) (Free:0.5 GB) (Model: ST1000DM003-1CH162) FAT32
 
Something is very wrong. I don't know where that list came from but it is very inaccurate there is only a few hundred mb used on that drive right now
 
This result is from FRST, so this is absolutely strange. But I would still suggest to perform the following steps and see what happens.
I would suggest to move the pagefile back to the C:\ drive, and then disconnect all the other hard drives and the Gmail drives. And then attempt to update again.
 
Here is what I chose to do:

Remove page files from e: and f:
Enable windows managed pagefile on c:
Disable f: in control panels

Start a normal windows update through settings


On double checking, the f: was empty except for a few gb of backups, no other folders then backupdata. The page file was 64bg. Page file on e: was 4gb

The name "newOS" strikes a very distant memory, can't remember any details but I believe it would have been literally several years ago. Perhaps during the update to windows 10 from 8 ? As I said, this system is about a decade old, through many changes and never a fresh install (always a running mission critical system). The update problems started close to 2 years ago, perhaps after some routine cleanup operations. Again, I can't remember details.

Update running now
 
Rich (BB code):
2023-02-24 18:35:45, Error                 SP     Cannot revert execution of operation 42 (Apply EAs for F:\$WINDOWS.~BT\NewOS). Execution queue is now compromised.[gle=0x00000012]
2023-02-24 18:35:45, Error                 SP     Operation execution failed: 13. hr = 0x8007001F[gle=0x00000012]
2023-02-24 18:35:45, Error                 SP     ExecuteOperations: Failed execution phase Safe OS. Error: 0x8007001F[gle=0x00000012]
2023-02-24 18:35:45, Error                 SP     CSetupPlatformPrivate::Execute: Execution of operations queue failed, abandoning. Error: 0x8007001F[gle=0x00000012]
This is the complete error message in relaition to the F:\ drive form the latest logs. I don't know why this location was used during the setup process? So I wonder if this part appears again when the update fails with a rollback after the first reboot.

The reason why I suggested to disconnect all the other drives is to avoid the update process could access them. 0x8007001F is a generic error and means "A device attached to the system is not functioning". This might also be a reason why FRST is reporting 8 GB of free space for drive F:\ in the logfiles?!
 
Status:

After doing the above, it failed just as before. same error, same point.

Then, I went into BIOS and disabled the drives. tried a normal update, and it failed again, same place, same error

Next, I went into bios and disabled not only the drives, but also the cdrom, and audio.

Did a standard update, and it failed with the same error but after running MUCH longer. Where in the past it would run about 20 minutes after the first reboot and reach about 25%, this time it ran for about an hour after the reboot before it reverted changes (did not catch the percent). However it did fail with the same error.

One extra datapoint: after i ran the standard update, the files in the panther folder were no long er accessible. I had to manually enable inheritance to read them.

So, lastly i am running an update through the media tool. When it finishes I'll grab the logs.
 
Last edited:
lt failed again, but ran for about an hour after reboot before undoing changes. logs look different, but i still see refetence to D: for that newos error. thete is onoy c: now, nothing else.

could it be referring to partitions on c?
 

Attachments

Back
Top