Updating to Windows 10 — 2
Part 1: Updating to Windows 10 — 1
After installing Windows 10 directly to the Windows 7 partition, both my admin and standard user accounts were unscathed in any way. I logged into both accounts and further disabled Windows 10 data mining and privacy related options.
I had to temporarily reconfigure my server dnsmasq configuration that blocks questionable Microsoft domains. The activation mechanism continually failed until I allowed those URLs.
Yet this is not what I wanted. I wanted to reserve the Windows 10 activation and then return to using Windows 7. Nonetheless, at least I now had an activated Windows 10 system.
I moved the updated partition to a logical partition location on the same disk. I wanted to restore the Windows 7 partition. Yet then I wondered whether I could run that Windows 10 partition from that logical partition.
After a lot of reading on the web I decided I needed to break the link between the C: partition and the System Reserved partition. Doing that required booting into Windows 10 and running one command:
bcdboot c:\windows /s c:
I used the Windows disk manager to mark the C: partition as active rather than the System Reserved partition.
I rebooted into Ubuntu MATE and copied the partition to a logical partition. A flaw in this plan is the copied partition has the same UUID as the C: partition. Restoring the Windows 7 partition to C: would not help because of the same UUID. Another flaw is when I restored the Windows 7 partition from the clone drive I restored the System Reserved partition too. I should have left the updated System Reserved partition until I got the new Windows 10 logical partition working and severed from the System Reserved partition.
Despite learning these bumps I somehow got the Windows 10 partition booting from the logical partition location. Emphasis on the word booting.
That is when I discovered the infamous Windows 10 black screen of death. In my case there was an oscillation between complete black and almost black, indicating something on the system was trying to function but failing.
The Windows 10 logo and epileptic spinning balls appeared during the boot process. The screen went dark when the login background should have appeared. No amount of reading around the web helped. I could not get into Safe Mode. All related tutorials are written with this expectation and the presumption is a failed video driver.
I was doing all of this directly from the hard drive and not within a VM. I had not progressed to the point of virtualizing the new system.
My understanding is once Windows 10 is activated, the system information is stored on Microsoft servers. Thus, users should be able to perform clean or fresh installs and never worry about reactivation. Apparently my understanding is incorrect.
Because the new installation seemed broken, I restored my original Windows 10 clean partition. Despite having had successfully activated Windows 10, the activation from within the virtual instance failed, requested a product key, and again refused to accept the Windows 7 product key.
My guess for the Windows 7 product key failing is the key is OEM rather than consumer. Or the sticker on the case, from which I grabbed the product key, is obsolete because the system is refurbished.
I restored the broken Windows 10 partition to the C: partition location. I booted with a Windows Repair DVD I had created. The system was able to repair itself. I was able to boot into Windows 10. The infamous black screen of death was gone.
I understand that moving a partition affects the boot process. I would expect to see related booting complaints. I would not expect a black screen of death.
After restoring the partition, my first point of business was to disable fast boot. After reading about the feature I wondered whether that could cause the black screen of death.
Next point of business was to create a USB Recovery Drive. I rebooted to test the USB drive. The Windows 10 logo appeared and then the system continued with the Windows 7 “Starting Windows” boot splash. Does the Windows 10 Recovery Drive use Windows 7 technology? Actually, yes.
Not yet understanding what was happening, when prompted by the dialog I deleted the Recovery partition, believing the word partition actually referred to a temporary file inside Windows 10.
Next I tried logging in to Windows 10 with my standard user account. No such luck. There were no error messages. I logged in with my admin account and changed the password anyway. Same results. I saw the Welcome message, but I could not log in. I configured the system to auto-login with the standard account and rebooted. The auto-login process started, there was the Welcome prompt, and then returned to the login screen.
The standard account was working before the black screen of death nonsense.
With the admin account I opened the event viewer. I found a Winlogon warning that the login process was looking for D:\windows\system32\userinit.exe. D:? I opened regedit and changed two occurrences of D:\windows\system32\ to C:\windows\system32\. I logged out of the admin account and tried again logging in as standard user.
Don’t ask me how that happened. I have no clue. Perhaps a guess. Possibly when I copied rather than moved the C: partition to a logical partition Windows 10 got confused with the two partitions existing at the same time. Windows, in its weird design, automatically assigned a D: letter to the logical partition.
The next irritant was the file explorer always opened upon logging in with either account. That never happened previously. More digging around the web revealed I should look in the registry for a double userinit.exe entry in the Winlogon key.
Fixed that. I wonder whether the two bugs were related.
I restored the system to not auto-login.
Back to the original focus of this journey. Getting Windows 10 installed and moved to a logical partition.
Stubborn, insane, or a glutton for punishment, I do not know. I decided to again try moving the C: partition.
I repeated the bcdboot command and ensured the Windows 10 C: drive was active. I rebooted into Ubuntu MATE, updated GRUB to boot from the C: drive UUID rather than the System Reserved partition. The system booted fine.
I tried a stiffer test. Using the Windows disk manager I reformatted the System Reserved partition. I confirmed the formatting by viewing the contents. I rebooted into Windows 10. This confirmed the boot management files were on the Windows 10 C: drive.
Could I now move the partition to a logical partition location?
I rebooted into Ubuntu MATE.
I made another backup of the partition to a third drive. This is when I noticed I no longer had a Windows 7 Recovery partition. Remember that dialog prompt? This explains why the USB drive booted into Windows 7. The USB Recovery Drive feature used the Windows 7 Recovery partition to create the USB drive. This explains why the process wanted an 8 GB USB drive — the Windows 7 Recovery partition is 7.95 GB.
I rebooted into Windows 10. I resized the C: partition and created an empty partition where the Windows 7 Recovery partition once resided. I would restore the partition later with my cloned drive.
Backups sure are nice. Possibly even useful.
Posted: Category: Usability Tagged: General, Windows
Next: Updating to Windows 10 — 3
Previous: Updating to Windows 10 — 1