EasyBCD 2.0 b97 overwrites all MBRs even on disks with no MBR

[joevt]

Bugs:

- I'm not sure which option in EasyBCD caused the problem (probably in Bootloader Setup) but I noticed that block0 of my Apple Partition Map formated external FireWire drive was overwritten with a Windows 7 MBR. EasyBCD seems to modify every MBR on all attached disks (I have 4 internal disk and a couple external disks). I have modified boot code in some MBR's which I do not want to be overwritten.

- Also an HFS+ partition on my disk which contains an NTFS Windows XP partition was modified.

- If you use "Select BCD Store" and choose the BCD that is used by the current system then an Unhandled exception error appears.

- The Partition list for Create Bootable External Media shows all 6 HFS+ partitions on my Apple Partition Map formatted hard drive as NTFS. (I'm using MacDrive 8). HFS+ partitions on other disks also appear as NTFS. Disk Management doesn't know what file system they are but it does know that they are not NTFS as it shows real NTFS partitions properly.


Feature requests to help with some of the above problems:

- Every button that modifies the disk needs to state what's it modifying and where. For MBR: disk. For VBR: disk/partition. For files such as Boot.ini, NTLDR, NTDETECT, BOOTMGR, BCD: full path. The dialog should allow the user to cancel. This information will help the user understand what's going, and will enable them to trust the process more. The information needs to be specific. "The MBR on disk 0" is more useful than just "the MBR". Some of the dialogs could be more specific such as the ones discussed in Recovering the Vista Bootloader with EasyBCD. "The BCD Registry" could specify path of the BCD. "default boot target" could say "default boot target in the new BCD" to differentiate it from any other kind of boot target specifier (such as active partition flag). "Of your boot drive" - does that mean the drive you're booted into now or another boot drive that you want to fix? I have lots of boot drives with ntldr and bootmgr and sometimes both so that's not a good way to identify the wanted drive. Maybe the dialog just wants a working boot drive? Maybe if the dialog said what it's going to do to that drive (read some files?) it would help the user choose.

- The EasyBCD main window should show the path of the BCD currently being modified so the user knows which they're editing at all times.

- It would be cool if we could open more than one BCD at a time so they can be compared more easily. You can run EasyBCD more than once but it might not be safe.

- On buttons that affect more than one disk, I would like the ability to choose a single disk (default to the one containing the currently selected BCD or the boot disk). This way other disks won't be needlessly or inadvertently modified. I may have multiple bootable disks, but I only boot one at a time or have problems with one at a time.

- Is there a way to create ARC paths of partitions for boot.ini files in Windows? The drive numbers and partition numbers shown in Disk Management don't seem to match the numbers used by BIOS/boot.ini.

- EasyBCD can fix boot problems by writing MBRs and VBRs and BCDs but can it detect boot problems to help the user understand what has happened to their disks? For instance, it could detect the MBR type (DOS/XP/Vista/7/unrecognized or custom), the VBR type (Vista/Grub/etc), and check the existence of the correct boot files (ntldr, etc. for XP, BOOTMGR for Vista)... The user would need to be able to add to the list of MBR and VBR types.

- When specifying an entry for NTLDR in the BCD, it's not possible to specify a drive. Maybe EasyBCD could explain why the BCD can only point to one NTLDR (the drive can be changed in Advanced Settings but that doesn't seem to have any effect). NTLDR's boot.ini can point to other NT type partitions.

 

[mqudsi]

Oh wow!

