Bienvenido! - Willkommen! - Welcome!

Bitácora Técnica de Tux&Cía., Santa Cruz de la Sierra, BO
Bitácora Central: Tux&Cía.
Bitácora de Información Avanzada: Tux&Cía.-Información
May the source be with you!

Sunday, July 4, 2010

BCDEdit.exe -specializing a BCD

Source
(Windows of course also keeps partition and disk information of its own, even prior to Vista.  But in my experience this never resulted in a boot issue for the situation described, and Windows automatically updated and corrected if a different partition / disk signature was used.)
The cause of the Vista load failure previously described, to the degree I understand it, is that by default all of the BCD entries use "PARTITION"-type device references where applicable.  In the BCD data stored for these "PARTITION"-type device references (visible in the BCD section of the registry, and in a BCDEDIT /EXPORT), both the drive signature and the partition number appear to be part of the information stored.  And based on the results, both must match the current environment else the boot manager will declare the OS loading application cannot be found.
(Even if I force the drive signature to be the correct signature, if I'm restoring to a different partition than the image was previously using, the restored partition will still fail to boot because the partition number stored in the BCD still doesn't match the current environment.)
The solution that appears to be most suitable (at least for the situation I previously described and was intending to solve) is to change the BCD entries to use "BOOT" device references rather than explicit "PARTITION"-based references.  Presumably thereby implying "whatever device/partition I booted from, that is the device/partition I want to use".
Preparing a Vista installation prior to creating the Ghost image then becomes a task of setting the DEVICE and OSDEVICE entries of the BCD entries you intend to use:
To run BCDEDIT.EXE, indeed you need to have your full Administrators rights in effect.  You can do this with any Administrators-member account (not specifically "Administrator"), but you will need to right-click the Command Prompt shorcut and select "Run as Administrator" in order to subsequently run BCDEDIT.EXE successfully within that Command Prompt session.
(Or, as alluded to, if UAC is simply disabled altogether that would give you full Administrators right in any Command Prompt session too.  But simply right-clicking the Command Prompt and selecting "Run as Administrator" will suffice for the default UAC-enabled mode of Vista.)
Logon as Administrator and from a command prompt invoke the following changes:
BCDEDIT /set {bootmgr} device boot
BCDEDIT /set {default} device boot
BCDEDIT /set {default} osdevice boot
Note you can "fix" a previously restored (and currently failing to boot) installation using a PE boot disc and executing these same actions against the restored partition's BCD entries.
There may be more entires that you need to fix if you intend to use them ({memtest}, {legacy}, etc.).  The above is just the minimum for my own scenario where there is just a clean Vista-only OS installation on the partition.
Once the BCD entries are no longer referring to specific disk signatures and partition numbers, there is no need to use -FDSP with Ghost anymore, either.  The disk signature can be reset as it is by default with a Ghost disk restore, and "nothing special" is required during image creation or restore (from a Ghost perspective).
Presumably this could have also been corrected by resetting/updating the "PARTITION"-type device entries with current information (current partition number and disk signature) post-Ghost restore, if for any reason the use of "PARTITION"-type references is needed.  For the purposes of making an image that can be restored via Ghost to any partition on my test box, the "BOOT" device reference appears most desirable by not being fixed to any one partition or disk signature.
------------------------------------
I found even ghost 7.5 to work.
just run the following commands from a cmd box in vista under an admin account :
BCDEDIT /set {bootmgr} device boot
BCDEDIT /set {default} device boot
BCDEDIT /set {default} osdevice boot
then make a ghost image as you normally would. (ghost 7.5 doesnt even understand the -fdps switch)
also i got ghostwalker to work (we only use it to change the computer name). ghostwalker looks for msdos.sys & boot.ini, it uses the content of boot.ini to locate windows. tho vista uses bcd instead of those files you can just copy them from windows xp. (havent tried changing the sid tho)
------------------------------------
Vista with ghost 11 works a treat, still havent tried any earlier versions with it though..
Allthough, i get that error "unable to access \windows\winload.exe", so I ran the repair from and vista cd, and it fixed it in almost 5 seconds, re-booted, and problem solved..
-------------------------------------
Follow up - Using the Vista install disk, it has a 'Repair' option that you can access a command promopt with. To get there, do this:
- On the system that won't boot due to the error, put your install disk in, and boot off of it.
- When it asks you for your language, select the language options you want, and then click "Next".
- On the following dialog, there should be an link at the bottom that says "Repair...". Click that.
- A dialog will come up where it will say "Scanning for Windows Installations..", let it finish.
- It *MAY* tell you that it found an installation that is corrupt, and offer to fix and reboot. Select "No", do not fix.
- That dialog will go away and you'll have another with a list of things you can do. Near the bottom will be "Command Prompt". Select that.
- In the command prompt that pops up, type 'bcdedit' and hit enter. It will give you a list of items.
- Note the "designation" part of each section. For each section, set the 'device' and 'osdevice' (if it is listed) to 'boot' for each section you see. For example, on all of my systems, I have two items - a designation of 'bootmgr' with "device" in it, and a section of 'default' with "device" and "osdevice" on it. So, I run the three commands:
bcdedit /set {bootmgr} device boot
bcdedit /set {default} device boot
bcdedit /set {default} osdevice boot
And yes, type the lines exactly like that - unlee you have something else in the "designator" section on output of bcdedit.
- After finished, type 'bcdedit' again, and it'll show your changes.

