questions about Vista vs. XP partitioning

I've been messing around with repartitioning on a new laptop running Vista Home Premium w/o SP1. As I mentioned in other posts, I haven't been able to repartition without getting some errors/warnings, even using the recovery disk in safe mode, but the machine seems to boot and run normally.

I've been reading a bit about differences between Vista and XP and I have a few questions.

1. Do I understand it correctly that in all previous versions of windows the first partition started in sector 63, but with Vista it starts at sector 2048? Does this mean Vista won't even try to access sectors less than 2048?

2. The machine boots normally, so I'm not sure if I really understand the underlying issues. The code in sector 1 appears to be valid MBR code and the partitions are defined there correctly, so is that enough to satifsy Vista for booting, even though I have data in sectors 63-2047? Should Vista normally have MBR code in sector 1, and nothing in sectors 2-2047?

3. When looking at my HD with Disk Director in hex mode, my first partition appears to start at sector 63, and has what appears to be bootmgr code in it because the text strings in that sector relate to bootmgr problems. Sector 2048 has some random data in it. Also I should add that the first partition is not the boot partition, it was originally a recovery partition shipped from the factory, and now I've changed it to a data partition. The first sector of the boot partition appears to be the same code as in sector 63, although I haven't done a complete comparison on it. So I'm guessing that on bootup it reads the MBR stuff at sector 1, jumps to the boot partition and reads what it needs from that sector, and because its outside of the first 2048 sectors it just goes on normally from there and doesn't cause any problems. Would I be seeing problems if my first partition was the boot partition and it didn't start at sector 2048 or greater?

4. Is the data between sectors 63 and 2047 accessible by Vista? Should I change the first partition so that it starts at sector 2048 instead of 63?

5. I'm trying to remember back to the first time I repartitioned, and I think there might have been some small unallocated space at the beginning of the first partition, but I can't remember for sure. If Vista had that area unused, and I tried to extend the partition into that area with Disk Director shouldn't DD have warned me that I shouldn't do that? It appears that DD was adhering to the old windows format, not the newer Vista format, and allowed me to extend the first partition all the way back into sector 63, when it should have stopped me at sector 2048.

6. If I used the recovery disk, then Acronis doesn't really know what OS I'm using, so in that case it wouldn't be able to tell me where to stop the partition. I think I resized the data partition in windows though, but I can't recall for sure. I guess from now on its probably up to me to know which sector to start the first partition at, and only use the recovery disk.

So I know I asked a lot of questions, but could someone with a good understanding of this topic please answer all my questions.

thanks,

doug

 

Doug:

Vista is the first (as far as I know) operating system to support partitioning standards for the future large-sector hard disks which are not even on the market yet. Up until now most hard disks have used a sector size of 512 bytes. With hard disks of 1 TB becoming commonplace, the number of 512 byte sectors on a 1 TB disk is huge and will continue to grow in the future, so provisions are being made for a time when the size of a sector will increase. With larger sectors then the number of bits needed to describe the sector number will not grow out of control. As of today, there aren't any large-sector disks (as far as I know) but they will appear at a future date.

So that is the underlying reason for the changes made to the Vista disk partitioner, DiskPart. If you create partitions with Vista DiskPart or with Vista Disk Management console then the offset between partitions will be 1 MB (2048 sectors) instead of the historical standard offset of 32 kB (63 sectors), or what is called "alignment on cylinder boundaries". This change is supposed to improve disk performance when the large-sector hard disks become available.

However, it is important to note that the only change made by Vista was to the partitioning software (DiskPart and Disk Management Console). So this only becomes an issue when you use Vista tools to create or modify partitions. Vista itself does not care whether it is installed to a partition with 63-sector or 2048-sector offset or any other offset, for that matter. So you may, on your disk, have any arbitrary offset between partitions and Vista won't know or care. The same is true for other operating systems - when they are running they are blissfully unaware of the underlying partition structure.

As an example, the disks on my two Vista PCs were partitioned using tools (Acronis Disk Director) that create partitions with the older 63-sector offset, and from your descriptions in 2) and 3), so were yours, or they were created by XP and you later installed Vista to existing partitions.