(sorry, couldn't contain myself at the sight of such an excellent and detailed post!)

Welcome to NeoSmart Technologies, joevt!

Let me address your points one-by-one:

EasyBCD overwrites the MBR on all disks
Yes, it does indeed. That's a quick workaround for an issue where the boot disk and what Windows thinks is the boot disk are different. I'll get back to you on whether or not I have a better way of doing so.

If you choose the BCD used by the current system, an exception occurs
Known issue - use the "Reload System Store" from the File menu instead. I'll have to fix the exception though - an application should never, ever crash.

BootGrabber lists HFS+ partitions as NTFS
MacDrive must have done something weird, because by default EasyBCD definitely doesn't do that if your partition is set up correctly. See the attached screenshot. (Next build will say "HFS+" where this screenshot says "0xaf")

More detailed messages
Good idea. Will see what I can do.

Show the path of the current file
I can stick that info on the main EasyBCD page ("View Settings"), but not on the other pages. It would add too much clutter. But good idea - I'll add that next build.

Opening multiple EasyBCD instances with different stores
As of 2.0 beta (not sure which build, but definitely there now) it is perfectly harmless to open n instances of EasyBCD. You can open as many different stores and compare to your heart's content

Modifications of more than one disk
Technically, EasyBCD shouldn't need to modify more than one disk, IF point one above is worked around.

Creation of ARC Paths for boot.ini
Already done and implemented. Check out Tools | Auto-Configure Boot.ini
This option is also presented when you attempt to add a new Windows XP entry.

Diagnostics of current machine
Nice idea. Too late to implement that for 2.0 though, it would need some serious work.

Explanation of why fixed NTLDR disk
Currently, EasyBCD just says "auto-configured" next to the disabled drive drop-down. It, as you of course know, makes no sense to have multiple NTLDRs since they all read from a hard-coded path (boot drive\boot.ini). The EasyBCD documentation clears all that up (online), but how can I clear it up unobtrusively in the software? I'm not going to display a pop-up... but perhaps a question mark button next to it. We'll see!


Thanks again for all your feedback, it is very much appreciated!

Oh, and stick around, we'd love to have you on board!

 

[Terry60]

On the last point.
The ntldr entry in the BCD, isn't a pointer to a copy of ntldr on an XP drive.
It's an alias of the GUID 466f5a88-0af2-4f76-9038-095b170dc21c, which describes the legacy boot loader on the "system" drive.
We know from years of experience that the most common mistake new XP dual-booters make, is to force that to point to the wrong place, then to post that EasyBCD doesn't work.
That's why Easy does everything in its power to make the user leave it alone.
It's a confusing anti-intuitive consequence of MS architecture, but we try to steer users down the correct path.
As you can see, it's not a subject that can easily be explained in a concise text message.
(I tried to get CG to put "leave it alone" in large angry letters, but he opted for a more congenial "auto-configured")

 

[mqudsi]

Terry, that's the way it used to be when they were created as {ntldr}, but now EasyBCD (def. in 2.0, not sure about 1.7.x) actually creates a real pointer to NTLDR on the specified disk.

 

[Terry60]

Why ?

 

[mqudsi]

one, it makes my code a lot cleaner not treating Winodws XP as a special case. But actually, the real reason is that you cannot have more than one {ntldr} entry so I do it directly to bypass that artificial limitation.

 

[Coolname007]

one, it makes my code a lot cleaner not treating Winodws XP as a special case. But actually, the real reason is that you cannot have more than one {ntldr} entry so I do it directly to bypass that artificial limitation.

Yeah, but wouldn't that cause problems if the user points at the wrong NTLDR (i.e. not the one on the "system" partition)?
And why would you provide support for adding multiple XP entries to the BCD anyway, seeing as you really should only have one, with the corresponding boot.ini pointing to whatever other XP systems are on there?

 

[mqudsi]

The user can't point it at NTLDR, only I can (in the code).

 

[Coolname007]

The user can't point it at NTLDR, only I can (in the code).

Ok, but I still don't see why you allow multiple {NTLDR} entries.
And I thought by "specified disk" you meant where the user can change the XP entry to point at a different partition (i.e. the feature of EasyBCD formerly under "Change Settings").

Terry, that's the way it used to be when they were created as {ntldr}, but now EasyBCD (def. in 2.0, not sure about 1.7.x) actually creates a real pointer to NTLDR on the specified disk.

 

[mqudsi]

True. EasyBCD gives you enough rope to hang yourself with

 

[mqudsi]

Followup on:

If you choose the BCD used by the current system, an exception occurs
Known issue - use the "Reload System Store" from the File menu instead. I'll have to fix the exception though - an application should never, ever crash.

I just double-checked: no exception occurs, but an error message is presented. That's acceptable.

 

[joevt]

I just double-checked: no exception occurs, but an error message is presented. That's acceptable.

I'm using Windows XP SP3, EasyBCD 2.0 b97. The exception says

Unhandled Exception has occur in your application...

The process cannot access the file 'C:\Boot\BCD' because it is being used by another process.
<Details> <Continue> <Quit>
See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.IO.IOException: The process cannot access the file 'C:\Boot\BCD' because it is being used by another process.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
   at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
   at ..(String value)
   at ...ctor(String bcdPath)
   at .
.(String bcdPath)
   at .
.(Object , EventArgs )
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib

Pressing continue continues EasyBCD. I get exceptions like this in other parts of EasyBCD. I have VB6, Visual Studio 2005/2008, SQL Server, etc. installed. I don't know if that effects this. Or maybe it's been fixed in a later EasyBCD version? I'll try that later.

one, it makes my code a lot cleaner not treating Winodws XP as a special case. But actually, the real reason is that you cannot have more than one {ntldr} entry so I do it directly to bypass that artificial limitation.

I've read all the bcdedit.exe /? topics and the bcd.docx documentation. While it's true that only one Application Object can use the {ntldr} GUID, there seems to be no limitation on the number of Application Objects with the NTLDR application type. They can be assigned other GUIDs. Every apptype can contain DESCRIPTION, PATH, DEVICE, and INHERIT data.

The above leads to the following questions:
1) Does the boot loader treat {ntldr} any differently than any other object with the ntldr app type? i.e. Can you get an ntldr object to work if it had a different GUID than {ntldr}?
2) Do the path and device data do anything? i.e.:
2a) can NTLDR be renamed?
2b) can NTLDR be moved to another directory?
2c) can NTLDR be on a different partition?
2d) can NTLDR be on a different disk?

Of the above, only 1, 2c and 2d are important. I am currently looking for a method to boot from one disk and have the boot loader run XP which is on a different disk. What I would want is for the NTLDR on the specified drive to be loaded and for it to use the boot.ini on the same drive and for that drive to be the boot drive. If I can't do that with the Vista or XP boot loader, then can I do it with NeoGrub?

EasyBCD overwrites the MBR on all disks
Yes, it does indeed. That's a quick workaround for an issue where the boot disk and what Windows thinks is the boot disk are different. I'll get back to you on whether or not I have a better way of doing so.

I suppose this works for people that don't use other partitioning schemes than gpt or mbr but you're using Windows 7 MBR code. Does that work with Windows XP VBR (boot sector) code or other such boot loader code?

Is the issue the same issue discussed in the second screen shot at "Recovering the Vista Bootloader with EasyBCD" where it says "... EasyBCD needs to know ... the correct letter of your boot drive"? I don't see any reason you can't use a similar dialog for fixing the MBR. Except instead of saying "We're not smart enough to figure out the boot drive because Windows sucks enough to not be able to tell us reliably", you could say "We are super and can fix anything so pick the one you want us to fix "

BootGrabber lists HFS+ partitions as NTFS
MacDrive must have done something weird, because by default EasyBCD definitely doesn't do that if your partition is set up correctly. See the attached screenshot. (Next build will say "HFS+" where this screenshot says "0xaf")

