Unanticipated EasyBCD problem on swappable hardware boots

a.k.a.

a.k.a.

Member
Hi Guru and co.,

I've had a lot of fun so far with EasyBCD. It's done almost everything I could imagine. In fact, the only problems I'm encountering are ones no one could have anticipated. :?? I'd like to draw your attention to them, because I need a workaround, and anyone else with a swappable hard disk drive will need a workaround too.

Here's the original thread where you and Makaveli were exploring some configuration options:
http://neosmart.net/forums/showthread.php?t=1330

The configuration I settled on is the following:
HDD 0 is an internal drive in my ThinkPad laptop:
Entry 1: Windows Server 2008 x64 RC2 (the new release candidate with the hypervisor)
Entry 2: Vista x64 SP1 RC
HDD 1 is an internal drive in a swappable bay -- a swappable bay that all ThinkPads have:
Entry 3: Vista x86 (no SP1)

Here's the EasyBCD summary screen:
"There are a total of 3 entries listed in the Vista Bootloader.
Bootloader Timeout: 5 seconds.
Default OS: Windows Server 2008 x64 RC2
Entry #1
Name: Windows Server 2008 x64 RC2
BCD ID: {current}
Drive: C:\
Bootloader Path: \Windows\system32\winload.exe
Windows Directory: \Windows
Entry #2
Name: Vista x64 SP1 RC
BCD ID: {e3d0a638-afa6-11dc-948b-001c251892ad}
Drive: D:\
Bootloader Path:
Windows Directory: \Windows
Entry #3
Name: Vista x86
BCD ID: {e3d0a637-afa6-11dc-948b-001c251892ad}
Drive: Deleted Partition
Bootloader Path: \Windows\system32\winload.exe
Windows Directory: \Windows"

I'm having BSOD shutdown errors with the Vista x64 RC. Probably this has nothing to do with EasyBCD; more likely it's an unsigned driver error. There have been a cascade of consequences as a result, including an Autochk run anytime either Server or Vista x64 boots on HDD 0, with Autochk hanging on booting into Vista x64. There are two quick troubleshooting questions around Autochk that I need answered to get this resolved, though they're not related to EasyBCD.

1. I have to go into the registry to turn Autochk off so that Vista x64 can boot, but I don't know which registry is initiating the Autochk run. Autochk is running both when Server boots and when Vista x64 boots, but since the BCD files are on the Server partition, I'm wondering whether it's more likely that Server is triggering Autochk for BOTH partitions, or whether Server and Vista x64 are EACH initiating Autochk independently. (If the former, I'll have to change the Server registry. If the latter, I'll have to change the x64 registry.)

2. Let's assume it's Vista x64 that's triggering Autochk in this instance, but now I can only boot into Server. So what do I need to do in order to get from within OS #1 (Server) into and edit the registry of OS #2 (Vista x64)?

For learning purposes I want to give the Regedit fix for Autochk a try, so I can try to locate the source of the original shutdown BSODs, but I realize I may need to do a reinstallation of Vista x64.

So that's where there are issues that have arisen with EasyBCD itself:

3. I was on the verge of reinstalling the Vista x64 entry, and found out that the ThinkPad DVD drive won't boot now. It operates completely fine from within another OS. When I put a bootable (install) disk in, however, it moves straight from BIOS to the EasyBCD boot options screen. :scared:

My uneducated hunch is BIOS might still be intact, but BIOS is relying on boot drive letters ( D: ) rather than the device numbers (HDD 0) that BCD uses, and on my configuration D: is no longer the DVD drive, but an OS installation. Here's why it's not D: In my experience so far, Vista's Computer Management --> Drive Management process becomes more erratic about which letter is assigned to which device as partitions and drives multiply, so the chances of the DVD ending up with D consistently across 3 OSes were pretty slim to begin with. :angry: And in all ThinkPads, the DVD drive is one of the devices housed in the swappable internal bay. Hence, as a swappable DVD drive, it isn't always visible to the OSes located on the main internal HDD, and so I went ahead and assigned drive letter D: to an OS rather than to the DVD. So there's a possibility that the DVD might not be disabled in BIOS, but it's not called D: anymore, so BIOS can't locate it. (I'm writing this before I check BIOS settings, because it's not as important, in my mind, as getting a fix into EasyBCD to accommodate swappable boot devices like those on ThinkPads, Asuses and desktops.)

I read this forum thread about zapping BIOS to restore DVD boot options
http://neosmart.net/forums/showthread.php?t=1350
but really, it doesn't seem to be the appropriate fix if you have a lot of erratic behavior in Vista's Drive Management to begin with that makes it often very unlikely that the optical drive will have a fixed drive letter.