Not necessarily. The MBR in sector 1 contains boot code and the partition table. The boot code only does one task - it searches the partition table to find the partition that has the "Active" flag set, jumps to its starting sector, and begins executing the code at the beginning of the partition (the partition boot record). Offsets are irrelevant. As long as the partition table can locate the start of the partition it doesn't matter what the offset is between partitions. If the partition table says that Vista's partition begins at sector 63 then that's where the program will jump to when booting. If it says it begins at sector 2048 then it will jump there.

No you wouldn't. Your Vista partition could be the first partition and it could start at sector 63 and it would work just fine. If that's where the partition table says it is located then that's where it will boot from. Your disk was partitioned by older partitioning tools and has the standard 63-sector offset between partitions. That's perfectly fine.

It depends on whether the sectors are contained within the Vista partition. If the Vista partition starts at sector 63 then yes, Vista will be able to read those sectors.

Not unless you want to be limited to using only Vista's partitioning tools to manage your disk. The available tools in Vista are not as flexible as third-party partitioning software, so if you want to use Acronis Disk Director or other tools with their nice graphical interfaces then you're better off sticking with the older standard of 63-sector offset.

DD conforms to the older partitioning standard and would naturally want to create a primary partition that is offset 63-sectors from the preceding partition. When you made a change with DD the starting and ending sectors of the Vista partition may have been modified. That's OK. As long as they are correctly entered into the partition table then it won't matter. As an aside, while experimenting I've ended up with odd offsets on partitions before (such as 72 sectors) on both XP and Vista, and both worked fine because DD made the correct entries for starting and ending sectors in the partition table and that's all that matters.

DD has been pretty good at recognizing where one partition ends and another starts. So far I've never seen it screw up and lose data. However, you are wise to be cautious. It is not a good idea to mix partition offsets on the same disk because you won't be sure how your partitioning software will handle this. Microsoft explicitly warns people not to use XP Disk Management Console to modify partitions created by Vista Disk Management or you risk losing data. So you should pick one offset standard and stick with it. If you want 2048-sector offset then you should only use Vista DiskPart (or Vista Disk Management Console) to modify partitions. If you want 63-sector offset then you should avoid Vista tools and use your favorite partitioning software. Don't mix and match.

 

Wow, thanks for the lengthy reply, that clears up every question I had.

I went in and resized that partition anyway, before reading your reply, because adding the small unused space at the start of the disk will have no real negative effect. Now I have just one more question regarding disk director.

When I clicked on the up/down arrows in the Disk director resizing window, it incremented in 7.xxx MB blocks, so I used one increment. I tried clicking on the actual number and typed in 1MB, but it didn't seem to like that. Now the partition starts at sector 16,071 instead of 63, which is no big deal.

So my question is, can I get a lower resolution than the default disk director value? Sorry if that's a stupid question, I just haven't experimented with the interface that much. Since the partition table has 1 sector resolution, would it be possible to get that resolution using disk director? If so, how?


thanks again.

 

I think that the only way to get lower resolution with DD is to manually edit the partition table. This is very risky since it's easy to miss a digit in a big number and end up with a mess. I would recommend making a full-disk image with TI before attempting to manually edit the partition table in case you do make a mistake.

By default, DD is trying to conform to the older partitioning standard that aligns all partitions on cylinder boundaries. The number of bytes in a cylinder = 512 bytes/sector x 63 sectors/track x 1 track/head x 255 heads/cylinder = 8,225,280 bytes/cylinder. Dividing by 1024 gives 8032.5 kB/cylinder. Dividing by 1024 again gives 7.844 MB/cylinder. This is the increment used by DD.

Since your partition starts at sector 16,071 (16,071 x 512 bytes = 8,228,352 bytes) then there is a one-cylinder gap before the first partition. Is your first partition a primary or a logical partition? If it's a logical partition then DD will reserve a one-cylinder space before it to allow room for a future insertion of a primary partition.