I agree it must be doing something weird but I don't know what. I've attached output from bootgrabber.exe and output from Mac OS (If you haven't guessed yet, I'm using a Mac Pro). The output from the Mac shows which disks are HFS+. You can find the disks in the Mac list by searching for the Size/512. Mac Drive will mount partitions marked in the MBR as HFS+. It also mounts partitions on Apple Partition Map disks.

Getting properties of a Mac disk in Windows shows file system type as HFSJ. The Device Manager list shows blank for fs type. Is it possible to get file system type in the same way that Windows Explorer does?

Creation of ARC Paths for boot.ini
Already done and implemented. Check out Tools | Auto-Configure Boot.ini

Auto-Configure gets the ARC Path from BootGrabber.exe? The ARC Paths in the attached file don't seem right. Several disks have the same rdisk value and some disks have more than one rdisk value for their partitions. How is the ARC Path created? Is there a Windows API? Is there another way to get ARC Path information (recovery console/neogrub command line)? I don't think this is a problem with Apple's BIOS emulation since it should be long gone by the time BootGrabber can be used. Getting Properties -> Hardware shows Locations 0,1,2,3,5 for the internal drives and LUN (0) for the IEEE 1394 drive.

BTW, the utilities in %Program Files%\EasyBCD\bin\ look interesting. Is there documentation for the non-Microsoft utilities somewhere? Being able to use them in a command line (for more control) or in a .bat file (for scripting) may be useful.

Explanation of why fixed NTLDR disk
Currently, EasyBCD just says "auto-configured" next to the disabled drive drop-down.

I've made my NTLDR comments above. I would like to know what specifically is auto-configured for each of the other loader types. Several of them add .mbr files to C:\NST. Several of those have a name AutoNeoGrub#.mbr. All the AutoNeoGrub#.mbr seem to only differ by a single character but that means they are not interchangeable with each other. It looks like they each load a different ANG# file from the root directory. The ANG# files are the same except for some self contained NeoGrub text commands that depend on the selected loader type.

There is documentation for each of the supported OS's which discusses some of the boot loaders. I think there should also be documentation in the other direction for the boot loaders such as how they work, the boot process up to the first os file being loaded, and what they require to work (what should be installed beforehand, what drive/partition to select, what the other options do, is an .mbr file used, boot sector location and contents, what os boot files are used, disk/partition information/limitations etc.) There's already documentation for NeoGrub. It may be sufficient for some of the boot loader documentation to point to the corresponding OS documentation but some of the OS documentation does not mention all of the boot loader options. There doesn't seem to be any documentation yet for the portable/external media loader types. Knowing the above would help with setup and trouble shooting.

 

[mqudsi]

OK, I don't get that error on Windows 7 64-bit. But I'll put the workaround in anyway and upload so you could test it. Any info on where else in EasyBCD you get these dialogs?

What you say about {ntldr} is true. Indeed, earlier versions of EasyBCD used to create multiple XP entries with the NTLDR application type.

With regards to your NTLDR questions, it's interesting:
1) No, bootmgr treats it the same. Other data types can boot NTLDR too. In fact, most of the entry types are internally treated identically. EasyBCD uses generic bootloader for everything.
2) NTLDR can be placed wherever you like and with whatever name you want. But when it runs, it will load boot.ini from (and only from) the active partition on the boot disk. You can't get NTLDR to read boot.ini from its own partition unless you use something like our Vista HnS software: [Download] Vista Hide 'n Seek BETA - The NeoSmart Forums

EasyBCD no longer overwrites the MBR of all disks in Build 100. The screenshots in the documentation are also outdated.

I get the partition information straight from the MBR. I currently use a Windows function to do so, though I may have to resort to manually opening, reading, and parsing the MBR like I do in other places. I'm not sure why the MS API is giving me incorrect results for the Snow Leopard partitions, but if I were to hazard a guess, I'd say it's due to the fact that you're mounting them as directories and not independent drives?

I'm not seeing the "single drive with multiple ARC paths" in your text file, but as for the "different drives with the same ARC" - that's a known issue. Windows does not offer ANY way whatsoever to retrieve the ARC path. BootGrabber.exe is a low-level program written with the Microsoft DDK that attempts a number of different techniques to tie-down a disk/partition to a particular ARC path. In its version, BootGrabber.exe relies on the VolumeID of each partition in order to uniquely index the partitions and match them up to given disks, arc paths, etc.

