Updating to Windows 10 — 3
Part 1: Updating to Windows 10 — 1
Part 2: Updating to Windows 10 — 2
Unanswered at this point is how to create a Windows 10 USB recovery drive when a Windows 7 Recovery partition exists. Curiouser and curiouser. Oh wait, that is not supposed to happen. The Microsoft presumption is Windows 7 was deleted when updating to Windows 10.
After the backup I copied the C: partition to a logical partition location. I reformatted the original C: partition to avoid collisions with the same UUID. GParted somewhat supports modifying the UUID of an NTFS partition, but I skipped that option. There is no manual method and the change is performed programmatically.
I updated GRUB and rebooted.
The result was a recovery/repair notice that \windows\system32\winload.exe is missing or contains errors. I rebooted into a command prompt with the Windows 10 Repair DVD. I ran
bootrec /rebuildbcd. I rebooted. No luck. I again rebooted with the DVD. I ran
bootrec /scanos to learn the temporary drive letter assignment and then ran
bcdboot x:\windows /s e:. No luck.
I restored the affected partitions and rebooted with the Windows 10 repair DVD to update the restored Windows 7 System Reserved partition. That struck out too. I temporarily assigned an S: drive letter to the System Reserved partition. I opened a terminal window and typed:
bcdboot c:\windows /s s:
I removed the temporary drive letter and rebooted. The system booted into Windows 10.
My next attempt to test my mental instability was to copy the C: partition without touching the System Reserved partition. I restored the Windows 7 partition. In Windows 7 I ran
msconfig to create a simple boot menu. I rebooted and then was able to select Windows 7 or Windows 10. I selected Windows 10.
Same Windows 10 boot splash logo. Yay! Same black screen of death for the login screen. Boo!
Enough of this nonsense.
To ensure integrity I restored Windows 10 back to the C: partition location. I repaired the BCD. I rebooted and verified both user accounts were intact. No black screens of death.
I am using GRUB and intend to run the Windows systems in VMs. I have backups and Windows 7 and Windows 10 installation and repair DVDs. I decided I did not need the original Windows 7 OEM Recovery partition.
Using a live Ubuntu MATE USB flash drive, I used gparted to backup all partitions, including the Ubuntu MATE partitions. I wiped the disk logical partitions to allow me to resize the original Recovery partition. I restored the original System Reserved partition, the Windows 7 partition to the original C: partition location, and the Windows 10 partition to the resized Recovery partition location. Both Windows 7 and Windows 10 were on primary partitions. I restored the Ubuntu MATE partitions. I updated GRUB.
Consistent with this stumbling, bumbling journey, Windows 10 again refused to boot. Windows 7 was fine.
I swapped the Windows 7 and 10 partitions, allowing the persnickety 10 to remain in the original C: location. I hoped that Windows 7 would be more tolerant and forgiving of being moved.
Not to be. Windows 7 booted, but after logging in I saw a dialog similar to:
“slui.exe: The procedure entry point RtlReleasePath could not be located in the dynamic link library ntdll.dll.”
Having used the Microsoft virtual machine appliances, I knew that slmgr was the software license manager. I then speculated that slui.exe was the software license user interface. A quick check of the web revealed this is the executable to validate the license activation.
Not really important though. I had seen this kind of error message dialog before, more than 15 years ago when I created a dual boot Windows NT4 system using two instances of NT4. Long forgotten memories rose. I realized the problem was the way the horrible Windows registry saved drive letter information. As I had moved the Windows 7 partition, Windows 7 now was trying to use the Windows 10 partition as the C: drive.
The drive letter approach is a nightmare.
I remembered I had to edit the Windows 7 MountedDevices registry values. To do this required booting into Windows 10, launching regedit as administrator, selecting the HKLM hive, then loading the HKLM hive from the Windows 7 partition, which is named \windows\system32\config\SYSTEM. I edited the values and key names using the already corrupted Windows 7 partition. I unloaded the hive.
I rebooted and Windows 7 never complained. Yet the damage was done. The corrupted system no longer was activated.
I rebooted into Ubuntu MATE to use gparted to again restore the Windows 7 partition from the cloned drive. I repeated the registry hacking on the restored partition.
After some additional go-rounds with the Repair DVD I finally booted into Windows 7.
Backups sure are nice. Possibly even useful.
A bump to my final solution was somehow Windows 7 decided I needed to restore files. On every login I received the following message:
“Recovery completed. Do you want to restore your user files?”
I found only one search result that provided a solution: delete the zero-byte file
C:\Recovery.txt. I do not know how this file gets created.
At least this journey was consistent — kicking and screaming all the way.
I recreated the VMs with the new partition layout. I removed the two Windows boot options from the GRUB menu.
After all of this hacking, cussing, and hissing, I was reminded of the TV show The A Team. In a typical episode there was all kinds of guns been used and bullets flying all over the place, but in the end nobody got hurt or killed. Hannibal Smith would yank a cigar from his pocket and say, “I love it when a plan comes together.”
I succeeded but I paid a price for the effort. The entire journey was not fun. Full of stress and confusion. The trial and error required several days. All because a product key would not work. Not knowing Windows as well as I know Linux contributed to me spending much of my time in the dark.
boot.ini was so much simpler and saner than this BCD nonsense.
The frustrating part about all of this is the user is thoroughly blocked from knowing what is happening. There is no ability to boot to a pure command line. No ability to ssh. There is no meaningful feedback. Users are left to guess. Everything is a black box.
Proprietary and closed source software is not nice.
Searching the web and browsing Windows forums throughout all of this indicates that despite billions of dollars, Windows can be just as user hostile as Linux systems. The geeks and technically savvy survive. The non technical users drown.