If your first partition is a logical then this is somewhat nonstandard. DD (and Linux and other partitioning tools) will allow you to create a layout like this but you might get strange results (see post #3 for an example) when viewing the layout with Windows Disk Management console. If you want to avoid this you could either use DD to convert the first partition into a primary, or you could move it to the end of the disk to follow your last primary partition. You want to be careful doing either of these to avoid a situation that leaves your OS unable to boot. If you could post a screen shot showing your current layout then that might help.

 

My first partition is a primary, although not the bootable, partition. I show 7.844MB as unallocated at the start of the drive, so that number seems OK, and consistent with your one cylinder gap. What's a bit weird is the partition starts at cylinder 1, sector 7. Not sure why it wouldn't start at cylinder 1, sector 1, but I don't really know enough about this to even guess. Do you have any idea?

 

It could be just weird behavior on DD's part. I've seen it do some pretty strange things occasionally, and for no apparent reason. What does your partition table look like (Disk Editor > View as partition table)? Here is a view of mine with everything aligned on cylinder boundaries. Each entry under "Relative Sectors" is a multiple of 63:



The first partition is Vista, the second is the logical partition container (with 2 logical data partitions) and the third is the Vista boot partition in which I've deliberately moved the boot files out of the main Vista partition and put at the end of the disk.

One sure-fire way to realign partitions is to back them up with TI and then restore them. When TI restores it seems to always set the partition's starting sector to 63 or a multiple. I've done this a couple of times to force realignment.

 

It must just be weird behavior on DD's part then, jeez that's confidence inspiring.

My partition table looks pretty much like yours, since all our partitions are beyond the ~8G limit of the CHS system. My first entry now has the cyl 1, head 0, sector 7 begin point.

I think I'm going to move it back so that's its consistent with at least one of the partitioning standards. I read somewhere that doing that with the Vista boot partition would cause the machine to fail on boot because Vista couldn't find the boot sector in that location. According to you Vista can find the boot code anywhere, it just wouldn't put it in sector 63 on its own, but it will still work. Since my first partition is not my boot partition I can't say for sure what Vista expects. Have you actually tried to boot Vista from a sector lower than 2048 and got it to work? I figure if its true that Vista can't boot from there, then its probably not a good idea to have any data there at all.

I have one other partition table 'weird behavior' that is now explained by your first comment, my third partition starts at 1023,0,3 instead of 1023,0,1. Always wondered about that entry before, now its explained, although I'm not happy with the fact that DD has these little quirks.

 

Doug:

Could you please post a screenshot of your partition table. It is very difficult to do this by guessing. I need specifics.

 

I don't know how to post a screenshot. I don't know how to convert the DD window into something that could be attached. I think I know how to attach to a post, but tell me how to do that as well because I haven't done it for several months.

But as I said, the only things weird about mine are the 1,0,7 and 1023,0,3 begin entries. The other two partitions (all primary) are the typical 1023,0,1 begin entries. All 4 partitions have 1023,254,63 end entries.

 

Sorry, Doug - I didn't realize that. If you have Vista then you can use the Snipping Tool (type snip in the search box to find it) for an easy way to grab a section of the screen and save it to a file.

Make sure that the desired image is completely visible on-screen and then open the Snipping Tool. Choose "New" and then "Rectangular Snip". Drag a selection rectangle around the portion of the screen image that you want to capture. Save it to a file (png format images will preserve transparency effects and are one of the forum's allowable file formats).

Follow the steps in post #2 of Grover Hatcher's Attachment modification & enhancement article to attach the image to your post.

 

Yes I have booted Vista from a partition that started at sector 63. Before I moved Vista's boot files to a separate partition they were in the the first primary partition on my disk which started at sector 63. This does indeed work.

I think what you may have read is that if a Vista partition's starting sector is moved then it won't boot until it is repaired. The reason for this is that the Vista bootloader uses a different mechanism to locate the boot loader and the Vista system files. XP used a text file (boot.ini) but Vista uses a binary database (BCD). The BCD refers to partitions by a hex partition ID that is generated from a combination of a) The disk ID and b) the starting sector of the partition. So if you move the starting sector of the partition that Vista is located in then the partition ID changes and Vista will not boot until the entry in the database is changed. A Vista DVD contains an automatic repair program that will fix the BCD, or you can fix it manually using the command-line tool bcdedit.exe.

Better yet, have a look at this post by MudCrab. You can fix the BCD in advance so that Vista will be location-independent. Then you can relocate the Vista partition to wherever you want.

 

