Windows Sorting out a repaired MBR's side-effects

Hi all, long time no post. This is a weird and slightly technical one - if you don't know what MBR is or have experience cloning drives it probably won't make much sense, just to set the bar. I wanted to see if anyone had any thoughts or similar experiences and could explain why this happens. I've experienced it many times but never figured out precisely what it's all about.

Quick TL;DR of the situation:

- Had a BIOS/MBR install of Windows 10 on a BIOS-based board.

- Installed GRUB2 as part of Ubuntu's auto-install; worked fine, GRUB replaced the bootloader and multibooted both happily.

- Removed Ubuntu's partition (also resized w10's partition to absorb empty space); Windows 10 would then not boot, obviously. GRUB2 seemingly removed along with Ubuntu (?)

- repaired the MBR using the wonderful Linux-ecosystem tool boot-repair, Windows boots fine again, no trace of GRUB2; presumably back to normal MBR Windows bootloader.

However, I don't know precisely what boot-repair did in technical terms, and rebuilding the MBR in this way has had strange side-effects. Cloning and backup utilities such as Windows Image Backup and EaseUS Todo Backup no longer know what to make of the boot disk, and refuse to clone or back it up while it's online (i.e. booted up on that installation), giving generic 'unable to access volume' type errors. System Restore points can no longer be configured or created on the volume. It can be cloned offline.

I tried the ol' faithful MBR boot disk fix: reinstalled Windows afresh, then cloned the troublesome partition back over the newly installed main partition. No effect, same symptoms. They point to Windows not being able to identify the main volume as bootable, in some sense (the usual bootrec fixes in WinRE failed to identify the main partition as a Windows installation, too) but I don't know how that works.

The underlying issue is how Windows reacts to changes in the bootloader, or the removal and recreation of the bootloader, it seems to me.

In a few years we'll all be on UEFI and GPT and this won't matter. So I'm not looking for a way to fix this, per se (I know the eventual answer to every MBR problem is "reinstall it from scratch"), so much as a technical understanding of why fiddling about with the MBR and partitions causes these little problems. If anyone could shed light on it, or point to resources that answer these questions, I'd be extremely grateful.

 

I'm only taking a guess so maybe someone can correct me if I've got anything wrong, but I'm guessing from reading about how Boot-Repair repairs boot sectors is that if you don't have a copy of the original MBR it generates a generic one, by the sounds of it, it identifies the file system and partition layout, selects the correct bootstrap code for that filesystem and then writes the partition table into it.

I'm guessing some programs are throwing a wobbly because while you can get away with only knowing about the filesystem and partition table to be able to load the next stage of the boot process other programs probably need to know the disk signature as under certain circumstances disc and partitions can change between reboots so the disk signature is a sure fire way to know it's overwriting the correct disk/partition.

 

Excellent, these are all things I don't know about. Disk signatures, and the means by which programs, OSes and the MBR itself identify and refer to partitions and disks.

I'm at risk of being like a boggled child with endless follow-on questions, and I appreciate that you may not want to delve endlessly into a lesson on the inner workings on MBR just for my benefit, so could I ask: where/how did you learn them? I need to get my head properly around how MBR and partition/disk identification actually work. I have, by trial and error, identified programs and methods that will let me safely clone, (sometimes) repair and work with MBR bootable drives in specific situations but I feel a bit like the man in the Chinese room, performing the correct actions with no understanding of the underlying workings. Is there an idiot's guide to MBR?

 

Have you tried this

Scroll down to the part about windows 10.

 

What little i know has only been picked up from years of dealing with multi-booting different OS's, the vast majority from fiddling around with GRUB.

I'm not sure how useful or if you've already read through them but the wiki article on master boot records and GRUB wiki maybe a good springboard, if you want to know more about the disk signature multibooters.com seems to have done a good article that goes into more details.

 

I'll have a look at those, thank you. It really aggravates me that Microsoft have never provided comprehensive technical documentation explaining exactly how the bootloader in Windows works. There are various guides and how-tos on diagnosing and fixing it, but no explanations.

Crapbag, that's interesting in that it differs slightly from the repair procedures I've seen before, I'll try them when I get a chance. But the underlying problem is still the same here - the commands are given, walkthrough style, but no explanation is given for what they do or why. As a technician I have amassed a collection of stickynotes covered in such commands, meant to fix the MBR in various situations, but have gained no understanding of what they do. Guides (Neosmart's included) ambiguously say that you "may have to use" one command or another but without an underlying appreciation of what each command is doing, I'm little better than a monkey pushing buttons. In particular, that Neosmart guide doesn't address what to do if the bootrec /rebuildbcd command returns "total identified installations: 0", which often happens to me and is currently what happens on this boot drive if I try it. As I say, those commands are slightly different - I've never used bootrec /ScanOs so I'll give that sequence a try.

 

Microsoft do have a TechNet article on the MBR, i didn't link to it previously as i sometime struggle to follow TechNet articles.

 

Somewhat doubt its MBR related fault (mbr just loads bootstrap code to start second stage bootloader, be it grub or windows one) and can be restored with "bootrec /fixmbr" command). Installing GRUB does not alter windows bootloader (BOOTMGR resides in "System Reserved" partition since Vista), it just changes the boot sequence from bios->mbr->BOOTMGR to bios->mbr->grub->BOOTMGR.
If something is wrong with boot sequence, most likely its something related to BCD (BCD does use GUIDs for boot sequence) or partitions in general (could you post screenshot of disk manager ?). If you can boot into windows, you could try Visual BCD editor or EasyBCD to inspect BCD store itself & try to repair it.

 

I maybe mistaken but i don't think boiled_elephant was asking about repairing a boot related issue, maybe i got the wrong end of the stick but i thought (s)he was asking how boot-repair fixed the problem and why after it did some programs that make images of the boot/system partition like Windows image backup and EaseUS Todo Backup are giving generic 'unable to access volume' type errors.

 

This is precisely correct. Sorry for slow response. The drive now boots fine but system restore cannot be accessed (the pane in sysdm.cpl just crashes with "System Restore encountered an error. Please try to run System Restore again. (0x81000203)"), and the backup problems mentioned by Corky.
EasyBCD looks alright based on my limited understanding:

Code:

There is one entry in the Windows bootloader.

Default: Windows 10 Home
Timeout: 30 seconds
EasyBCD Boot Device: E:\

Entry #1
Name: Windows 10 Home
BCD ID: {current}
Drive: C:\
Bootloader Path: \Windows\system32\winload.exe

Code:

Windows Boot Manager
--------------------
identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=\Device\HarddiskVolume1
path                    \bootmgr
description             Windows Boot Manager
locale                  en-GB
inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default                 {43915020-c937-11e7-a143-a0927ea310af}
resumeobject            {64516524-c932-11e7-bbb5-ec8fb95423d3}
displayorder            {43915020-c937-11e7-a143-a0927ea310af}
toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout                 30

Windows Boot Loader
-------------------
identifier              {43915020-c937-11e7-a143-a0927ea310af}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 10 Home
locale                  en-GB
osdevice                partition=C:
systemroot              \Windows
resumeobject            {4fad7ba6-c937-11e7-9d43-806e6f6e6963}
bootmenupolicy          Standard

But really, diagnosing this one particular installation is secondary now to wanting to understand, once and for all, how exactly booting works in an MBR-based environment. Thank you both for your input, I'm reading up on it when I can get the time (i.e. seldom, and fleetingly).