Nor do I understand what's being discussed as a solution right now, so if this is the only way to resolve the issue, I could really use some help with the explanation (just like the original forum poster did).

Here's an alternate approach: Can you rewrite the boot configuration file that EasyBCD (or Vista) uses in such a way that there's more flexibility in changing the priority of boot DEVICES (as opposed to boot PARTITIONS)? This would be something of a trick:
a. Normally, the entries for the OSes on the fixed internal drive would always listed as installed on "HDD 0." The OSes on the swappable internal HDD would be on "HDD 1."
b. But if you want to boot off a DVD that's only in place on some occasions (and not assigned drive letter D), then this will have to be "device 0" (or whatever). :grinning: The fixed internal HDD will have to be described as "HDD 1" instead. The swappable HDD will have to be called "HDD 2."

4. Another minor glitch (unimportant, but worth mentioning) with the troublesome Vista x64 partition is the following: I can see the x64 entry in all of the EasyBCD screens EXCEPT the Advanced Settings screen. There, my only two options are modding Server and modding Vista x86. The Vista x64 entry doesn't appear, even after restoring the BCD file and restarting EasyBCD. (Admittedly, I haven't rebooted after restoring the file.)

5. Easy question: Assuming I have to reinstall the secondary OS (Vista x64), will it overwrites the original file? If so, then correct me if I'm wrong, but I'll no longer be able to boot into my primary OS to restore the file -- I'll have to boot into the secondary OS, install EasyBCD there, and restore the BCD file from that partition. Is that right?

6. This leads to a related question: Is EasyBCD going to be confused if I install it on EACH of my three OS partitions? It would be very convenient to do this. :booyah:

7. I'm beginning to think it would be a good idea to keep the BCD entry on a partition OTHER THAN than the primary OS partition. For instance, if my OSes are on partitions C, D and E, I'd put the BCD store on a very small A or B partition. The logic would be that I would be able to reinstall my primary OS if need be, without having to restore or rebuild the BCD store per se. Is there an easy procedure for doing so? :brows: (Amidst the other issues, I'm not thinking too clearly about this right now.)

Happy holidays to all! :tongueout:
a.k.a.
 
Last edited:
Okay i would say that your Vista 64 problems are related to a unsiged driver. That has caused more issues that EasyBCD ever would. I would explore that option long before i would say it is a bug in EasyBCD cause technically you can NOT used unsigned drivers in Vista 64. Which is why i say that is the problem before EasyBCD.

There is no way to make EasyBCD choose to boot by device cause EasyBCD is jsut a TOOL by which to modify and edit the Vista bootloader to load various OS's. It is not the actualy bootloader itself. That is created by M$ and used by Vista. Id you wish to have it boot by device you ahve to contact M$ and have them re-write the BCD.

If you reinstall Vista 64 you shouldnt have to reinstall EasyBCD or the BCD at all. It should see the BCD and adjust it accordingly. At least it has with me everytime i reisntall Vista with my dual boot or tri boot setup.

The thing about Vista 64 not appearing in Advanced settings Guru will have to address.

As for #6 EasyBCD will not be confused. I do it with XP/Vista here.

As for #7 this wont do you any good. As a backup yeah. But for the actual boot no. The boot info in kept on the first partition of the first hard drive. moving it to a partition A or B wont do you any good unless you use that strictly for boot. Cause the info will be stored on that parition at all tiems. If you move it then you wont be able to boot to a OS. (at least Windows)

The problem with swappable drives is that the letters are never the same. So having them in with your boot paths doesnt help. While you have it set to boot from the first sw2appable drive. Say E:\ this time. Who is to say that when you swap that one out and put a new one in that that one wont be recognized as F:\? Or it could be E:\ again. The swappable drives are so tough to configure for cause you have to take into account all the little things. Like a USB Thumbdrive left in by accident. That will affect your swappable drive boot letter. Or if you plug in 1 swappable drive and then plug in a 2nd drive.

The swappable issue isnt common. That is why it was never addressed. Very FEW people actually use swappable drives as boot drives. If any. For the reasons stated above. IT is just to tough to account for all the little things that affect their boot priority.
 
Hi again Mak,

Thanks for sorting me out about these things again. Much appreciated!

About this:

The problem with swappable drives is that the letters are never the same. So having them in with your boot paths doesnt help.
Click to expand...

I couldn't agree with you more. In fact, I had to make a trip into the registry to get the boot letters aligned, because one of the three OSes actually decided to assign the Intel Robson NAND a drive letter, which mucked everything up regarding the drive letter assignments. :angry: As you know, with Vista's Disk Management, the drive letter of the active partition is "locked" within the other OSes. But Vista's authors apparently presumed that locking the entry would make it consistent across OSes to begin with, which in this case it clearly wasn't. Obvious design flaw there. :x

3. On further experimentation, It turns out that the DVD player DOES still boot with a little more tweaking. All it took was "refreshing BIOS's memory," so to speak. For whatever reason, when I moved the DVD drive's place in the BIOS boot order from 2nd to first -- ahead of USB booting -- it would boot. :tongueout: It makes no sense to me why this would help, because 2nd priority was ahead of HDD 0 in the boot order to begin with. Oh well. Glad to have the option to reinstall.

5. I'm also glad to hear from you that a reinstallation of Vista doesn't overwrite the old BCD file. (At least MS had some sense to see this part of the multibooting thing clearly. :wink:)

Regarding 7: It would be great to get a little more clarification from you on your remarks about saving the BCD entry to a partition being impossible anyplace besides the first boot partition. You wrote back that,

"The boot info in kept on the first partition of the first hard drive. moving it to a partition A or B wont do you any good unless you use that strictly for boot. Cause the info will be stored on that parition at all tiems. If you move it then you wont be able to boot to a OS. (at least Windows)"
Click to expand...

By first partition, do you mean first partition WITH AN OS, or first partition on the drive? :lup: Right now I have 2 blank 1.5GB partitions ahead of the first boot entry (i.e., partitions A & B), in case in the future it seems advisable to install WinRE and/or BitLocker after all. So those are the first partitions, but I don't suppose the BCD entry is on A or B. It's on C, right? (The first boot partition.)

But my understanding is that there's a distinction between the "active system partition" where the BCD entry is stored, and the "boot partition," where the OS is. Could you make partition A active and place the BCD entry on it, without installing an OS on A? Or am I still mistaken here, and BCD resides on the first *boot* partition.

So there are two questions left where some more guidance could help:

1. I have to go into the registry to turn Autochk off so that Vista x64 can boot, but I don't know which registry is initiating the Autochk run. Autochk is running both when Server boots and when Vista x64 boots, but since the BCD files are on the Server partition, I'm wondering whether it's more likely that Server is triggering Autochk for BOTH partitions, or whether Server and Vista x64 are EACH initiating Autochk independently. (If the former, I'll have to change the Server registry. If the latter, I'll have to change the x64 registry.)

2. Let's assume it's Vista x64 that's triggering Autochk in this instance, but now I can only boot into Server. So what do I need to do in order to get from within OS #1 (Server) into and edit the registry of OS #2 (Vista x64)?
Click to expand...

Happy booting to all, and to all a good night!

a.k.a.
 
3) This isn't an EasyBCD-related issue, actually.
The BIOS cannot understand the concept of drive letters and numbers (this is purely an OS-specific function).

It hands control off to the devices listed in the BIOS setup in the order you've specified. EasyBCD's boot files are not triggered until after the BIOS selects the hard drive that EasyBCD's boot files are on.

4) Sounds like a bug. Can you please post the contents of "Detailed Mode" here? (use a
Code: 
 tag, please).
 
5) Shouldn't overwrite, it'll detect the existing BCD setup and use it.
 
6) Like Mak says - no :)
 
7) Even if you need to reinstall your primary OS, it shouldn't be an issue. So long as you don't format the entire partition (so that the BOOT folder is not deleted), you should be good to go.
 
With regards to the Autochk issue, no clue off the top of my head but I'll look around.
 
Guru,

4. Is this what you're after? It's the only verbose mode output I could find.