That's it - if you need to make a ghost image, then reboot and make it there.
------------------------------------------
There is a tool available that will prepare your Vista installation for cloning. 
It can be found at:
http://www.net-runna.com/Agreement/tabid/243/Default.aspx


============================
Source
Possible partition issues - Preparing the BCD.
Fix the BCD while working from another OS or the Vista DVD.
Hibernation issues - Backup the BCD - Whole drive cloning.

logo-7The information on this page also applies to Windows 7 - except where indicated.
Cloning
Vista is similar enough to previous versions of the NT operating system that many current cloning tools can still be used for Vista. The problems arise mostly from the new Vista boot files bootmgr and BCD, the way they use the Disk Signature, and the new Vista partitioning rules. If these factors are taken into account and adjusted for then the majority of pre-Vista tools are perfectly capable of doing the job. Of course many cannot be installed inside Vista, but they can be run from another OS or boot disk. Third party vendors of such tools are releasing Vista compatible versions, but some still have issues that have not been fully addressed.
Cloning any WinNT OS requires adherence to certain rules to get a clean booting and independent clone that is not in some way cross-linked with the parent install. When using the Microsoft bootmanager with its reliance on separate system and boot partitions and non-default drive letters there are extra variables that can make successful cloning more tricky. I have tried to provide some information relevant to the MS bootmanager, but please be aware that the information here is mainly aimed at systems where the Windows installs are independent with all their boot files on their own partition and see themselves as the C: drive and their partition as both system and boot. If you don't know what I mean by 'independent', or you are using the MS bootmanager and don't understand how it operates, then you should read this guide before attempting to multiboot clones.

Off Boundary Partitions
.
The first and most potentially troublesome issue to be aware of is that Vista created partitions are different, so many pre-Vista cloning tools will either just not recognise them as valid partitions, or worse still try and correct what they see as errors. If you have allowed Vista to create its own partition during install, or used any Vista tools such as Disk Management or Diskpart to create or resize any of the partitions on the computer, then you would be advised to be extremely cautious in using a pre-Vista cloning, imaging or partitioning tool. Not all tools will baulk at the Vista partitions and some will clone and image them, but none will keep the structure of the Vista partition for the newly created clone or restored image, (unless you are doing a whole drive sector-by-sector clone, see section below). Powerquest's Drive Image and Partition Magic will not work with Vista partitions and their attempts to 'repair' things will damage Vista. As long as all partitions on the computer are old style then you have at least a fair chance of success, but more importantly you have much less of a chance that you will do any damage. If your cloning tool seems happy working with a Vista OS and goes to work without reporting any errors, then you should be okay.