If the VolumeID is identical (usually caused by crappy cloning or partitioning software that doesn't generate a new, unique VolumeID for the newly-created partitions), BootGrabber will present the same ARC path for multiple disks. And in that case, it may present the wrong ARC path as well.

What you have to realize is, when dealing with bootloaders and low-level hardware from within Windows there's so much that is not documented. I've worked with several other engineers in reverse-engineering Windows components and hidden APIs to get at some of the info you see. None of the techniques are fool proof, the evidence of which you have already seen. But for most people (probably over 99%) who have "standard" disk configurations (very much unlike yours and mine!), it just works. We haven't had any complaints about ARC paths failing for boot.ini auto-generation since I made the last updates to BootGrabber.exe over 4 or 5 months ago.

The AutoNeoGrub files are spilt into two components, AutoNeoGrub#.mbr and ANG#. One is a stage-1 loader, the second is a stage-2 loader. Each stage-1 loader has just one job, which is to find and run the stage-2 loader (which is the real code, but needs to be separated from stage-1 due to the size restrictions).

Each ANG# file contains custom NeoGrub code embedded within it so that it can do a particular action without presenting the user with a menu of actions to choose from. This technique lets me mount 2 different ISOs for booting via NeoGrub without putting them both as two entries in a single NeoGrub menu. Instead, I generate a single-entry NeoGrub exectuable for each, making the whole business a one-click affair from the Windows bootloader as far as the user is concerned. ANG is used to boot from ISOs, chainload GRUB and LILO entries, and a couple of other things.

I know the documentation in the wiki is lacking. We have such a severe shortage of contributors - I'm mainly tied up in the code (actually, more R&D than coding of late in order to reverse-engineer and experiment up different solutions) while Terry and Justin are busy with the support here on the forums. I've been meaning to get to the wiki and expand on all the documentation as soon as 2.0 is released.

Addendum:

btw, check out bootgrabber.exe /tlist - it presents a much more concise output that makes it easier to compare entries and spot patterns. Can you post it?

 

[mqudsi]

Hi Joe,

Try this build - it should fix the crash.

 

[joevt]

Any info on where else in EasyBCD you get these dialogs?

I can't remember off the top of my head.

I'm testing build 102 now.

Do new builds or versions of EasyBCD update the /NST files if for example the mbr's have bug fixes or enhancements since the last time they were installed? This does not currently seem to be the case. The ANG# files are larger in b102 than the ones from b97. Also, the Grub (Legacy) option has an additional search for /grub.conf.

In build 100, I did not get the error when I tried to open C:\Boot\BCD (a dialog appeared for less than a second) but I did get an exception when I tried to close EasyBCD afterward. In build 102, an apropriate message was displayed when I tried to open C:\Boot\BCD but it didn't seem to know that the file I selected was the System BCD. Is there no way for EasyBCD to know the selected BCD is the same as the System BCD?

I would like to suggest a "Don't show me again" option for the "Selecting a New Store" message.

I made a backup of my BCD store, then did a Reset BCD configuration. This has the side effect of closing windows in Explorer belonging to the boot partition and causing Explorer to forget the name of the boot partition (makes it blank) so that it displays as Local Disk. This change seems to be only cosmetic because Disk Management still shows the original volume name. "Install the Windows Vista/7 bootloader" has the same effect but "Install Windows XP bootloader" does not. Good News: looks like only the MBR on the boot disk is now updated.

Reset BCD configuration does not remove AutoNeoGrub and ANG files. Perhaps there should be an option to clean them up. EasyBCD would need to be able to identify that the files are actually an ANG file and not a file created by the user. And there would need to be a warning that backups that use ANG files will no longer work (or the backup process could backup ANG files too...).

Adding a Windows XP Entry gives the option of configuring the boot.ini file but the boot.ini file does not get changed even if I empty it or delete it beforehand. Actually, it's modifying the boot.ini on my Windows Vista 32 partition instead of my Windows XP partition (XP is the boot/active partition). I think the active partition got switched by EasyBCD to the Vista 32 partition also. This is one reason a select partition dialog is needed for these changes.

I did a "Select BCD Store" and selected the backup BCD, then did load System Store. This did not show my new reseted BCD store and neither does the "Refresh BCD Store" menu item. Further messing around with the backup and sytem BCDs (can't remember the exact steps) caused an exception and now my backup BCD is no longer loadable - I get a "The boot configuration data store could not be opened.". The backup file length was somehow set to 0. I should have made a backup of the backup

I tried adding an MS-DOS entry, pressed Yes to view the documentation. Then got an Unhandled exception: StandardOut has not been redirected or the process hasn't started yet. See below for details. Pressing the No button works but I have no idea what partition if any was modified. I see a zero length IO.SYS and MSDOS.SYS on both my Windows XP partitions but they don't appear to be modified. I think they are normal for Windows XP partitions.

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.InvalidOperationException: StandardOut has not been redirected or the process hasn't started yet.
   at System.Diagnostics.Process.get_StandardOutput()
   at (Object )
   at  . . ()
   at  . . (String uri)
   at  . . (String name, Boolean silent)
   at  . . (Object , EventArgs )
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3607 (GDR.050727-3600)
    CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
EasyBCD
    Assembly Version: 2.0.0.102
    Win32 Version: 2.0.0.102
    CodeBase: file:///C:/Program%20Files/NeoSmart%20Technologies/EasyBCD/EasyBCD.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3614 (GDR.050727-3600)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Configuration
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3082 (QFE.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
{70ca641e-96be-4286-80fa-da82f209d3b2}
    Assembly Version: 0.0.0.0
    Win32 Version: 2.0.0.102
    CodeBase: file:///C:/Program%20Files/NeoSmart%20Technologies/EasyBCD/EasyBCD.exe
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

But when it runs, it will load boot.ini from (and only from) the active partition on the boot disk. You can't get NTLDR to read boot.ini from its own partition unless you use something like our Vista HnS software

So the Vista Boot loader doesn't set the boot disk to the disk containing the partition that contains the NTLDR that I have selected (the partition containing the selected NTLDR is active but not on the disk that I'm booting from).

Can the NeoGrub boot loader change the boot disk? I think it can using the map command. See below for my multiple NTLDR solution.

I looked at the HnS thread. There's an issue of one OS (XP) messing with the files of another (Vista)? ... Weird. If HnS hides the boot disk, does that mean it makes another disk the boot disk? Is HnS just NeoGrub with an automated setup (i.e. can HnS be done manually with Notepad and EasyBCD)? The thread contains a link for a utility called Drive Grabber.exe. Does BootGrabber supersede Drive Grabber (i.e. does Drive Grabber not have any useful features that are in BootGrabber)?

I'd say it's due to the fact that you're mounting them as directories and not independent drives?

I was running out of drive letters and thought it would be neater to mount them like on Unix since they don't contain any Windows programs or documents. I tried mounting them to drive letters instead but that didn't affect what BootGrabber was seeing as their file systems.

I'm not seeing the "single drive with multiple ARC paths" in your text file

The disk at Index 2 shows the EFI partition as rdisk(3). The rest of the partitions on the disk are rdisk(1).
The disk at Index 3 is similar. The EFI partitions are unused and not important so it's not a big issue.

If the VolumeID is identical, BootGrabber will present the same ARC path for multiple disks.

How do I view VolumeID's? I know disks have a 4 byte disk ID in the MBR. On the Mac, I have volume UUID's for HFS+ volumes (created from 64-bit volume ids), and gpt partition UUID's (neither are shown in the mac output I uploaded before). NTFS boot sectors have a 64-bit volume id (Volume Serial Number).

check out bootgrabber.exe /tlist

Here is the output from bootgrabber.exe /tlist. It appears to be the same output as /list except in a table format.

BootGrabber utility. 
Copyright NeoSmart Technologies 2009-2010 <http://neosmart.net/>

D0,3,3,0,320072933376
P1,,238,209735168,209735168,Yes,multi(0)disk(0)rdisk(3)partition(1)
P2,O:\,7,64424509440,23968215040,Yes,multi(0)disk(0)rdisk(2)partition(2)
P3,C:\Volumes\SnowLeopard\,7,255170232320,216076754944,Yes,multi(0)disk(0)rdisk(2)partition(3)
D1,2,2,0,1000204886016
P1,,238,139930390016,139930390016,Yes,multi(0)disk(0)rdisk(3)partition(1)
P2,,7,21340618752,21340618752,Yes,multi(0)disk(0)rdisk(3)partition(1)
D2,4,4,0,250059350016
P1,,238,223000808960,223000808960,Yes,multi(0)disk(0)rdisk(3)partition(1)
P2,I:\,12,1073741824,853598208,Yes,multi(0)disk(0)rdisk(3)partition(2)
P3,L:\,12,524288000,392825344,Yes,multi(0)disk(0)rdisk(3)partition(3)
P4,K:\,1,2097152,638464,Yes,multi(0)disk(0)rdisk(3)partition(4)
D3,4,4,0,320072933376
P1,,238,209735168,209735168,Yes,multi(0)disk(0)rdisk(3)partition(1)
P2,E:\,7,85684600832,46466240512,Yes,multi(0)disk(0)rdisk(0)partition(2)
P3,D:\,7,86114091008,62457946112,Yes,multi(0)disk(0)rdisk(0)partition(3)
P4,C:\,7,148064485376,94423392256,Yes,multi(0)disk(0)rdisk(0)partition(4)
D4,2,2,0,1000204886016
P1,,238,16896,16896,Yes,multi(0)disk(0)rdisk(3)partition(1)
P2,R:\,7,805096649216,228636475392,Yes,
D5,6,0,6,200049647616
P1,C:\Volumes\Work\,7,53687091200,3056418816,No,
P2,C:\Volumes\Devs\,7,42949672960,5590994944,No,
P3,C:\Volumes\Apps\,7,32212254720,10218336256,No,
P4,C:\Volumes\Updates\,7,42949672960,684466176,No,
P5,T:\,7,8589934592,963108864,No,
P6,U:\,7,7516192768,859353088,No,

The AutoNeoGrub files are spilt into two components..

Very cool stuff. I was looking at the NeoGrub commands in the ANG# files to get some ideas on what all NeoGrub can do. I've read the grub documentation but didn't see a lot of practical examples like the ones in the ANG# files. The ANG# files all use the find command which means they can all only find the first occurance of what they're looking for. e.g. Only the first GRUB (Legacy), or first GRUB 2, or first Wubi. Granted, a user will usually only ever have one occurance but in cases where a user has two or more, it is possible to find a tag file unique to a partition selected by the user, then run whatever from that drive. Like this:

title BootCamp2
find --set-root --ignore-floppies --ignore-cd /BootCamp.tag
map () (hd0)
map (hd0) ()
map --hook
makeactive
chainloader /ntldr

The above finds a tag file (a zero length file whose contents or name doesn't matter) that I created on my second Windows XP partition, then boots the NTLDR on that partition. This is better than the next to useless NTLDR option provided by BOOTMGR. Is there a way to make NeoGrub not dump output to the screen for the commands or whatever it's doing unless there's an error?

Another feature: Allow the user to create their own AutoNeoGrub commands like the one above. Sure we can edit menu.lst but then we have to go through a Grub menu after going through the Vista menu. If we wanted to do that then we would be using EasyGrub instead of EasyBCD and you wouldn't have created all those wonderful bootloader options for the BCD.

Speaking of bootloader options, I tried to boot from a Windows XP SP 3 iso (from MSDN) but got a blue screen. Is that normal for this iso? It gets as far as the message "Starting Windows". Booting from a burned CD of the iso works fine.

 

[mqudsi]

Hello again, Joe

Seriously. Stick around. We need this sort of constructive feedback and insight more often!

Do new builds or versions of EasyBCD update the /NST files if for example the mbr's have bug fixes or enhancements since the last time they were installed? This does not currently seem to be the case. The ANG# files are larger in b102 than the ones from b97. Also, the Grub (Legacy) option has an additional search for /grub.conf.

Either the old entry works and doesn't need to be updated, or it doesn't and you need to download and use a new build to add a work entry. So no harm done.

In build 102, an apropriate message was displayed when I tried to open C:\Boot\BCD but it didn't seem to know that the file I selected was the System BCD. Is there no way for EasyBCD to know the selected BCD is the same as the System BCD?

Difficult. I'd have to change the heuristics a bit, don't think it's worth it for such a minor dialog I mean, for the user, the difference would be "this is in use" vs "this is the system bcd and it's use, use the other menu option."

I would like to suggest a "Don't show me again" option for the "Selecting a New Store" message.

Already there. Just enable "Expert Mode" in the options. When I get the time to completely redo the documentation in the same way that I've redone the software, that'll be fully explained.

Reset BCD configuration does not remove AutoNeoGrub and ANG files. Perhaps there should be an option to clean them up. EasyBCD would need to be able to identify that the files are actually an ANG file and not a file created by the user. And there would need to be a warning that backups that use ANG files will no longer work (or the backup process could backup ANG files too...).

Good point. Currently you can do so by deleting the entries manually beforehand, but perhaps it's quicker to delete the ANGx files yourself. I'll fix this in a future update (2.0.1 perhaps).

Adding a Windows XP Entry gives the option of configuring the boot.ini file but the boot.ini file does not get changed even if I empty it or delete it beforehand. Actually, it's modifying the boot.ini on my Windows Vista 32 partition instead of my Windows XP partition (XP is the boot/active partition). I think the active partition got switched by EasyBCD to the Vista 32 partition also. This is one reason a select partition dialog is needed for these changes.

Well, you yourself explain the reason. It's changing the file on the wrong drive. Fault isn't with EasyBCD - I ask Windows what drive it booted from. Check out HKLM\System\Setup\SystemPartition ... you'll find that Windows has it wrong.

Got an idea though, I can add a field in the Options dialog to override this value. Of course, you can also correct it yourself in the registry. I have no other way of determining what drive was booted from. Remember, the system does not NEED to boot from the active partition on drive 0 - you can have something physically wired as drive 0 but select drive 1 to boot from in the BIOS.

ACTUALLY: Can you give this a shot? Delete that key. It's definitely auto-generated if it doesn't exist upon boot, but I don't know if it's refreshed each boot if it's already there. That may fix it.

I did a "Select BCD Store" and selected the backup BCD, then did load System Store. This did not show my new reseted BCD store and neither does the "Refresh BCD Store" menu item. Further messing around with the backup and sytem BCDs (can't remember the exact steps) caused an exception and now my backup BCD is no longer loadable - I get a "The boot configuration data store could not be opened.". The backup file length was somehow set to 0. I should have made a backup of the backup

Will look into it. Thanks

I tried adding an MS-DOS entry, pressed Yes to view the documentation. Then got an Unhandled exception: StandardOut has not been redirected or the process hasn't started yet. See below for details. Pressing the No button works but I have no idea what partition if any was modified. I see a zero length IO.SYS and MSDOS.SYS on both my Windows XP partitions but they don't appear to be modified. I think they are normal for Windows XP partitions.

Will look at this, too. IO.SYS and MSDOS.SYS aren't normal for XP partitions - they're the files used to boot DOS-based OSes (e.g. DOS, 9x, ME).

Can the NeoGrub boot loader change the boot disk? I think it can using the map command. See below for my multiple NTLDR solution.

I looked at the HnS thread. There's an issue of one OS (XP) messing with the files of another (Vista)? ... Weird. If HnS hides the boot disk, does that mean it makes another disk the boot disk? Is HnS just NeoGrub with an automated setup (i.e. can HnS be done manually with Notepad and EasyBCD)? The thread contains a link for a utility called Drive Grabber.exe. Does BootGrabber supersede Drive Grabber (i.e. does Drive Grabber not have any useful features that are in BootGrabber)?

HnS is only based on Grub4Dos. I had to modify it pretty extensively a while back in order to get certain things working. Current builds of G4D have implemented a different way of pulling this behavior making my fork moot and will work as needed without modification... Drive Grabber was indeed succeeded by BootGrabber, which adds additional features and fixes certain crashes and incorrect detection of drive letters.

NeoGrub *can* change the boot disk - but with a huge caveat: it does so permanently, not just for the next boot.

I was running out of drive letters and thought it would be neater to mount them like on Unix since they don't contain any Windows programs or documents. I tried mounting them to drive letters instead but that didn't affect what BootGrabber was seeing as their file systems.

Weird. I have a MacBook Pro myself, but have so far managed to avoid installing Windows on it. Or, to be more precise, installed Windows when I got it on a Boot Camp partition, and have found no reason to boot into it except for that one time. I have just the one disk though, so I don't know if I can reproduce. (I actually use Windows exclusively for development, everything else - including answering threads here on the forum about EasyBCD *and* looking at the EasyBCD source code as a reference is done on my Mac... like right now )

How do I view VolumeID's? I know disks have a 4 byte disk ID in the MBR. On the Mac, I have volume UUID's for HFS+ volumes (created from 64-bit volume ids), and gpt partition UUID's (neither are shown in the mac output I uploaded before). NTFS boot sectors have a 64-bit volume id (Volume Serial Number).

and
Changing volume's serial number - CodeProject

Very cool stuff. I was looking at the NeoGrub commands in the ANG# files to get some ideas on what all NeoGrub can do. I've read the grub documentation but didn't see a lot of practical examples like the ones in the ANG# files. The ANG# files all use the find command which means they can all only find the first occurance of what they're looking for. e.g. Only the first GRUB (Legacy), or first GRUB 2, or first Wubi. Granted, a user will usually only ever have one occurance but in cases where a user has two or more, it is possible to find a tag file unique to a partition selected by the user, then run whatever from that drive.

Thanks You're getting a real feel for what it's like in my seat - a lot of options if you're creative enough.

You're spot-on correct though - it only finds the first. The problem: No matter what I try and do, etc. I can never find a way to list all drives and partitions from Windows that agrees with what GRUB will show me *for all different computer and hard drive configurations*. So I can't display the drop-down menu generated by my BootGrabber output that will coincide with the variables in a menu.lst for GRUB. So I have to resort to searching instead of hard-coding the paths. Tagging won't work because Windows doesn't have read/write ability on non-Windows filesystems, so I can't tag linux or mac partitions.

title BootCamp2
find --set-root --ignore-floppies --ignore-cd /BootCamp.tag
map () (hd0)
map (hd0) ()
map --hook
makeactive
chainloader /ntldr

The above finds a tag file (a zero length file whose contents or name doesn't matter) that I created on my second Windows XP partition, then boots the NTLDR on that partition. This is better than the next to useless NTLDR option provided by BOOTMGR. Is there a way to make NeoGrub not dump output to the screen for the commands or whatever it's doing unless there's an error?

That's verrrrry similar to what I do with HnS, except it won't work. The problem: makeactive is permanent (as previously mentioned). So it'll work the first time, but when you come to reboot, it'll try to find bootmgr and the bcd on the partition that has NTLDR. Needless to say, it's most likely to fail miserably in many cases.

Another feature: Allow the user to create their own AutoNeoGrub commands like the one above. Sure we can edit menu.lst but then we have to go through a Grub menu after going through the Vista menu. If we wanted to do that then we would be using EasyGrub instead of EasyBCD and you wouldn't have created all those wonderful bootloader options for the BCD.

I like. 2.1 perhaps or sooner, who knows

Speaking of bootloader options, I tried to boot from a Windows XP SP 3 iso (from MSDN) but got a blue screen. Is that normal for this iso? It gets as far as the message "Starting Windows". Booting from a burned CD of the iso works fine.

A lot of system setup CDs (Windows, Linux) have problems being run from a read-only virtual hard disk. They assume hard disks are write-available. Or they have issues due to recursive loops when they try to detect the hardware config for themselves instead of taking what NeoGrub already loaded.

 

[joevt]

Don't think it's worth it for such a minor dialog

I was thinking that the inability to not know if a BCD is the System BCD may contribute to some other problem like the corrupted backup BCD problem I reported.

Just enable "Expert Mode" in the options.

That will disable all extra alerts. I'm afraid I might miss some important information while doing some other action. A "Don't show again" option for each alert allows the user to read an alert once and decide how important it is to read that alert again depending on the actions being taken.

Check out HKLM\System\Setup\SystemPartition ... you'll find that Windows has it wrong.

You're right. I found it was pointing at \Device\HarddiskVolume10. I googled that and found dmdiag.exe which is installed from the Windows XP CD support folder. I ran dmdiag.exe -v and saw that Volume10 is my Windows Vista 32 partition.

Changing \SystemPartition to point to Volume11 makes EasyBCD write the boot.ini and other files to the correct partition, but \SystemPartition gets set back to Volume10 upon restart even if I delete \SystemPartition. Why is this getting set wrong?

How does your expectation of \SystemPartition differ from the drives pointed to by %SystemDrive% or %SystemRoot% (which are correctly pointing to my Windows XP partition on drive C)? Maybe you could warn when %SystemDrive% doesn't match \SystemPartition.

IO.SYS and MSDOS.SYS aren't normal for XP partitions

I read that NT type operating systems have these zero length files for compatibility with old utilities.
NT Creates MSDOS.SYS and IO.SYS Files on IBM PC-DOS Machines

HnS is only based on Grub4Dos

I thought NeoGrub is also based on Grub4Dos and since you worked on both, that HnS and NeoGrub would be more closely related to each other than to Grub4Dos. Does HnS have grub commands that NeoGrub doesn't? Or does it have special code that NeoGrub doesn't?

NeoGrub *can* change the boot disk - but with a huge caveat: it does so permanently, not just for the next boot.

Are you talking about the active partition flag? Are there any other permanent changes made by NeoGrub besides the active partition flag? I was originally referring to the ability of the map command to swap hd# and hd0.

I have just the one disk though, so I don't know if I can reproduce.

I think you only need one HFS partition to reproduce the file system number problem. You just need to make the HFS partition visible to Windows by making sure it has an entry in the MBR. MacDrive has a free trial. Boot Camp 3 from the Snow Leopard DVD also has an HFS file system driver (applehfs.sys). If your PC has a FireWire port, you could connect your Mac in Target Disk Mode.

I was looking at the output from dmdiag.exe and saw that all my partitions had a Partition Type of 7 (except for the EFI partition type 0xEE). I googled Partition Type and found Disk Partition Types (Windows) which says 7 is for PARTITION_IFS where IFS stands for Installable File System. I think we (or the file system developers) are confusing partition type as defined in the MBR, and the partition type as returned from Disk Management which are both different from file system as returned by Volume Management.

Both MacDrive and applehfs.sys report HFS partions as type 7. If they are removed then the partition is reported as type 0xAF (the number in the MBR).

I installed an ext2 file system from a Source Forge project (Ext2Fsd Project), changed the Ubuntu partition type in the MBR to 0x83 (for Linux), then mounted the Ubuntu partition as EXT2. That partition gets reported as type 0x83. So ext2fsd is doing something wrong or MacDrive and applehfs.sys are… The ext2fsd project has a nice utility (Ext2Mgr.exe) for viewing all the volumes and partitions (like Disk Management does except with more info and source code).

Changing volume's serial number

Interesting. dir /w shows only the first 4 bytes of the 8 byte NTFS Volume Serial Number.

Tagging won't work because Windows doesn't have read/write ability on non-Windows filesystems

Right. This is one reason a manual AutoNeoGrub would be nice. NeoGrub can read ext2fs partitions (otherwise the Linux options wouldn't work) so the user can tag them manually and NeoGrub can find them.

The problem: makeactive is permanent (as previously mentioned)

I normally use rEFIt (rEFIt - An EFI Boot Menu and Toolkit) to select between different OS's. One thing it does is set the active flag of the selected Windows partition before handing control over to the legacy (i.e. Windows) boot loader to make sure that partition is the one that the legacy boot loader loads.

In this case makeactive isn't necessary because there's only one Windows partition on that drive and it is usually already active. I would use makeactive for other drives containing more than one Windows partition. Since it makes the new partition the active partition, the new partition would need the same boot setup as the original partition to get back to the original partition (if rEFIt isn't being used). All my XP's and Vista's have BOOTMGR and NTLDR so they can all boot individually. That's why I use EasyBCD to edit the system BCD's on other Windows partitions.

The thing with HnS is that it hides other partitions (correct me if I'm wrong). What if there's a file on one of those hidden partitions that I want to look at?

As a Mac user, I'm not overly concerned about or familiar with restore points and other Vista info that HnS protects from XP. I might miss them when I need them but I haven't used Vista enough to encounter that situation.

 

[Terry60]

HnS only hides partitions when XP is booted, and only those partitions containing Vista/7 restore folders. If there's a file on Vista you want to see from XP (shared data e.g.), you should put it on a drive which contains no Vista/7 apps or OSs, and there's no problem. You can't use XP to look at anything on a Vista/7 drive if it contains a restore folder. Pure user data doesn't get changed by SR, so doesn't need to be monitored, but you have to configure your system to separate OS/apps/data if you need to be able to access from XP as well as your other OSs.

 

[mqudsi]

That will disable all extra alerts. I'm afraid I might miss some important information while doing some other action. A "Don't show again" option for each alert allows the user to read an alert once and decide how important it is to read that alert again depending on the actions being taken.

Good point. In the future, I'll do that.

Changing \SystemPartition to point to Volume11 makes EasyBCD write the boot.ini and other files to the correct partition, but \SystemPartition gets set back to Volume10 upon restart even if I delete \SystemPartition. Why is this getting set wrong?

BootCamp isn't reporting the correct boot drive info to Windows.

How does your expectation of \SystemPartition differ from the drives pointed to by %SystemDrive% or %SystemRoot% (which are correctly pointing to my Windows XP partition on drive C)? Maybe you could warn when %SystemDrive% doesn't match \SystemPartition.

You seem to misunderstand Microsoft's (admittedly very confusing) terminology. "SystemPartition" means "boot drive" while "SystemDrive" and "SystemRoot" mean "current operating system drive/root". Terribly poor naming on their behalf.

I thought NeoGrub is also based on Grub4Dos and since you worked on both, that HnS and NeoGrub would be more closely related to each other than to Grub4Dos. Does HnS have grub commands that NeoGrub doesn't? Or does it have special code that NeoGrub doesn't?

Yes. At the time that I wrote HnS, I modified the Grub4Dos code extensively to add the `--make-active` switch to the `find` command. At the time, the `map hd() ....` terminology was not possible. NeoGrub doesn't need these features.

Are you talking about the active partition flag? Are there any other permanent changes made by NeoGrub besides the active partition flag? I was originally referring to the ability of the map command to swap hd# and hd0.

No. Everything else, even swapping disks, etc. is temporary. But changing the active partition is permanent, which makes it impossible to address the NTLDR issue in that manner.

I installed an ext2 file system from a Source Forge project (Ext2Fsd Project), changed the Ubuntu partition type in the MBR to 0x83 (for Linux), then mounted the Ubuntu partition as EXT2. That partition gets reported as type 0x83. So ext2fsd is doing something wrong or MacDrive and applehfs.sys are… The ext2fsd project has a nice utility (Ext2Mgr.exe) for viewing all the volumes and partitions (like Disk Management does except with more info and source code).

I remember now about the IFS also being 0x07. EXT2 does it right, Apple and MacDrive do it wrong. Back in the day, I wrote a filesystem for a RamDisk and I used to retrieve my custom Partition ID correctly.

HOWEVER, in the light of this information, I'll probably have future versions of BootGrabber manually parse the MBR for that info instead of asking the OS for its opinion on the matter.

Right. This is one reason a manual AutoNeoGrub would be nice. NeoGrub can read ext2fs partitions (otherwise the Linux options wouldn't work) so the user can tag them manually and NeoGrub can find them.

Hey, I'm already sold on the idea. I'll work on it post 2.0.

I normally use rEFIt (rEFIt - An EFI Boot Menu and Toolkit) to select between different OS's. One thing it does is set the active flag of the selected Windows partition before handing control over to the legacy (i.e. Windows) boot loader to make sure that partition is the one that the legacy boot loader loads.

...

As a Mac user, I'm not overly concerned about or familiar with restore points and other Vista info that HnS protects from XP. I might miss them when I need them but I haven't used Vista enough to encounter that situation.

Yeah, your situation is quite different from our usual users. I know rEFIt, and it does make things easy.

 

[joevt]

BootCamp isn't reporting the correct boot drive info to Windows.

BootCamp is just a simple partitioning utility for Mac OS X and a set of drivers and a control panel for Windows. Other partitioning tools can do the same thing and most of the drivers are available from the original manufacturer. If there's a problem then it's with the BIOS compatibility loaded by EFI. I don't doubt there's problems with the BIOS. It's not configurable so my Mac Pro can't boot into Windows in AHCI mode without a hack. Also, I think there's some requirement that Windows XP has to be the last primary partition in the MBR but I can't find that in official documentation anywhere. Do real PC's have that problem? My Vista partitions work fine where ever they are.

I think Windows XP also has a problem if it's partition is moved to a different position in the MBR from the original position it was installed as. I'm not sure about Vista...