Code: 
Windows Boot Manager
--------------------
identifier {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device partition=C:
description Windows Boot Manager
locale en-US
inherit {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default {4d16ff49-afaa-11dc-a933-c4f9bb2fc85d}
displayorder {4d16ff49-afaa-11dc-a933-c4f9bb2fc85d}
{e3d0a638-afa6-11dc-948b-001c251892ad}
{e3d0a637-afa6-11dc-948b-001c251892ad}
toolsdisplayorder {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout 5
Windows Boot Loader
-------------------
identifier {4d16ff49-afaa-11dc-a933-c4f9bb2fc85d}
device partition=C:
path \Windows\system32\winload.exe
description Windows Server 2008 x64 RC2
locale en-US
inherit {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
bootdebug No
osdevice partition=C:
systemroot \Windows
resumeobject {4d16ff4a-afaa-11dc-a933-c4f9bb2fc85d}
nx OptOut
pae ForceDisable
sos Yes
debug No
Windows Boot Loader
-------------------
identifier {e3d0a638-afa6-11dc-948b-001c251892ad}
device partition=D:
description Vista x64 SP1 RC
osdevice partition=D:
systemroot \Windows
Windows Boot Loader
-------------------
identifier {e3d0a637-afa6-11dc-948b-001c251892ad}
device unknown
path \Windows\system32\winload.exe
description Vista x86
osdevice unknown
systemroot \Windows


1. On the Autochk hang, would running one of the options under EasyBCD's Diagnostics Center be a good idea? Or do I risk erasing data?

2. Still curious about getting into OS 2's registry from OS 1.

7. Ok, I can see how it's robust enough to leave the BCD files on the first boot partition. Still, is it possible to place them on another partition? (Just curious.) Also, if I merge the first boot partition (C) with another partition (an empty B partition), does that destabilize things? Presuming not.

8. By the way, I've been eyeing Tweak VI. Is it possible to run it on Server or on Vista x64?

Cheers!
a.k.a.
 
Well, I don't think it's a bug actually.
Your Windows Vista x64 entry is missing the "path" line:
Code: 
path \Windows\system32\winload.exe
which is how Vista distinguishes its entries.

Autochk is not a bootloader-caused problem, so resetting the BCD registry will not help.

7) so long as its still the active partition, no problem

(We didn't write TweakVI) but it'll run just fine on both :smile:

You can open a registry hive from another OS by loading c:\windows\system32\config as the selected hive for these steps:
Microsoft Corporation
 
By first partition, do you mean first partition WITH AN OS, or first partition on the drive? Right now I have 2 blank 1.5GB partitions ahead of the first boot entry (i.e., partitions A & B), in case in the future it seems advisable to install WinRE and/or BitLocker after all. So those are the first partitions, but I don't suppose the BCD entry is on A or B. It's on C, right? (The first boot partition.)

But my understanding is that there's a distinction between the "active system partition" where the BCD entry is stored, and the "boot partition," where the OS is. Could you make partition A active and place the BCD entry on it, without installing an OS on A? Or am I still mistaken here, and BCD resides on the first *boot* partition.
Click to expand...

In regards to this question i am almost positive that Windows places the boot files on the first drive used. Meaning the first drive with a OS. Sicne that is technically the boot drive cause of the fact that it caontains info about the OS and such. The other drives would jsut be seen as data drives.

2. Still curious about getting into OS 2's registry from OS 1.

7. Ok, I can see how it's robust enough to leave the BCD files on the first boot partition. Still, is it possible to place them on another partition? (Just curious.) Also, if I merge the first boot partition (C) with another partition (an empty B partition), does that destabilize things? Presuming not.
Click to expand...

Guru pointed this out how you can gain access to another OS's Registry.

As for the boot files as Guru said and i have said there as well. You can put them anywhere. But they would be a backup. Not the actual files. You can do whatever you want with the partitions as long as you dont move or delete the boot files from teh Windows Boot Drive.

I have enlarged and shrank my Boot Drive several times and have never had any issues at all with my boot. I also have a backup of my BCD files on my external drive as well. But i can not boot from that drive nor do i use that drive for anything other than backup.:wink:
 
Oh yes - if you do delete your BCD files it should suffice to restore EasyBCD's settings. Always have a backup handy.
 
Ok, I made the changes to restore Vista x64. There's something a little awkward about the GUI -- particularly getting the buttons pushed in just the right order for it to write correctly. :scared: For a while, I ended up with all sorts of screwy stuff, like two Vista x64 entries, then no Vista x64 entries, then a restore back to the already corrupted entry, then an erase and reset, and finally another restore with correct edits. Yikes!

Bottom line is, it seems to have worked well, even with all that fumbling around to get it right.

Well, just for the sake of constructive feedback / product improvement, would you take a suggestion of two very minor interface tweaks?

First UI tweak:

In the Add/Remove entries screen, you can Add Entry, but it remains invisible -- i.e. the new entry doesn't appear anywhere -- not in the boot order window (Manage Existing Entries window) above the Add Entry window, not in the View Settings window, etc. The impression is that EasyBCD hasn't registered that you've added a new entry, and you've likely corrupted the durn thing. The newly added entry only shows up in the Manage Existing Entries window AFTER you commit to saving?!? (Scary.) It would be peace of mind for users if, before they committed to saving, they could see evidence in the Manage Existing Entries window that EasyBCD heard its user loud and clear. Plus, it just trips people up.

If you're worried about giving people the impression it's saved when it isn't (yet), then
1) Display the added-but-not-yet-saved (or deleted-but-not-yet-saved) entries BEFORE the save button is pressed, but add a tag next to those entries saying it is not finalized until Saved.
2) Add an extra warning at the top of the screen, saying that any edits are not final until saved.

Second UI tweak:

The other thing I noticed is that under the Diagnostics Center --> Reset BCD Storage option, there's just the plain-vanilla option to use "Vista" as the name of the default entry you're specifying. There's no way to retitle it the entry name you intend to use. (The user must remember to go to the Change Settings screen after committing to the reset process, which is also a little disconcerting.) Would be a bit clearer and more convenient to allow users to edit the name of the newly-created default entry before resetting. For instance, the default "Vista" for my multiboot setup isn't Vista per se, but actually "Windows Server 2008 RC2." Or suppose you had an x64 install and an x86 install. You'd want to be able to specify the name of the default at the outset in that case as well, rather than leave it as vague as "Vista."

Again, thanks for all this, Guru & Mak! :wink:

a.k.a.
 
It seems there's a bug in EasyBCD.

EasyBCD does update the list when you add a new entry, but I just found out that if you have only one entry, adding a second does not update the list. Adding anything beyond the second entry updates the list in real-time.

I don't know what you mean about saving changes - the minute you press "Add Entry" changes are instantly saved.

As for the second UI tweak: I can change it to read "EasyBCD-Recovered Windows," would that help? I'm not going to add yet another prompt asking the user to name the recovered entry, and most people know about the "Change Settings" page's rename options.

Thanks for reporting this bug, I'll see what I can do :smile:
 
"The problem with swappable drives is that the letters are never the same."

Mak.
You've got to be well organized as you create a new OS, then you can avoid this. Ever since WME I've always made sure that every new OS install - First thing after the install finishes, I rename/reletter my DVD drives, plug in every external HDD, Flash drive, scanner, camera etc one at a time, give them their unique letter assignment and name, and only then carry on updating the OS and adding the 3rd party apps.
Then whenever you plug something in on any system you built, it comes up with the name, and on the drive letter that you know it by.
It doesn't half make life simple in the long run, if you spend 15 minutes early on making the system look like you want it to appear in future.
 
Terry i fully understand that as i do it myself. But the thing with swappable drives as i have pointed out is that upon plug in to the system itsem you never know wha tht BIOS letter will be assigned to it. The OS doesnt matter at that point cause it isnt loaded. That is where we are heading. But the BIOS at that point has assigned it a drive and number. Which is what is needed at boot.

Now we can have this configuration stored in our boot tables but once you swap the drive out there is no knowing what that config will be upon plugging it back in next time. We can be as sorted as we want within the OS. But ultimately the BIOS will determine the drive and placement once it is plugged in. That is where the issue comes in with swappable drives.

Have 1 drive that you label E:\Vista X64 is great within the OS. But once you remove that drive and plug in another, or forget to remove that drive and plug in another, or leave a Thumbdrive plugged in and swap out a drive, or any other combination of 1,000 things is where the problems come in. Who knows if the BIOS will see that as Drive E:\ again a 2nd time once you plug it in. Yeah once you get the OS fired up it will remember your placement and drive lettering. But that doesnt mean the BIOS which is a simple yet stupid (Compared to the OS drive config utilties) drive utility, will see it the same way every time.
 
Actually, the BIOS doesn't speak in terms of drive letters.... It references attached drives with the same ARC path used in boot.ini: by controller id and disk id. It does not identify individual partitions, and therefore does understand the concept of letters or numbers.

The OS interfaces with the BIOS to identify drives, and then higher-up in the chain analyzes the MBR for partitions and other layouts.

The BIOS allows for an OS to access a drive either by:
a) the ARC path
b) the UUID

The UUID is a unique value assigned to each physical drive itself, it's a GUID in that it doesn't repeat - no two are identical.

Linux uses this to allow the mapping of drives to partitions on the fly (`mount -a` is the best example) if the UUID is mapped in FSTAB.

I have no idea what system Windows uses to identify drives, but I know that certain versions of Windows under certain configurations will use the UUID - for instance, when you plug a USB stick in the PC and it is assigned drive D:, then you remove it and put another one instead, you'll notice that sometimes the new stick is Drive E: and not D: - in this instance, the PC has been configured to go by UUID rather than location.

I'll see if I can't find an MS resource on how Windows determines the letters for Drives, it's certainly an interesting concept.
 
Back
Top