Welcome to our peer-to-peer forums, where owners help owners. Need help now? Visit eSupport here.

English Community

ThinkCentre DesktopsThinkCentre A, E, M, S Series
All Forum Topics
Options

2895 Posts

06-13-2013

United States of America

11444 Signins

62811 Page Views

  • Posts: 2895
  • Registered: ‎06-13-2013
  • Location: United States of America
  • Views: 62811
  • Message 1 of 10

21H1 Update FAILS in SAFE_OS phase at boot (error 0xC1900101-0x20017 )

2021-06-09, 8:05 AM

More nonsense, most likely from Microsoft.

 

Three different machines (Lenovo M920t, Lenovo M93p, HP All-in-one) all currently running 20H2, all failed the same way to upgrade to 21H1.

 

 

At first I simply initiated the ordinary "download and install" process pushing the button when offered in Windows Update, which said 21H1 feature update was ready to be installed on the machine.  Never seemed to run to completion. Sorry, I can't remember what the termination was for each of the three machines, but they were all unsuccessful.

 

The next thing I've tried (again unsuccessfully) on all three machines is the standard "upgrade this PC" method.  This begins with a visit to the MS "Download Windows 10" site (to create installation media, either downloaded for immediate use or to create bootable USB install media).  Push the "download tool now" button, and then choose the "upgrade this PC" path. After running quite some time all three machines then terminated with the above error message, reverting back to 20H2.

 

This of course is very similar to the worldwide failure last year of Win10 machines to move past 1909 and into 2004 or 20H2. This was supposedly the result of a Microsoft "upgrade blocker" bug that was eventually fixed by MS and pushed out to the world, and which actually did finally allow those failing updates to 20H2 to actually now succeed.

 

