Messed up laptop: Windows 10 recovery

[aum]

Messed up laptop: Windows 10 recovery

 

All right. Just a few days back, we talked about my messed-up laptop and the subsequent recovery of the KDE neon instance in its eight-boot Windows-and-Linux setup. As it turns out, various distributions would not boot because they were configured to mount a non-existent partition. This happened because new Linux systems use a sub-optimal way of marking devices, with meaningless, human-unreadable UUID strings rather than simple numbers.

 

Well, we need to fix the Windows 10 instance as well. Here, the issue was kind of similar. Windows 10 would start booting, then there's be a message about diagnosing PC, automatic repair - and then, predictably, the automatic repair would fail. In the previous article, we've already established that the Windows 10 partition was healthy, all the data was there, so I didn't want to do any reset or such. Let me show you how I gracefully fixed this rather annoying issue.

Problem in more detail

Come the pale blue Windows 10 recovery console screen, it read:

 

The automatic repair couldn't repair your PC.

Press "Advanced Options" to try other options to repair your PC or "Shut Down" to turn off your PC.
Log file: C:\Recovery\WindowsRE\Winre.wim\System32\Logfiles\Srt\SrtTrail.txt.

 

Like a good techie, I decided the best course of action is to go into advanced options, start a command line prompt, and then navigate to the log file and read the contents. Except this file wasn't there. We shall explore this soon.

 

At this point, I thought the recent system image recovery test I did may be partially or wholly responsible for the issues. So maybe Windows 10 bootloader needed fixing. I was doubtful, especially since I was using the Linux bootloader to control the sequence, but in order to eliminate the obvious, I decided to try the simple bootloader fix:

 

bootrec.exe /rebuildbcd
bootrec.exe /fixmbr
bootrec.exe /fixboot

 

I encountered problems right away. If I ran this command from the Windows 10 USB thumb drive, it would find nothing. Again, there's a reason for this, we will get there. If I ran this from the recovery console, it would find one, but it referenced the D:\ drive rather than C:\ drive, and when I tried to actually add the entry, the command would complain that it couldn't complete the operation:

 

The system cannot find the path specified.

 

And the last command would result in the following error:

 

Access is denied.

 

The fact the log file was supposed to be under C:\ but it wasn't there, and the fact bootrec.exe had found an operating system under D:\ led me to believe that perhaps the drive letters were not assigned correctly, and that I needed to fix that.

 

So let's head into the solution.

Solution 1

I launched the diskpart tool from cmd. This is the disk manager tool you would normally use in Windows, which means a nice GUI. Here we need to use the command-line, uhm, commands, instead. If you're not sure what to do, you can just type ? to get an idea of different options and flags. So first, let's check the volume letters.

 

diskpart
list volumes

 

In my example, I noticed that the C:\ drive was wrongly assigned. So I changed that. If the letter "C:" is taken, then you need two steps, first to assign the drive holding to a free letter, and then assign the correct drive. For example (ignore the actual numbers, because they will uniquely depend on your setup):

 

select volume 2
assign letter=(something that is not C):

select volume 5
assign letter=C:

 

I went back to running bootrec.exe, and I made progress, but the system still wouldn't boot.

Solution 2

At this point, I was certain the issue was not with the bootloader. So it's time to move up, to the next step in the boot process. In this case, the boot image, which is located on the EFI partition. Perhaps, for whatever reason, this file was corrupted somehow, and needed to be rebuilt.

 

I booted into the recovery console, and ran the exercise with diskpart again, only now, there were two steps. First, the right volume being mapped to C:\. Second, I made sure I was working with the EFI partition. Please pay careful attention to the drive letter. If you're afraid of messing up, you can then select the volume, assign it a new letter, and then proceed to rebuilding the boot image. If the letters are correct, you can skip this.

 

diskpart
list volumes
# select the partition that corresponds to "C:"
select volume X
assign letter=C:
# select the EFI partition (FAT32, with the boot flag and often hidden)
select volume Y
assigned letter=F:
exit

 

I went with the letter F for EFI. You can choose any one you want. Now, the boot image repair step:

 

bcdboot.exe C:\Windows /s F: /f UEFI

 

What do we have here? We run bcdboot in the following manner:

 

• Source - initializes the system partition by using BCD files from C:\Windows.
• /s - specifies the letter of the system (EFI) partition.
• /f - specifies the firmware type.

 

Both /s and /f are optional. Check the technical reference for details.

 

Once this step was complete, I rebooted, and Windows 10 launched fine, with everything intact. All the other Linux distributions were working, the GRUB2 remains untouched, and there's no data loss.

Conclusion

I found this exercise quite frustrating, but also rather enjoyable. When it comes to deep technical stuff, Windows behaves pretty much like Linux. And it is equally vague and non-resilient when it comes to system boot errors. I wonder why the automatic repair couldn't do what I've done. There's nothing special or magic in the sequence of steps I took. Also, the logs aren't easily accessible. Why not allow the user to read them on the first error screen, right there?

 

Another issue is, when there are discrepancies in how the system expects things to be - like drive letters, you suddenly encounter half a dozen other issues that only distract you. The solution isn't too difficult, but you waste time troubleshooting nonsense. That's modern software for you. Well, I hope I did clarify ever so slightly what you could potentially do if you're multi-booting, and you have issues starting Windows 10. If the data is intact, start simple, and work through the boot sequence, step by step. As to philosophy, it's the same as Linux. The future ain't rosy, so enjoy what little technical freedom you have before it all becomes abstract nightmare.

 

Cheers.

 

Source