Wow, there's a lot more to this than I first expected, but I'm interested in learning. I'm gonna have to re-read that link you provided a few times to digest all of it. Is the hazard described in that thread unique to TI 10, or would it apply to TI 11 as well? I'm new to TI in general (11 is the first version I've owned) but I think 11 might have been the first version to support Vista, am I right?

That might have been why my first resizing of the Vista partition crashed and burned and wouldn't boot at all after I did it. But doing an image restore with TI 11 seemed to make everything OK again and it kept the new partition size intact, so I somehow made it through that maze without even knowing what was happening.

Here's the screenshot of my partition table, with the little graphic from DD beneath the table.

 

Doug:

TI 10 was the first version to support Vista, but it did not contain any code to repair the BCD after a restore to a partition having a different partition ID. That issue was fixed in TI 11, but the details of how this is accomplished are unknown (at least to me), so I can't speculate on whether or when a repair will be needed when restoring with version 11. I do know from reading forum posts that a plain-vanilla Vista system that was set up by an OEM or by installing from the Vista DVD will boot correctly after a TI 11 restore, even if the original partition offset was 2048 sectors. After restoring, TI always changes the offset to 63 sectors thus changing the partition ID, but somehow TI 11 fixes the BCD entry so that the OS will boot correctly.

What I don't know is whether you can restore to a completely different partition in a different area of the disk and automatically end up with the correct entries in the BCD. But that's easy enough to do manually by "Generalizing" the BCD per MudCrab's post. If you generalize your BCD (by changing the BCD to refer to partition entries as "boot" instead of by their partition IDs) then you can move the Vista partition anywhere and it will boot correctly. In this context an entry of "boot" in the BCD means the Active partition, or the one that the PC boots from. In a single-boot system (like yours) this will always work.

Thanks for posting your disk layout. I see that only the second and fourth partitions have starting sectors and sizes that are a multiple of 63. The first and third do not. I've seen Disk Director do things like this when you resize a partition. I think it's a bug in the code but it doesn't really cause any harm. As you know your system is working just fine as-is. Most of the Linux partitioning tools will accept this layout without complaint. The older DOS tools like Partition Magic will not, however. Vista and XP Disk Management should be OK with it. But I can tell that you are like me and probably want to have a standard layout with all of your I's dotted and T's crossed. Having a standard layout will allow you to use any partitioning tool and expect to have it work without complaint.

The easiest way to realign things is to use TI. When TI restores the first thing it does is to delete the partition. Then it makes a new entry in the partition table, following the older partitioning rules (starting offset = 63 sectors). If you simply restore either of your misaligned partitions then they will magically realign.

If you want to realign then my suggestion is to put the Vista partition in the first slot followed by your data partitions in whichever order makes the most sense to you. I would proceed as follows:

1. Generalize the BCD by following this procedure.
2. Make a full-disk image using TI
3. Boot to DD and delete all partitions leaving only uncommitted free space
4. Boot to TI and restore only the Vista partition as an Active primary partition, resizing to suit
5. Boot into Vista to check
6. Boot to TI and restore the other partitions, one at a time in whichever order makes sense
7. Boot to Vista and reassign drive letters of the three data partitions per your personal preference

If happy with the result, make an image of the new layout for safekeeping. If not, restore the first full-disk image and you should be back to where you started.

 

Mark,

Thanks again for all the information, its been a big help in understanding all the underlying hazards. Jeez, on my XP machine I just resized partitions and never gave it a second thought, Vista sure has changed the playing field.

I've downloaded the Microsoft BCD documentation, so I'm going to read that to get a better understanding of what you guys are talking about.

BTW, I seem to recall reading something a while back that suggested the Vista booting sequence just looked at all the partitions in the table and checked to see which one was the boot partition. If it found bootmgr code at the first sector of the boot partition then it could proceed with the boot. Does that make any sense, or did I not interpret it correctly? Is the BCD in that bootmgr code?

thanks,

doug

 

Doug:

Here is Microsoft's explanation for the reasons that they changed the Vista boot process, and here is a Wikipedia article that summarizes it.

You can view yours by starting an elevated command prompt (START > type cmd then right-click on Command Prompt and choose "Run as Administrator"). Enter the following command:

Code:

bcdedit

and you will see the entries in your BCD. They probably reference by explicitly pointing to the Vista partition (Partition=C.

Sort of. When the PC boots the BIOS loads the first sector of the disk and begins execution of the Master Boot Code. This code searches the partition table in the first sector to find the partition marked as Active. Then it jumps to the beginning sector of the active partition and loads the Partition Boot Record code located there and begins execution of this code. The Vista Partition Boot Loader code then searches for the file BOOTMGR at C:\ and the BCD file at C:\Boot\BCD and, if found, will begin execution. BOOTMGR is the Vista Boot Manager that displays a menu to allow you to select operating systems, but if you only have one OS installed then you won't see the menu. If Vista is selected from the menu or if it is the default selection, BOOTMGR then locates and starts executing the file Winload.exe, which loads and starts Vista.

 

The BCD FAQ document cleared up some of my questions, and its starting to make more sense to me now, but I have a few basic questions remaining.

1. In the mudcrab bcdedit procedure, what is the significance of replacing the 'partition=C:' string with 'boot'? What exactly is the difference, and what meaning does 'boot' carry in this environment? If you're only running Vista, and its always located in C:, what is the significance of this change?

2. When the original partition is moved/resized and Vista won't boot until the BCD is repaired, what aspect of the boot process breaks? If I understand it, Vista would still know which partition to look in, so it just has to find the \boot\bcd directory and the BCD should still be there. The GUID for Vista wouldn't have changed, only the starting sector number for the partition, which was changed in the partition table. So I assume whatever mechanism is used to re-adjust the file table (assuming these entries are all relative address offsets to begin with, so a new partition just needs to account for the new starting point and everything else doesn't need to change) would also allow Vista to locate the BCD as well. So what breaks, does the new starting sector value need to be written somewhere in the actual BCD database?

BTW, I resized/restored and now all my partitions are back to where they should be. Like you said TI put everything back at the cylinder boundary like it should have been in the first place.

 

The tag boot references the Active partition, or the one Vista booted from. When you fix the BCD to reference the Vista partition by this tag then you are eliminating the reference by GUID. As long as Vista is installed to the active primary partition on your disk then the boot manager will always find it this way.

The default BCD is referring to the Vista partition by GUID. When you view the BCD using bcdedit, the program translates the binary database entry (GUID) and displays it to you as a drive letter like C:. The stored GUID will only translate correctly to C: if the referenced partition still has the same GUID. The problem is that the partition's actual GUID will change if the starting sector is moved or if the disk ID changes. Once that happens the original GUID no longer points to the correct partition. If you then examine the BCD file using bcdedit you will see unknown displayed for the partition entry. This is what breaks the boot process.

What breaks is the part of the boot process where the file winload.exe must be located. If the BCD doesn't have the correct GUID for the main Vista partition then the process fails here. The first two parts of the boot process work (the MBR finds the active partition and the PBR loads and executes bootmgr) but the next step, executing winload.exe, fails.

(emphasis added in your quote above) - but that's the issue. The GUID does change when the starting sector changes and bootmgr doesn't know where to find winload.exe.

Excellent! Like magic, isn't it?

 

OK, thanks once again for taking the time to explain these things in such detail, I really appreciate it. The more I learn about the Vista boot sequence, the more questions I have, and its not the kind of topic you can just learn part of and be confident you're not breaking something. So now just one last set of questions about the GUID, and I think I'll be done.

When the partition starting sector changes, why does that change the GUID? Is the GUID like some sort of crypto sequence that gets generated and if you mess with anything it changes the bit sequence and Vista refuses to load? If so, then it seems odd that Vista would allow you to circumvent the process entirely with a simple action like using the 'boot' tag. (Actually it seems even more odd that Vista would take such measures like GUID to prevent you from moving the boot partition, but that's another story).

I also saw a reference in this forum to the HD serial number getting in the mix somehow as well, so if you try to restore the active partition to a new HD you'll also run into problems and have to re-install Vista onto the new HD to get it to load properly. Is that also related to the GUID changing because a new drive serial number is used? If so, I assume the 'boot' tag technique applies as a fix to that issue as well.

I knew I should have bought an XP laptop instead of Vista, what a pain!! Seems like they put up roadblocks everywhere for doing things that were common and routine in the pre-Vista days.

thanks again!

doug

 

I don't know the details of how the GUIDs are generated but they do depend on the Disk ID and the partition's starting sector. They are longer (16 32 hex digits or 64 128 bits) than the partition IDs in the registry at HKEY_Local_Machine\System\MountedDevices (12 24 hex digits or 48 96bits). The latter are used by Windows to keep track of drive letters and are simple in concept, consisting of a concatenation of the Disk ID from the first sector of the hard disk and the offset in bytes from the start of the disk to the partition of interest. I haven't been able to find any information that describes how the GUIDs in the BCD are calculated, but they depend on the same two pieces of information and thus will change if the partition's starting sector is moved.

Once you have understood how to use the Vista DVD and the command-line tool bcdedit.exe to fix a "broken" BCD entry then it's quite simple and quick to repair Vista. Most of the time you can just let the DVD do an automatic repair and it will figure it all out for you.

Yes, there have been changes but messing around with partitioning and the boot loader aren't the kinds of things that you do very often. And yes, XP's boot process is easier to understand. But give Vista a fair shot before drawing your conclusions.

With the way you are currently set up you should be able to back up and restore without worrying about these kinds of issues. It should "just work".

 

OK now I know just enough to be dangerous

Here's a screenshot of my bcdedit /eval all showing just the sections relevant to booting.

I have two entries for the bootloader, one with the 'unknown' parameters, one with them mapped to C:.

One more question I have regarding the 'boot' mapping procedure. It appears that the text in curly braces, {default} is what refers to the GUID field, and 'boot' refers to the partition/drive assignment. So is it really the reference to {default} that removes any GUID dependencies, rather than the 'boot' reference? Or am I misinterpreting things?

If I did the 'boot' mapping would all of my existing bootmgr/bootloader entries get replaced by just the two shown in mudcrabs thread? Or is it possible I'd still have the second bootloader entry shown in my screenshot even after doing the boot map commands?

 

Re: OK now I know just enough to be dangerous

The one with the unknown entry looks like the entry for booting into the Dell recovery partition, which you've removed. You can probably delete the first "Windows Boot Loader" section but I'm not sure how you would remove the two entries "recoverysequence" and "recoveryenabled" from the main Vista boot section.

This is a little beyond my understanding but I believe the {default} and {current} entries are textual references to the current Vista System partition GUID. You can see the Vista GUID in the line "identifier" in the "Resume from Hibernate" section. This GUID translates to "partition=c:" on your system. The entry "boot" will point to the partition with the boot flag set, or in Windows terminology the Active partition.

The commands:
bcdedit /set {default} device boot <ENTER>
bcdedit /set {default} osdevice boot <ENTER>
will change the two entries for device and osdevice in your third bootloader entry Windows Boot Loader because it is the default entry in the BCD. The command:
bcdedit /set {bootmgr} device boot <ENTER>
will change the entry for device in your first bootloader entry Windows Boot Manager from partition=c: to boot. Neither will modify the second bootloader entry Windows Boot Loader for the recovery partition.

FYI, here is my BCD. I have only applied the third command to generalize the section Windows Boot Manager so that I can move my boot partition (currently the F: drive) around. The other two entries have to remain pointing to the main Vista partition (currently the C: drive) because it is not the active partition. In your case all three can be generalized since they are all pointing to the Active partition.



P.S. If you modify an entry in the BCD incorrectly and Windows won't boot then you can go to a command prompt on the Vista DVD and use the same bcdedit.exe commands to undo your last change. Or, restore your last image to undo.

 

Re: OK now I know just enough to be dangerous

I agree that {default} and {current} appear to be references to a Vista GUID, but what does that GUID reference? I think {default} and {current} are referencing the GUID associated with the boot loader. And {bootmgr} is referencing the GUID associated with the boot manager. Then both the bootloader and bootmanager GUIDs require a device reference, namely 'boot' or 'partition=C:' to associate it with a partition. So I think what these commands are really doing is associating a Vista GUID for the bootloader/bootmanager with a partition ('boot' or 'partition=X'). I think that's slightly different than your statement that the GUID translates to "partition=c:", but maybe you meant the same thing and used different wording.

The set command appears to associate a GUID {default} with a device 'boot'. So I would word it as the {default} GUID is associated with (or mapped to) the device "partition=C:". I don't get the feeling that the GUID directly translates to "partition=C", I think the GUID translates into either the bootloader/bootmanager, and the "device boot" command associates the bootloader/bootmanager with a particular partition. Am I on the right track, or way off? Are we saying the same thing, but using different wording?

So this implies that your boot partition contains something other than Vista, like XP, Linux, etc. Since none of those OS require a BCD at all, I think all you have to do is use the boot manager to find the boot.ini etc. as required by XP, rather than the files used by Vista. As long as all the required XP files are on the partition referenced by bootmgr, then you're OK, right?

If you boot into a non-Vista OS, does the Vista bootloader do anything at all, I suspect not.

 

Re: OK now I know just enough to be dangerous

Doug:

On re-reading the documentation I believe that {default} refers to the entry in the BCD that is the default entry; the one that will be selected automatically without operator intervention. On a multiboot setup BOOTMGR will display a menu of operating system choices and one of these is the default entry. If no selection is made from the menu the default entry will be automatically booted after a timeout. For single-boot systems like yours and mine then the default entry is Windows Vista.

{current} probably then refers to the menu item that is currently selected. But I could be wrong here.

I still believe that the 64 128-bit hex GUID is identifying a partition location. An example is the GUID 9ba97b5b-251e-11dd-abc2-e9e6d4590921 from my BCD, which is the GUID of the C: partition containing Vista.

I think that in your example {default} is a menu entry and the "set" command associates this menu entry with the GUID of a partition. It either references the partition directly (partition=c or else indirectly references the active partition (boot).

It depends on how you set things up. On multiboot systems there could be other entries in the BCD for booting XP, Linux, etc. The entry for XP would load the file ntldr instead of winload.exe like is done when starting Vista. There are other ways to do a multiboot setup that only use the BCD when booting Vista and use other methods to boot other operating systems. On my laptop, for example, I use GRUB from Linux as the boot loader.

But on my desktop machine (the one that the BCD picture came from) I do not have any other operating systems installed. My boot partition contains only the file BOOTMGR and the folder \boot, which are Vista's boot files.

 

Re: OK now I know just enough to be dangerous

Mark, I think we're saying the same thing regarding the meaning of {default},{current}, etc.

What is the benefit of separating the bootmgr from the rest of the bootloader, and do 1 bcdedit command, rather than keep everything together and do all 3 bcdedit commands?

Also, tell me if I understand this part correctly. Instead of doing mudcrabs bcdedit commands is this how you would manually fix the BCD when the GUID changed:

1. do a bcdedit /eval all and find the new GUID value (BTW its 128 bits, not 64)
2. bcdedit /set {128 bit GUID} device "partition=X:"
3. (the 2 other similar commands)

The basic underlying command structure is simply associating the 128-bit GUID with a partition, as we have said before. The problem arises because a new GUID was created, so the old association no longer works.

By using {default} and 'boot' you get the advantage of indirectly specifying those values, so you don't have to take the time to figure out the new GUID every time it changes, and can change your boot partition without having to go in and manually change that entry as well.

I think I understand it all now, am I right?

 

Re: OK now I know just enough to be dangerous

Mark,

As far as I know, the layout of the BCD file and the bcdedit program do not show any GUID values for partitions. The program always substitutes the partition or "boot" value.

{default} is the BCD entry that will automatically boot.

{current} is the BCD entry that is currently booted. If you look at a BCD file from a non-booted system, you won't see the {current} entry.

bcdedit assigns default "tags" to known objects (entries) to make working with the file easier. These include {default}, {current}, {ntldr}, etc. All other objects have to use their own "long" identifier value. This value is not a partition GUID. This value is what you would type in to change any of the settings for that entry. For example:

Code:

bcdedit /set {8419151d-d54a-11dc-9519-0019dbda2159} device partition=C: <ENTER>

Also, you can create a new BCD entry that isn't currently assigned and the identifier will be created for you. As it contains a value before the entry is even connected to a partition, it can't be a partition GUID value. In addition, multiple entries can be pointed to the same partition, yet have different values. These values are also used for the displayorder value of the {bootmgr} entry.

So, your 9ba97b5b-251e-11dd-abc2-e9e6d4590921 value is just the indentifier for your Resume Object. That entry's device value has it's own assigned partition GUID which you can't see.