SetupDiag.exe Will Help You Diagnose Windows 10 Upgrade Errors
Rubie Mccloughan
This summer, I completed my Feature Update from 1803 to 1909 for my company. The deployment went pretty smooth using the feature updates deployed from CM and then Martin Bengtsson Toast notification script (v 1.6 at the time). At that time, it didn't handle Feature Updates. So I added protocols and scripts to help with that. I'll look at another article to talk about that. This is mainly a blog of troubleshooting that went into feature updates for me this summer.
The update may still be running in the background. Please check for the running Processes from below (mainly SetupHost). Also, look at the SetupAct.log and see if it has exited the process. If processes are still running, please just wait until the update completes. This can be done by either just waiting a few hours or monitoring the setupact.log.
Once setupact.log shows completed, you can retry the update from Software Center to allow it to determine that it is indeed installed and ready for reboot. This will allow the trigger of phase 2 and the reboot process can complete.
After the upgrade, Software Center may continue to state that the update requires a Reboot to complete. This will put the computer into a sort of reboot loop. And you will notice that it is actually already upgraded to 1909. To resolve this, do the following:
Although this is not a complete guide, these are the sorts of errors I ran into during my feature updates this summer. Much of this was probably gleaned from other sources in the heat of the moment but, has been refined to the solutions that helped me complete the upgrades.
I'm sure there are more errors out there that you have run into. It'd be great for you to share them. Or, you may have different solutions to the same errors that I didn't think of, share those as well.
This is an extremely hot topic and I do know that we have some awesome OSD experts out there sharing their content already (Gary Blok, Mike Terrill etc.). Now, their content is way superior to mine and probably suit a lot of needs already, but I think that content around WaaS in particular is interesting and especially when sharing how one does Windows Servicing in details.
This is where the actual upgrade takes place, following some other actions like flashing the BIOS, updating of applications etc. With my previous post, we made sure that all the content referenced by this very task sequence already exists in the CM cache. By doing so, we cut down the time the end user has to wait dramatically. Also, this enables us to allow the task sequence to be run from VPN, Direct Access or even over the Internet through our CMG without the need to download any content while being remote. Sweet! ?
This step sets the initial UpgradeStatus registry key to 1 indicating a failure. This is supposed to be overwritten later on when everything succeeds and we have verified that Windows 10 is now 1803 (or whatever version of Windows you are deploying). The idea is, that the upgrade is considered a failure until this key has been updated. More on this later on. Also, this is being picked up by hardware inventory for use with collections.
This is just me doing all sorts of configuring of Windows and updating of applications POST upgrade. This group only runs if _SMSTSSetupRollback equals False AND _SMSTSOSUpgradeActionReturnCode equals 0.
Finalize is a sub-group to Post-processing and thus only runs if everything supposedly ran without issues during the actual upgrade. I also re-enable BitLocker at this stage following the next reboot (I enable AND disable BitLocker but without -RC 0 which will enable BitLocker at next reboot).
This combined with the previous step is an additional check on whether the upgrade indeed was done and the build is now 1803. This group runs if the current OS build is NOT equal to what we initially set in the task sequence.
At this stage we have verified that the _SMSTSOSUpgradeActionReturnCode returned 0 AND the actual Windows build is as expected, thus we tattoo and update the UpgradeStatus registry entry with 0 indicating a SUCCESS. This is still being picked up by hardware inventory.
This is running the diagnostic tool SetupDiag, which can be used to obtain additional details on why a Windows 10 upgrade failed. More about SetupDiag here: -us/windows/deployment/upgrade/setupdiag
Ideally and as I touched briefly in the PreCache post, the collection where ALL the checks has passed will be where you will deploy the actual IPU task sequence to. Another approach is obviously to create additional collections and then use this collection as a limiting collection. Everything as it suits your own environment.
And when deploying the IPU task sequence, remember to deploy it with following deployment option: Download all content locally before starting task sequence. This will make sure that the content already in the CCM cache is used and that content is not downloaded yet again.
First of all thanks for sharing this, it has been a massive help getting our 1809 WaaS deployment up and running. One thing that we have noticed is that we are encountering a number of devices failing to upgrade and when we check the setupdiag logs we see the following error:
Warning: Setup was executed with a /Compat ScanOnly command line switch and exited with the appropriate exit code.
If you wish to update this system, remove the /Compat ScanOnly switch from the command line.
I have double checked the task sequence to ensure that the perform windows setup compat scan without start upgrade was unticked, which it was. Any ideas on what could be causing the task sequence to believe that its running the setup in compat mode as required in the precache TS?
Thank you for sharing your work and documenting it. I am in the process of trying to leverage these respective TS in my environment but after the Upgrade OS Step everything takes an extremely long period of time to run on the system.
e.g. I have already installed a licensed copy of MS WORD and it would be ideal if 21H2 preserved all existing programs and files. I would rather avoid needing to re-install all third-party software again.
Has Microsoft perhaps offered a single-purpose utility to verify whether or not all installed drivers are compatible with pending Windows Updates and/or upgrading to newer versions of Windows 10?
Device Manager continues to list an IDE device, even though there is no PATA socket anywhere on the motherboard; and, the .pdf User Manual also confirms that this PC does not support any IDE / PATA storage devices e.g. old PATA HDD or ODD.
For example, one ASUS motherboard has 2 x integrated Gigabit LAN controllers: one PCIe and one PCI. I ENABLE the PCIe one, and DISABLE the PCI one. These settings have always worked smoothly with all of our ASUS motherboards.
My BEST GUESS, as of today, is a very subtle bug in the latest motherboard BIOS: for example, I have also DISABLED the 1 x PCI slot in that BIOS. Such a bug may be associated somehow with that change e.g. I can try ENABLING it to see if that makes any difference.
I enabled WinUpdateStop, because of all the published complaints about Windows Update. That was a wise decision, in retrospect, because it rendered this HP workstation VERY stable over the course of many years.
A search of the Internet for that error code finds results that suspect a device driver as the reason for the ROLL-BACK and fatal error code. But, our efforts to locate such a driver in the update logs turned up empty.
software related issues can be hard to pin down and since you are using a old release of win 10 currently and having problems with a in place update, consider doing a clean install, this method can save you much time and frustration I personally have a 6300 pro (SFF model) which uses the exact same motherboard,.. and windows 10 22H2 64bit installs without any issues and includes all necessary drivers for this models hardware short of some add in discrete video cards and printer drivers i would simply backup your existing data, download the win 10 installer of your choice (usb key or Iso) install the OS and be done with it
I agree with HP about wiping the hard drive and installing a fresh copy of Windows as something is clearly amiss with the existing Windows installation with no end in site of possibly getting it fixed after six days of troubleshooting.
I fully appreciate why you are advising that probable solution, and I am sincerely grateful and understanding why it may have potential, and could succeed assuming I am willing to re-install ALL third-party software and similar system management utilities.
(2) the majority of professional opinions point to some device driver that is not identified any further in any of those opinions, however; at best those opinions recommend disconnecting ALL peripherals and resorting to more trials-and-errors
(10) it is very UNLIKELY that the driver for the Highpoint RocketRAID 2720SGL RAID controller is the culprit, because both PCs host the C: system partition on that same add-in card, and the long Windows Update process must perform HEAVY I/O with that add-in controller
(11) further research of relevant documentation on the Internet confirms that the error code in question has been occurring on many PCs worldwide: reportedly it is the single most frequent error code being reported to Microsoft during the past 2 years
(12) if verifiable, the reports summarized at (11) above would strongly suggest that Microsoft escalate that error code by dedicating capable in-house engineering expertise to identify the source(s) of that error and to publish one or more effective solutions
(13) specifically, any Microsoft software that issues that same error code can and should be modified to add more executing code that attempts to identify any suspicious device driver(s) and/or to report any other diagnostic information that can help Windows Update to complete successfully withOUT a total ROLL-BACK
bcf7231420