[EBCD-421] BootGrabber writes boot.ini to wrong partition in certain cases

[joevt]

There's a thread that describes the EasyBCD Boot Device at What is EasyBCD Boot Device? - The NeoSmart Forums

I have a disk that contained Ubuntu (primary active partition). I added 2 primary partitions to install Windows 7 on. I installed Windows 7 to one of the new partitions. When I booted into the new Windows 7 partition, I saw that my Ubuntu partition had been formatted to NTFS. Why is Windows so evil? (I didn't loose anything important).

Anyway, the Ubuntu partition is being used for the Windows 7 boot files (bootmgr file and Boot folder containing BCD file). I guess this happened because it was the active partition. Windows 7 was successfully installed to the partition I created.

The problem is, EasyBCD says the EasyBCD boot device is some other drive (at first it was my Vista 32 partition which is on a different disk, then after I created a BCD on the Windows 7 partition, EasyBCD says that's the EasyBCD boot device). I guess this is all happening according to the algorithm mentioned in the linked thread probably because the Ubuntu partition (Disk 2 partition 2) doesn't have a mount point. The attached screen shot shows what I mean.

I know the Ubuntu partition is being used for the BCD because I see the modification date of the BCD change when I make a change in EasyBCD (after I give the Ubuntu partition a mount point so I can actually see the BCD file).

So my question is, can EasyBCD be made to find the correct drive for the BCD when the drive doesn't have a mount point? The screenshot does show that the drive has an NTFS file system. And EasyBCD is able to modify it. This means the system can access the file system somehow. Maybe it uses the volume GUID?
Naming a Volume (Windows)
CreateFile Function (Windows)
Naming Files, Paths, and Namespaces (Windows)

"EasyBCD Boot Device: \\?\Volume{26a21bda-a627-11d7-9931-806e6f6e6963}\" would look strange. So maybe it could say "EasyBCD Boot Device: \\?\HarddiskVolume9\" or "EasyBCD Boot Device: \\?\Harddisk2Partition2\" for short.

Note that the Windows Object Manager in Windows 7 shows extra stuff in the Win32 namespace that does not exist in the Windows XP Win32 namespace (namely the HarddiskVolume# and Harddisk#Partition# devices).

I plan on putting BCD's on each Windows 7 partition using EasyBCD. I'll keep the BCD on the Ubuntu partition for further testing.

 

[mqudsi]

Hi Joe,

Everything seems to be correct. EasyBCD does indeed modify the BCD from the unmounted partition via the volume GUID, but for everything else (basically the NST folder and everything in it), it will create them on the local system disk rather than on the unmounted partition.

This is by design in order to minimize the pain both for me (accessing in the unmounted partition is a real PITA) and for the user should they need to modify anything in the NST folder. This shouldn't pose any problem for multiple Vista installs, EasyBCD will continue to keep the BCD changes synchronized in the unmounted partition and any helper boot files in the NST folder on whatever partition you were booted into at the time that you use EasyBCD to create a boot entry.

 

[joevt]

That makes sense and it works. It's just a little confusing that the NST files are on a different volume than the BCD when usually they're on the same disk. For Windows XP entries, EasyBCD does the right thing by putting the boot.ini/ebcd.00# file on the unmounted disk even though \NST\ntldr and \NST\easyldr# are on a different disk. Windows XP boots fine this way because the unmounted disk is the system disk and that's where ntldr/easyldr# expects to find the boot.ini/ebcd.00# file and bootmgr (on the system disk) is able to load ntldr/easyldr# from other disks.

There may be a small issue with multiple Vistas which are both booted from the bootmgr/bcd on a third unmounted partition. If the algorithm used to choose the BCD boot device (the place where the NST files are stored) does not choose the same partition for both Vistas, then a 2nd Windows XP entry created in the 2nd Vista will overwrite the ebcd.001 file for the 1st Windows XP entry create in the 1st Vista. This is because EasyBCD numbers \NST\easyldr# files not by existing entries in the BCD but by existing files in the \NST\ folder.

A user that needs to modify the unmounted partition can just create a mount point or drive letter for it. There may be valid reasons for not having a mount point such as protecting the boot files including (\NST stuff) from novice users or to make things more tidy like if you don't want to see 20 ANG# files in the root directory or if you don't want to see the system partition in Explorer.

 

[mqudsi]

Yes, good point. I meant to fix the code to use the ebcd.00x number instead of the easyldrx number, but it totally slipped my mind.

And I've been recommending that users who don't want to see the NST directory mount the partition, use EasyBCD, then unmount.. so we're on the same page there

 

[joevt]

The system partition might contain 1 ebcd.00# file but you could be writing easyldr's to an NST folder that contains 20 easyldr's already because the NST folder could be used by other BCD's. So the numbers would have to be unique in both places - on the system disk for ebcd.00# and in the NST folder for easyldr#.

 

[mqudsi]

Not really. If the user is editing a different BCD store (than the one on the boot partition), I actually create the NST folder on the same drive that the BCD being edited is on.

I guess if the user is editing multiple BCDs on the same drive though? Doesn't cost me anything to check both locations, so I'll probably do as you suggested

 

[joevt]

I mean when the user is editing the system BCD when the system partition is unmounted, then EasyBCD will use an NST folder on a different disk which may be used by a BCD on that different disk.

It is not inconceivable that a user may be using a BCD on an unmounted system disk without even knowing it (it happened to me). The Windows installer can create this situation without input from the user and it will give no indication that it did so. EasyBCD also gives no indication that this situation exists.

It is also not inconceivable that a user has multiple disks with BCD's. They could have a disk connected that came from a different computer or they may want a disk that is bootable without the first disk for recovery purposes or if they're using the disk for virtualization or whatever.

Is doing NST changes on an unmounted system disk really much more difficult than a mounted disk? You already do boot.ini/easybcd.00# changes to the unmounted system disk.

 

[mqudsi]

What I'm saying is, the only case where I will edit a BCD on an unmounted partition is if it's on the system boot device.

In any of the other cases that you mention, the BCD will need to be on a mounted partition, or else you cannot browse to it in EasyBCD to edit it. As such, EasyBCD will create the NST folder on the same drive that the BCD being edited now is on.

So when you edit the system BCD on an unmounted partition, an NST folder will be created on your current Windows disk.

When you edit another BCD on one of your other "multiple disks with BCDs," the NST folder will be created on that same disk, never on the current Windows partition.

 

[joevt]

the only case where I will edit a BCD on an unmounted partition is if it's on the system boot device. In any of the other cases that you mention...

This is the case I am describing here. I have not mentioned any other cases.

the BCD will need to be on a mounted partition, or else you cannot browse to it in EasyBCD to edit it.

Browsing to another BCD is not required to encounter this issue.

I guess if the user is editing multiple BCDs on the same drive though?

I have not mentioned editing multiple BCDs on the same disk and I don't think that would cause the same issue since they would all use the same location for the easyldr#s and the same location for the ebcd.00# so checking one location is enough for ensuring filename uniqueness.

So when you edit the system BCD on an unmounted partition, an NST folder will be created on your current Windows disk.

Look at the screen shot. The disk containing the used NST folder (EasyBCD Boot Device) might not be the current Windows disk (Boot). There are 3 partitions involved:
<1> = The system disk containing the BCD that EasyBCD opens by default on disk 2 partition 2 (19.88 GB NTFS). It has no mount point. This partition has a BOOTMGR.
<2> = EasyBCD says the EasyBCD Boot Device is: E:\ where it will create NST files. Drive E:\ has it's own BOOTMGR and BCD.
<3> = Windows is booted from C:\ which is Windows 7 64.

Imagine that <2> has 5 easyldrs. Adding the first easyldr to <1> requires an easyldr6 to be created. You need unique easyldrs in the NST folder. You've already agreed that you need unique ebcd.00#. Therefore, both places need to be unique.

It is also not inconceivable that a user has multiple disks with BCD's.

This was meant only to point out that multiple partitions could have preexisting NST folders to support their BOOTMGR/BCD. It's these preexisting NST folders that is the cause for this issue because EasyBCD may choose to use one of them when the system BCD is on an unmounted partition.

I've been recommending that users who don't want to see the NST directory mount the partition, use EasyBCD, then unmount.

It is not inconceivable that a user may be using a BCD on an unmounted system disk without even knowing it.

This point was meant to contradict your above statement that assumes the user wanted the NST directory to be invisible when in fact they may not have had a choice to begin with or know what a system partition is or why they would want it to be visible or not.

This whole discussion describes the pros and cons of the 2 solutions for the case where the BCD is on an unmounted system partition.

A) Put NST files on other disk. Cons: Less simple. More fragile when it involves an extra partition in the boot process. Adding boot files requires a check for filename uniqueness in both the NST folder and the system root folder for files that can have differing contents. Note that NeoGrub does not have a filename uniqueness feature like easyldr or AutoNeoGrub so it's not possible for multiple BCD's to have their own menu.lst if they use the same NST folder.

B) Put NST files on unmounted system partition. Cons: pita to code otherwise it requires the user to manually mount the partition first. For the user to manually edit NST files, they need to mount the partition but they have to do that anyway to edit boot.ini/ebcd.00# files.

I like B. It boils down to just pita to code.

 

[mqudsi]

OK, I've found the source of the misunderstanding. I was not aware that were situations where EasyBCD will use something other than both the system boot partition and the current Windows partition for the creation of the NST folder.

I have to revise the code for the "EasyBCD Boot Device" - it was written a year+ ago, and I guess it's a bit more complicated than what I described (try BCD partition, else Windows partition).

 

[joevt]

It's possible that the Windows partition may itself have it's own BOOTMGR and populated BCD and NST folder so the same situation occurs where multiple BCD's on different system disks are using the same NST folder because Windows is booted using an unmounted system disk.

Unlike my original situation which was created by the Windows installer, this would require manual setup (either the user created the BCD on the Windows partition using EasyBCD or the user hid the system partition).

 

[mqudsi]

The code actually goes:

* Boot drive, or failing that,
* A drive with the BOOT\BCD file, or failing that,
* The current Windows root