But I haven't yet tried what I've used successfully multiple times to overcome the "upgrade blockage", which is the so-called "in-place upgrade" method. I will try this next. This approach is based on first building a USB install media flash drive (from the Download Windows 10 site, following the "create installation media for a different PC" path. Then while running in the currently installed 20H2 system, navigate to the inserted just created USB flash drive and RUN the SETUP.EXE in the root of the USB flash drive. This initiates a true fresh new 21H1 Windows install that will completely replace the existing currently installed 20H2 Windows, while simultaneously retaining all existing currently installed user programs, customization, and data.

 

I will try the "in-place upgrade" method tomorrow. It is recommended to try this with all external devices (e.g. external Thunderbolt devices, USB hard drives, etc.) disconnected just to minimize any distractions, but that is not necessarily a requirement nor is it a guarantee of success. But the "in-place upgrade" method is generally the last resort (short of a wipe clean full install from scratch), and I've had excellent success with this method in some previously very frustrating situations.

 

There are quite a number of similar reports of this error out on the interweb.

Reply
Options

5961 Posts

08-02-2018

Philippines

953 Signins

30199 Page Views

  • Posts: 5961
  • Registered: ‎08-02-2018
  • Location: Philippines
  • Views: 30199
  • Message 2 of 10

Re:21H1 Update FAILS in SAFE_OS phase at boot (error 0xC1900101-0x20017 )

2021-06-09, 9:52 AM

Thank you for the heads up and for sharing the steps you've made regarding this issue.

 

We'll wait for your update.

 

 


Jwes_Lenovo



Did someone help you today? Press the thumbs-up icon below to thank them.!
If you find a post helpful and it answers your question, please mark it as an "Accepted Solution"! This will help the rest of the Community with similar issues identify the verified solution and benefit from it.


Using Browser Search to find your answers in Lenovo and Moto Community

Reply
Options

2895 Posts

06-13-2013

United States of America

11444 Signins

62811 Page Views

  • Posts: 2895
  • Registered: ‎06-13-2013
  • Location: United States of America
  • Views: 62811
  • Message 3 of 10

Re:21H1 Update FAILS in SAFE_OS phase at boot (error 0xC1900101-0x20017 )

2021-06-09, 15:15 PM

I managed to get time to work on the first of the three machines (M920t). And I have emerged victorious!  The "in-place upgrade" method once again saved me.  Of course I had to spend a good 1 1/2 hours accomplishing the objective, but at least in the end it was successful. The machine is now at 21H1.

 

NOTE: It is not necessary to actually build a USB install media on a flash drive in order to be able to RUN the SETUP.EXE from the root of the "drive".  The MS Win10 Media Creation page also offers the ability to create an ISO file instead on one of your partitions, presumably for use by a DVD burner program. And then instead of burning to DVD the ISO file can simply be "MOUNT'ed" (onto a virtual drive letter) and then SETUP.EXE run from that virtual drive. Or, you can use WinRAR or PowerISO or whatever to actually expand the ISO file on your hard drive and then once again run SETUP.EXE. In my case, I took the very simple and direct MOUNT approach and then RUN the SETUP.EXE... and spent the next hour watching while it ran.

 

However...

 

(1) Don't forget when you're finished to run DISK CLEANUP (from Windows Administrative Tools), being sure to first push the "clean up system files" button. And then check ALL THE BOXES, in order to delete ALL of the temporary and backup files produced by the system upgrade. This could free up 10-40GB of storage on your C-partition, so don't forget to do it.

 

(2) I maintain about 20 computers remotely for friends and family, including this M920t for a cousin. After running this upgrade to 21H1 I have now observed a new Windows "quirk" (i.e. BUG). I don't know which KB item might be responsible for it, but I've now seen it on maybe 3 of the machines I work on. The oddity is that the ENTIRE NOTIFICATION AREA IS NOT POPULATED WITH ANY ICONS!! It is entirely empty!  Note that I typically run with a double-high taskbar, which may or may not be relevant to the anomaly.

 

 

I have also discovered how to "solve" the problem, although it seems to return upon reboot. So I have to repeat my "solution procedure" all over again if I do reboot. Hopefully this issue will eventually be seen by others and reported to MS and ultimately fixed for real. But in the meantime here is the "trick" I've come up with.

 

First, I UNLOCK the taskbar (which I normally have locked at double-high) so that I can now shrink it back and forth between double-high and single-high and then back again to double-high, repeatedly until I'm finished (after which I once again LOCK the taskbar at double-high). It is this process of changing the taskbar from single-high to double-high or vice-versa which causes Windows to repopulate the notification area correctly.

 

So first I start with a shrink of the taskbar from double-high down to single-high. Miraculously, this process now causes Windows to populate the notification area! There are several icons for programs I want to close or exit, but at least all the icons are once again present in the notification area of this temporarily single-high taskbar.

 

 

If I now return the taskbar to double-high, magically the icons in the notification area are retained. If I were happy and wanted all the icons, I would simply LOCK the taskbar now.

 

 

Since I actually don't want all the icons I now begin the process of closing/exiting the several programs running in the notification area. But each time I close one program the new bug in Windows causes all the other icons in the notification area once again disappear!!

 

 

So now I once again must shrink the double-high taskbar back down to single-high, which once again causes Windows to correctly repopulate the single-high notification area with all the remaining program icons.

 

 

I'm going to repeat this process for a few more icons, so I now just close/exit the next program right here while the taskbar is single-high. Doesn't really matter when the close/exit is done, single-high or double-high. The new bug in Windows will vaporize the remaining icons in the notification area any time an icon gets closed/exited. And then resizing the taskbar from single-high to double-high or double-high to single-high will cause the notification area to once again get correctly repopulated with the remaining icons.

 

So, once again, closing the next icon while single-high will evaporate the notification area.

 

 

And then pulling it back to double-high will once again repopulate the notification area, so that I can continue with the close/exit process on the next icon.

 

 

Etc., etc., etc. As each re-populate of the notification area occurs (by going to either single-high from double-high or vice-versa) this allows me to close/exit the next icon. This is repeated until done. And then the taskbar is either already correctly at my desired double-high and properly fully populated, or not. So it may be necessary depending on how things end up after however many times this back-and-forth trickery is performed, to one final time again shrink down to single-high and then one final time back up to double-high, at which time the notification area finally has the correct icons present and is also fully populated and is also my desired double-high.

 

 

And now I can finally LOCK the taskbar, and begin normal Windows operation. Of course I'm prepared for having to repeat this entire procedure if I unfortunately must reboot.

 

This is a VERY ANNOYING new Windows bug, seemingly related to double-high taskbar but that may not be the culprit. It may actually be something unique to my own machines, and the particular programs whose icons are running in the notification area on those machines. Whatever the cause it now appears present in 21H1 on at least three of the machines I work on... all of which also have double-high taskbar as is my norm. When one icon gets closed/exited, Windows now seems to improperly repaint the notification area such that ZERO icons appear, instead of just the remaining icons. And re-sizing the taskbar from single-high to double-high or vice-versa seems to be successful in forcing Windows to now properly repaint the notification area of the new height with the correct remaining icons.

Reply
Options

2895 Posts

06-13-2013

United States of America

11444 Signins

62811 Page Views

  • Posts: 2895
  • Registered: ‎06-13-2013
  • Location: United States of America
  • Views: 62811
  • Message 4 of 10

Re:21H1 Update FAILS in SAFE_OS phase at boot (error 0xC1900101-0x20017 )

2021-06-10, 14:33 PM

I have now spent all night working to apply 21H1 to the remaining two (out of the earlier three) machines which had both failed to install 21H1 naturally through standard Windows Update when offered. And I once again used the "in-place upgrade" method successfully for both, utilizing the ISO method.

 

Furthermore, I also managed to apply 21H1 to the final two machines in my collection of about 20 that I maintain for friends and family. Neither was easy.

 

(1) The first one offered me 21H1 in Windows Update, and I pushed the "download and install now" button to see if that would succeed. It did not, and this time I took a screenshot of the error message:

 

 

I then reverted to the "in-place upgrade" method and it eventually completed successfully. Note that if 21H1 as offered by Windows Update actually does apply successfully, it is really quite quick. It's not a major update. In contrast, the "in-place upgrade" is typically a good hour at least if not more, depending on computer speed and internet speed. So while "in-place upgrade" is essentially 100% effective in getting the job done it is truly a very time-consuming method.

 

(2) The second machine (another Lenovo M910t) was more complex, more of a "production" machine used in a guardhouse office. The machine displays the output of 53 security cameras via Avigilon software, as well as handling the front gate security through BuildingLink software presented in a browser window and controlling six external USB security devices. The machine normally runs for each guard under a "user login" to Windows. I thought I could get away with my "in-place upgrade" as a second logged-in user on the machine, while still running the "guard user". I then changed my mind and "signed out" the "guard user", logging in as my "administrator user" to perform the 21H1 upgrade.

 

Well, after more than an hour, it eventually failed with the "fails in SAFE-OS phase" error message. Grrrrr!!

 

So hoping I could overcome this by trying it all again but this time only with the administrator active, I re-booted the machine and logged in as administrator only. No "guard user". And then I retried the "in-place upgrade" again (I already had the ISO file downloaded, so I just had to MOUNT it and RUN SETUP.EXE in order to start over), and this time it ran for another hour but eventually actually finished successfully.

 

(3) Interestingly, on the guardhouse M910t the "guard user" has a single-high taskbar, whereas my "administrator user" has a double-high taskbar. And interestingly my previously reported "disappearing icons from the notification area" symptom once again showed its ugly face but only on the double-high taskbar setup. ON the single-high taskbar user (i.e. it's never been double-high) the icons did not disappear but were all present normally.

 

So I'm now much closer to believing that the issue is definitely something new in 21H1 pertaining to populating the notification area in a double-high taskbar situation. There's something odd going on here, as it re-paints when my "trick" of alternating between single-high and double-high to bring back the icons before finally ending up with everything showing in the double-high taskbar notification area. It looks like some of the icons are overlying one another (perhaps calculating space required in the one or two rows or with the up/down arrow vertical bar), and then eventually sorting it all out so that the display looks correct. Definitely looks "stressed", and not right.

 

As it turns out, I saw the same "disappearing icons from the notification area" issue on 3 of the 4 machines I worked on last night. Only these 3 had external graphics cards in them (one with an AMD and  with NVidia). The fourth uses built-in Intel Graphics. So maybe that's relevant. Whatever the explanation, this is definitely a new issue first seen by me with this 21H1 update on many/most of the 20 machines I maintain, all of which have double-high taskbars.

 

 

So, it's been a rough and long couple of days. Each "in-place upgrade" takes at least an hour, along with another 10 minutes or so to do the "disk cleanup" to reclaim 30-40GB, so it's a very slow process. But in the end I've emerged victorious on all of the machines. All now running at 21H1.

Reply
Options

2895 Posts

06-13-2013

United States of America

11444 Signins

62811 Page Views

  • Posts: 2895
  • Registered: ‎06-13-2013
  • Location: United States of America
  • Views: 62811
  • Message 5 of 10

Re:21H1 Update FAILS in SAFE_OS phase at boot (error 0xC1900101-0x20017 )

2021-06-10, 15:50 PM

Looks like the issue with the strange behavior of the notification area (system tray) after 21H1 was observed previously during the "preview" period, as tied to KB5003214.

 

However I don't see 3214 installed. On the other hand, trial and error shows that is its KB5003637 which actually IS installed with 21H1, and that backing it out undoes the erratic system tray glitch.

 

Whatever, I'm sure Microsoft will "rush out" a quick fix for this, as it is a very very pronounced and "visible" anomaly that has a significant effect for everyone.

 

 

Reply
Options

2895 Posts

06-13-2013

United States of America

11444 Signins

62811 Page Views

  • Posts: 2895
  • Registered: ‎06-13-2013
  • Location: United States of America
  • Views: 62811
  • Message 6 of 10

Re:21H1 Update FAILS in SAFE_OS phase at boot (error 0xC1900101-0x20017 )

2021-06-11, 17:25 PM

Final five more machines updated to 21H1 last night, or at least tried.

 

(1) One old/slow/small Toshiba laptop wasn't showing 21H1 in Windows Update. I decided to try using the first-level "Windows Update Assistant" method from the MS Win10 Download site.  I hadn't used this approach recently so I was curious if this theoretically easiest and quickest approach would work.  This approach simply forces the initiation of Windows Update as if it had occurred naturally.

 

Well, it failed.  Same "Update FAILS in SAFE_OS phase" error at the end of a VERY VERY VERY LONG AND SLOW PROCESS.

 

I then ran "disk cleanup" to guarantee at least 30GB of free space, just to eliminate that possibility for the failure. Turns out there was 75GB free, so that isn't the issue.

 

I will retry this machine again overnight tonight, this time using the 'in-place upgrade" method.

 

(2) ALL FOUR OTHER MACHINES FAILED, USING THE IN-PLACE UPGRADEl  Very surprising. I had pre-run "disk cleanup" on all of them to ensure 30GB, but nevertheless all four of these machines did NOT run successfully. Again, "Update FAILS in SAFE_OS phase" result. This is the same curious results as happened with the guardhouse M910t yesterday on the first attempt, but when I repeated the "disk cleanup" and then "in-place upgrade" a second time, well this second time it was successful.

 

So on all four of these machines I did the same thing. Repeated the "disk cleanup" pre-step, and then just repeated the MOUNT on the already downloaded ISO file and then RUN SETUP.EXE from the root.  And amazingly, all four of these machines NOW COMPLETED SUCCESSFULLY ON THIS SECOND TRY, all four having just failed to complete on the first try.  Go figure!

 

(3) I checked in on some of the remote machines updated recently, and sure enough the "system tray glitch" issue (scrambled or disappeared icons) had reappeared for whatever cause. On one of them I'd yesterday decided to BACK OUT the KB5003637 Windows Update which is the "cause" of the problem. The backing out of the update did, indeed, eliminate the system tray issue (of course also backing out whatever else was fixed by this patch).

 

Unfortunately the just backed-out update got automatically reapplied overnight by Windows Update!  So the patch is once again present today, as is the same system tray glitch!

 

There's no way to prevent individual updates from being applied in Win10, that I know of. So the best I can do is back it out again and "pause" Windows Updates for one week, to defer the re-application by Windows Update. Maybe MS will have a true patch for this problem by then. We shall see.

 

 

This 21H1 upgrade, minor as it supposedly is, sure is causing me much lost sleep.

Reply
Options

2895 Posts

06-13-2013

United States of America

11444 Signins

62811 Page Views

  • Posts: 2895
  • Registered: ‎06-13-2013
  • Location: United States of America
  • Views: 62811
  • Message 7 of 10

Re:21H1 Update FAILS in SAFE_OS phase at boot (error 0xC1900101-0x20017 )

2021-06-12, 16:17 PM

Final two machines now completed. The "in-place upgrade" method was used on both, preceded by first doing a "disk cleanup" to ensure maximum free space was available. On one of the machines (M93p) the C-partition only had about 30GB free, which is actually insufficient to hold the "previous Windows system" that gets replaced.  So on this machine I also used Partition Wizard to shrink the partition adjacent on the right by 30GB, and then expand C by this now available 30GB.

 

I'm now sure there is a strong relationship between not having enough free space when using this method and the "update fails in SAFE_OS phase" error. You'd think the process would check first before beginning, to ensure adequate free space is available, but it doesn't appear to do so. Anyway, I now had 60GB free on the M93p C, and 75GB free on the VERY SLOW Toshiba laptop, before beginning.

 

And, happily, BOTH COMPLETED SUCCESSFULLY ON THE FIRST TRY. And, as expected, after the upgrade the finishing "disk cleanup" reclaimed about 35GB (most of which was the "previous Windows version" files). That entire Toshiba process from start to finish took about 5 hours! But it's now done.

 

Of course the system tray glitch still persists. Interestingly Microsoft pushed out an update for 21H1 systems last night, but it did not include a fix for the glitch. Actually the glitch didn't come from 21H1 but rather from KB5003637, which was a separate update published around the same time. Note that you can only back out this update (and "pause Windows updates for 7 days" to prevent it from immediately getting reinstalled overnight) BEFORE YOU DO THE DISK CLEANUP! Once you do the full disk cleanup and remove all Windows Update recovery files, you no longer have either history nor recovery from KB5003637. It's in for good, and the glitch is "permanent" until MS fixes it. 

 

 

Reply
Options

2895 Posts

06-13-2013

United States of America

11444 Signins

62811 Page Views

  • Posts: 2895
  • Registered: ‎06-13-2013
  • Location: United States of America
  • Views: 62811
  • Message 8 of 10

Re:21H1 Update FAILS in SAFE_OS phase at boot (error 0xC1900101-0x20017 )

2021-06-14, 6:00 AM

One more stray machine updated today.  Another M93p but this one with original HDD spinner instead of SSD. So it's slower. Plenty of free space, but I still did a "disk cleanup" before starting.

 

No 21H1 offered by Windows Update so I gave "Windows Update Assistant" another try, thinking that might be faster than the full "in-place upgrade". Unfortunately, it was not fast at all. Still took a long long time to complete.

 

The awful news was that although it sure looked like the whole thing was working perfect, at the end of the long process when it rebooted and I logged in, remarkably NOTHING HAD HAPPENED!!!  It was still at 20H2.  There were no error messages of any king thoughout the entire process. Looked completely normal, and success seemed promised. And yet apparently something went wrong and the updater must have decided to back things out entirely. So the first hour was a complete waste of time.

 

Then I did another "disk cleanup", to get rid of everything left over from the first failed Windows Update Assistant. And then I began the "in-place upgrade".

 

And this time, SUCCESS. Yes, another hour+ (slower than the other machines with SSD for C-partition) followed by another 15-minute "disk cleanup", but I didn't care. I was now at 21H1.

 

I realized that this M93p has a second "mate" M93p machine, which I will get to tonight. Very tiring, but it must be done. I will simply start with the "disk cleanup" and then go right ahead with "in-place upgrade" (although even that may have to be done twice before succeeding, based on past experience).

 

NOTE: there is an inherent advantage to just going ahead and performing the "in-place upgrade", regardless of whether or not Windows Update has offered 21H1 (which seems to be the quickest and most reliable method for getting there and an indicator for whether the outcome of that first try will be a success). The effective full re-install from scratch of a Win10 while retaining user data, apps and customizations, thus returning full out-of-carton integrity and cleaning up any corruption or detritus in Windows is a real benefit. It's like deciding to do a full reinstall of Windows to "clean house", but without having to actually then spend the time reinstalling all apps and recustomizing. It's only Windows itself that has been "completely replaced with a shiny new 100% clean working version", right out from underneath the previous system environment, saving you many hours or days of otherwise required subsequent "production build-out".

Reply
Options

2895 Posts

06-13-2013

United States of America

11444 Signins

62811 Page Views

  • Posts: 2895
  • Registered: ‎06-13-2013
  • Location: United States of America
  • Views: 62811
  • Message 9 of 10

Re:21H1 Update FAILS in SAFE_OS phase at boot (error 0xC1900101-0x20017 )

2021-06-14, 16:37 PM

Will somebody please make arrangements to return to my life the total of 8 hours spent running the 21H1 "in-place upgrade" TWICE last night on this M93p, in order to emerge victorious?

 

This M93p is a small one, only 8GB of RAM. Originally it was a Win7 machine and 8GB was adequate. With Win10 8GB isn't really adequate, although the machine will certainly run. In fact it runs pretty well, normally. But when installing Windows from a "virtual 4GB installation media DVD in memory" I would imagine the paging rate is rather extreme. And EACH of the TWO installs I had to run (because, of course, the first one failed after 2 hours with "update FAILS in SAFE_OS phase", requiring me to repeat the "disk cleanup" and then run SETUP.EXE all over again( took about 3 hours.

 

If I had it to do over again, I'd probably expand the ISO onto disk and run SETUP.EXE from disk, instead of MOUNT the ISO and running it from virtual memory.  Probably would have put less pressure on the HDD spinner for paging.

 

Anyway, it's finally done. And successful. Only took a re-run of the install to accomplish this. It's not clear why the install works the second time but not the first time. But all it takes is fortitude, and lots of time, and it's possible.

 

Although I know it's not going to happen, this machine really should have another 16GB installed in it. I'm sure it would make a huge difference, as it has on a number of other machines I've added memory to for friend/family after upgrading all of them from Win7 to Win10. I even upgraded an HP AIO from 4GB to 16GB, and saw an amazing improvement.

 

Time again for sleep.

Reply
Options

2895 Posts

06-13-2013

United States of America

11444 Signins

62811 Page Views

  • Posts: 2895
  • Registered: ‎06-13-2013
  • Location: United States of America
  • Views: 62811
  • Message 10 of 10

Re:21H1 Update FAILS in SAFE_OS phase at boot (error 0xC1900101-0x20017 )

2021-06-22, 10:00 AM

Interesting observation: on the handful of machines where 21H1 was actually offered to me by Windows Update, going ahead to let it install saw maybe the fastest "feature update" I've ever witnessed. Maybe a minute or two, and the whole update from 20H2 to 21H1 was finished. Period.

 

But on all the other machines which did not offer 21H1, or for which the update was offered but it didn't succeed for one reason or another and thus for which I was forced to  revert to one of the Windows in-place upgrade methods, well those full reinstalls took 1-3 hours to complete, possibly needing to be done TWICE before the second attempt was successful where the first attempt had failed.

 

Note that the "in-place upgrade" isn't a simple pure fast and quick from-scratch cold Windows install. It has to work around retaining existing installed apps and customizations, retain all user data, back up components that are being replaced (thus producing maybe 30+ GB of backup files), etc. All this accounts for the 1-3 hours required instead of maybe 10 minutes tops to do a true from-scratch cold Windows install.

 

So, if you do get offered 21H1 by Windows Update, consider yourself lucky. It will most likely be painless and quick, and all over in under 5 minutes. But if you're forced to or volunteer for a manual in-place upgrade then be prepared for 1-3 hours, maybe times 2!

 

Reply
Forum Home

Community Guidelines

Please review our Guidelines before posting.

Learn More

Check out current deals!

Go Shop
X

Save

X

Delete

X

No, I don’t want to share ideas Yes, I agree to these terms