Winload.exe........Is Missing
.
After successful cloning you will still be unable to boot the clone unless the Vista BCD file is pointing to the correct new location of the Vista bootloader. It's very similar to how the boot.ini file has to be edited to point to the new partition or drive, but unlike the boot.ini you can't just edit the BCD in Notepad. Correcting the BCD in clones is possible and not particularly difficult, but it is more of a hassle than opening Notepad and changing a digit or two. What would be ideal is if the BCD could be made to just point to the winload.exe that was on the same partition as itself. This would allow a new clone to boot without having to make any corrections to the BCD.
Fortunately there is a way to do this and it makes cloning Vista almost easier than any previous NT operating system. Thanks for this edit to the BCD goes to the man who first reported it. It's still not exactly clear what happens in the Vista bootmgr when this edit has been applied, but it has been used by a lot of people since 2006 with no reports of any problems or issues. It is not a published Microsoft fix, but it appears to be exactly the same edit as applied by Microsoft's own sysprep utility. The sysprep tool is designed to allow computer suppliers and IT pros to easily deploy Vista to numerous computers, by letting them install Vista once and then copy it to the other machines. That single install has to be 'generalized' so that when it is rebooted for the first time on another machine it is able to adapt to its new surroundings. My examinations of the 'generalized' BCD of a syspreped Vista install has shown that it employs the same edit as described here. If it's how Microsoft do it, then I think we can be fairly confident that it is a valid approach. If you don't want to generalize a BCD but just reset one to its new surroundings, then see the section below, Re-Specialize a BCD.
...
...
Re-Specialize a BCD
If you want to change a generalized BCD back to a specialized one, or just repair one so that it is specialized for its new surroundings, then it only takes replacing the 'boot' component in the BCDEdit.exe commands with specific partition drive letters. To fully un-generalize a BCD of an independent Vista that you are booted into then you need these five commands, where X is the drive letter that the OS sees itself as. An error from the first two commands here will tell you that there is something wrong with your set-up and you are not working on the BCD or the Object you think you are. But remember that the absence of an error message is not a guarantee that you have got things correct. If you have not yet read the beginning of this page you should do so before proceeding. (The {memdiag} command is only required if you ever want to use the MS boot-time memory tester. The {ntldr} command is optional for Vista and won't apply to Windows 7 unless you actually have a legacy OS installed and you are using the MS bootmanager).
bcdedit /set {current} osdevice partition=X:
bcdedit /set {current} device partition=X:
bcdedit /set {bootmgr} device partition=X

bcdedit /set {memdiag} device partition=X:
bcdedit /set {ntldr} device partition=X:
To specialize a BCD while working from another OS or the DVD your commands will be as follows, where the drive letter of the partition is the same as the drive letter in the path to the BCD. That is both Xs have the same value. (These are also the commands you would use from inside an OS if you were having trouble getting BCDEdit.exe to target the OS's own BCD).
bcdedit /store X:\boot\bcd /set {default} osdevice partition=X:
bcdedit /store X:\boot\bcd /set {default} device partition=X:
bcdedit /store X:\boot\bcd /set {bootmgr} device partition=X:
bcdedit /store X:\boot\bcd /set {memdiag} device partition=X:
bcdedit /store X:\boot\bcd /set {ntldr} device partition=X:
Remember, you are not setting drive letters in the BCD, you are simply telling BCDEdit.exe which partition you mean, in this case you mean the partition the Vista install is on.
(Note - If you have the MS bootmanager configured and operational in the BCD that you are targeting and your Vista install is on a different partition to that BCD then the first two commands above will require the specific GUID for your Vista and not the {default} identifier. The value of the Xs in those two commands will also be different, the store X: being the BCD's partition drive letter and the partition=X: being Vista's partition drive letter).

Manually Set Hibernation Object
If you do have trouble with the resume object correctly resetting or just want to do it yourself then here is the command. First make sure that hibernation is indeed turned on as described at the bottom of this section. There is no shorthand identifier for this one so you have to use the full 32 digit GUID number. Run bcdedit /enum all and the GUID you want is the 'Identifier' for the Resume from Hibernation object. You will almost certainly be doing this from inside the OS you are having trouble with so it will be possible to copy and paste the GUID instead of having to type it out. To copy from the command prompt window right click anywhere and from the popup menu click ‘Mark’ then highlight your text and either right click or press Enter to copy. Or you can click ‘Select All’ and paste everything into Notepad or whatever.
If your BCD is generalized then the command will be:
bcdedit /set {xxxxxxxx-your-guid-here-xxxx-xxxxxxxx} device boot
If the BCD is Specialized then it is this, where X is Vista's own drive letter.
bcdedit /set {xxxxxxxx-your-guid-here-xxxx-xxxxxxxx} device partition=X:
(If you are working from another OS or the DVD then X will be the letter that is currently assigned to the Vista partition).
Once hibernation has been used for the first time a new line (Element) called 'resumeobject' will appear in the bootmgr Object, and also a new one called 'filedevice' in the resume Object. The filedevice Element in the resume Object uses the signature and offset information and so has to be set correctly, but we never have to do this one ourselves because it is reset every time hibernation is used. It is always specialized, so there would be no point in generalizing it.
It is this auto specializing of the filedevice Element just before hibernation shuts the system down that is part of the cause of hibernation or hybrid sleep problems in independent Vistas on second or higher hard drives or logical partitions. If your bootmanager is not fully Vista compatible then the wrong BCD store can be set for resume, see BCD is Always Open. If you do want hibernation to function in independent Vista installs on anything other than boot drive primary partitions, then I have found no solution other than making sure your bootmanager is fully Vista compatible. The new Hybrid Sleep in Vista also uses the hibernation function and so partly suffers from the same problem. Hybrid sleep is hardware dependent so it may not be available as an option on slightly older machines. If you do have it turned on then you will not have hibernation as an option on your shutdown menu. You have to set hybrid sleep to Off before hibernate will be available.

Hibernation and Third-Party Bootmanagers.
Most bootmanagers will happily let you boot to another OS while you still have one in a state of hibernation. This is something the MS bootmanager won’t allow because it can lead to data corruption. If you have a common data partition that is visible to more than one OS, or you just allow OSes to see each other, a hibernated OS may have left open file handles to shared files, which will cause problems for another OS wanting to access those files. It works the other way as well because a newly resumed OS will not be aware of any changes made to shared files since it went into hibernation, the cached file table index resumed to memory will not match the actual file table on disk. Running chkdsk will refresh the index or delete orphaned files. Perhaps this solution for Windows XP Embedded can be adapted for any WinNT operating system. If anyone has explored this then please share - feedback.

Turning Hibernation On and Off
.
By default the hibernation feature should be on and you can check if it is by looking to see if you have the hibernation file hiberfil.sys in the root of your install (it is hidden by default remember). If it's not there then hibernation is off and so the resume object device element will not auto reset itself on bootup. To turn it on at the command line enter powercfg /h on to turn it off powercfg /h off The hiberfil.sys file can show as a couple of gigs in size even when it's not being used, so if you don't use hibernation or hybrid sleep then you can get rid of this file by turning hibernation off.

Backup and Restore a BCD with BCDEdit.exe
If you want to create a backup of a BCD from inside the Vista OS that is holding it open, then the command will be as follows – where X:\folder\ is the target drive and folder where the back-up will be saved to.
bcdedit /export X:\folder\bcd
To restore the BCD from your back-up
bcdedit /import X:\folder\bcd
If for example you create a new folder in the root of the C: partition and call it boot2, then the path would be C:\boot2\. If you want to send the BCD backup to your documents folder on the C: drive then the whole command would be bcdedit /export C:\users\yourname\documents\bcd. If you include any spaces in the folder name or the name you give to the BCD back-up file you have to enclose the path and file name in quotation marks: e.g. bcdedit /export “C:\boot2\bcd bkup”

Whole drive sector-by-sector cloning
If you make a complete sector-by-sector clone of a drive containing Vista then you will duplicate the disk signature and the partition offset and so you will not have to modify the BCD to get Vista booting, because it will already contain the correct information. Be aware however that you cannot have two hard drives on the same computer with identical disk signatures. If you boot any WinNT operating system when there are two drives with the same signature then one of the signatures will be automatically changed. If you do clone a Vista drive in this way and need both drives connected at the same time then generalizing the BCD before cloning, or re-specializing or generalizing the BCD on the affected drive, will fix the problem. This has always been an issue when cloning entire hard drives containing WinNT, but before Vista a signature change could in many cases not cause an issue and so may have went unnoticed.

Cloning Vista for anything other than backup or recovery may violate your EULA

No comments: