News Stay informed about the latest enterprise technology news and product updates.

Win10 Stumbles Badly on Surface During Post-Install App Additions

Drat! I wrote too soon, or too optimistically, in yesterday’s blog post about the contortions necessary to bring my Surface Pro 3 into “Windows 10 land.” After getting more or less everything working from the factory reset followed by the Windows 10 upgrade, my SSD disappeared from Windows’ ken after adding support for older .NET versions (2.x and 3.x) as required to run the Windows DriverStore Explorer (aka rapr.exe). What followed next was a comedy of errors in figuring out how to boot from a recovery UFD (don’t turn off BitLocker encryption, but do turn off TPM, and make sure either the dock or the built-in USB ports are enabled for booting) which included finding the recovery keys for BitLocker for that failed Surface install (use the MS FAQ page for a link to a login to grab any such keys you might need, unless you’re managing them on your own domain controller, in which case you don’t need me to tell you how to do that).

After all kinds of further contortions — and a fair amount of salty language — I realized my only out was to perform a clean install of Windows 10 on the damaged system, which further necessitated burning one of my 5 MSDN Windows 10 Pro keys so as to be able to get the unit up and running. For a future blog post, I’ll describe what’s involved in capturing the upgrade key from the backup image of the initial installation that remains at my disposal. This should let me recapture and re-use the key that Windows granted for the initial and apparently successful upgrade install that went down in flames mid-afternoon yesterday. To make a long and probably unbearably tedious story short, I didn’t finish rebuilding the system until about 11:20 last night, but I did take a couple of hours off to help the Boss cook dinner and consume the fruits of our labors during that period, too.

Here’s what I learned in setting that system back to rights after the dread “boot drive inaccessible” blue screen bit me on the hindquarters:

1. The resulting install still got all the drivers right at the end of the process. However, investigation with DriverStore Explorer after that install was done resulted in my removal of over 100 duplicate or obsolete drivers from the driver store, including more than 60 copies of various Intel ATA/ATAPI drivers, more than 20 Intel USB drivers, and a variety of other miscellaneous but unnecessary elements therein. Total space recovered as a result was more than 4 GB. Given the high number of Intel drivers involved, I’m inclined to blame the IntelRST.exe program rather than the OS install for that portion of the excess. I’ll experiment on future installs to confirm or disprove this hypothesis.
2. For the first time I can recall, the startup repair function in the repair installation fork of the Windows Install UFD (and DVD) functionality failed to find and/or fix the missing boot drive when run, once I puzzled my way into making that happen. This led to an attempt to reset the initial installation and ultimately to a clean install of Windows 10 using the aforementioned MSDN key.
3. Because part of my recovery efforts included a (failed) reset of the initial OS install, followed by a clean install of a brand-spanking new OS that didn’t involve rebuilding the SSD partitions and their contents from scratch, I found myself with two Windows.old files after all was said and done (Windows.old was 19.5 GB, and Windows.old.000 was 17.5 GB). For some reason or another CCleaner didn’t detect and thus couldn’t clean up those folders, so I turned to WinDirStat instead, which got rid of Windows.old.000 for me, and used Disk Cleanup for Windows.old — WinDirStat balked at getting rid of WinSXS in that folder, so I had no choice but to turn to the built-in utility — to reclaim that wasted drive space (I made three backups along the way to finishing the system rebuild, so can dig into those folders should I need to do so).
4. Final size of my on-disk OS partition including all applications I like or need to use  was 33.3 GB, around 40 GB smaller than where I started before driver cleanup and removal of the Windows.old folders.

The final size of the Boot/Sys drive is a svelte 33.3 GB; note the yellow warning symbol that denotes BitLocker is turned off.

5. Because of publication requirements, I have to shoot screencaps against an all-white background. Interestingly Personalization no longer offers plain white as a solid color option in Windows 10. To produce an all-white background, I had to provide an image (I captured a big chunk of a window background, saved it as a PNG file, then chose the “Picture” option and browsed to that image, to produce the desired results).
6. It took me a while to figure this out, but I finally determined that the unlock icon on the boot drive originates from turning BitLocker off during the install process. Once the encryption is turned back on the yellow warning symbol affixed to the drive icon goes away.

Concluding Unscientific PostScript: In commenting on yesterday’s post, Stu Sjouwerman described his recent Dell desktop Windows 10 install experience as resembling a “dog’s breakfast.” Upon further reflection on the Surface issues that popped up, I’m feeling a bit less enthusiastic about the process myself. However, I still have 6 more machines to upgrade, so I’ll have plenty of further grist for this mill in the posts here still to come.