Over the past few weeks, I have had an interesting, ongoing fight with one of my laptops. All my life, I’ve never fought as much with a single device, just trying to get an operating system to work as expected. First, the problem came from the Windows Admin Center (WAC). It caused a GSOD every time it launched (see this story’s title image). WAC has become an essential tool for me, I don’t want to even think about using and managing my devices without it. I relayed an earlier installment of this adventure, about the “start of this fight” in this Win10.Guru item: War story – Insider woes
OK, it was time to clean install anyway. I decided to build a new deployment image of build 18965 in Hyper-V, and deployed it to my problem laptop using MDT. Things initially looked good, but a closer inspection showed I had neither audio nor video. A subsequent repair install failed, as did an in-place upgrade to build 18970. Time after time, this is what I saw at the end of the trail:
Literally, and I am using that word fully knowing what it means, for the next two weeks or so I did nothing else than test various deployment, install and upgrade scenarios. Of course, I took breaks to get some fresh air, eat and drink and sleep, but other than that, I spent my waking hours trying everything possible I could think of. I put in some quite long days. In fact, one night at 2:30 AM I realized that I had started my day at 4:30 AM the night before (22 hours). I saw this up to ten times a day:
I could not give up. I refused to believe that a 3 year old laptop (HP ProBook 470 G5) would be too old to run modern Windows 10. This is the best laptop I have ever had, and I wanted to make it work. New builds were released, my testing moved to build 18970, then to 18975, 18980, 18985 and now finally to 18990. Each and every time, upgrade installs didn’t work. Clean installs and deployments always had this or that broken. Either it was audio and video, or the Store and WAC. Office refused to activate, and so on. Over the four builds before 18990, I could not install two extremely important tools, in addition to WAC causing GSOD and other issues:
Finally, I found a clue. Although Device Manager had not shown any firmware issues, nor had I any boot issues, Windows update offered a firmware update after I restored an 18865 image. Checking all recent Macrium images, I noticed that each and every build since 18936 showed a firmware error with an update available, whenever an image was restored. I’d been left in the dark, because Windows had not shown that error and its associated update when each image was created. I had to test this.
I deployed, once again, a clean 18965. I updated it fully, with audio and video drivers not working as I already knew would happen, refusing to accept automatic or manual driver updates. Now the firmware was OK, with no errors shown at boot, UEFI settings or in Device Manager. At this time, no firmware update was offered. Only some 20 minutes after getting to the desktop on a clean deployment, I created a Macrium image, and restored it immediately. After a fast restore, quarter of an hour later I was back on the desktop, and now the firmware update was offered, and Device Manager showed the device not working:
However, the firmware update was not applied after the restart. Back on the desktop it was again offered via Windows Update. Notice the date of that update (mid-July), and the date for the Intel display driver (mid-August). I was doing this mid-September.
Once again, I went through my recent Macrium images, and finally found out that build 18936 was the latest where this update was not offered after image restore. Now back in 18936, I performed a manual firmware update, and was pleased to see that the new firmware was successfully applied. I thought that now I could finally upgrade. I wish! Yet one more time, Windows Update failed to install an in-place upgrade to 18985, or an ISO in-place upgrade to any other build newer than 18936.
Macrium to the rescue! I thought that now that the firmware was updated, I could create a new system image, and simply upgrade it using Macrium viBoot. That method has saved my behind several times. When trying this approach, an important thing to remember is not to connect the viBoot VM to a network:
This way, any possible host hardware devices that could cause the upgrade to fail will be ignored, not updated. When on the desktop for a viBoot VM based on your Macrium image, simply mount the latest Fast Ring ISO image, and run the upgrade from that:
I upgraded the viBoot VM without issues to the latest build 18990, saved that upgraded image, and restored it to my laptop. Everything is working now. No GSODs; audio, video and all other devices working; firmware up to date; Store working. No issues whatsoever. Even repair install worked; as you know, a repair install is exactly like an in-place upgrade but using the same version and build than the underlying OS. This is, to me at least, a strong indicator that my upgrade issues just might be over.
This was, as I said in the beginning, the longest fight ever I have had with a single device. I feel that I won this fight, although the war might still resume one of these days. That remains to be seen. Stay tuned!
Author: Kari Finn
A former Windows Insider MVP, Kari started in computing in the mid 80’s writing code for VAX / VMS systems. Since then, he’s worked in a variety of IT positions. He specializes in Windows image capture, customization, repair and deployment as well as Hyper-V virtualization. Kari is a proud Team Member at number #1 Windows site TenForums.com.