This section looks at the syntax used for devices and file paths. The following information has been copied from the (Windows 8.1) bcdedit.exe help topic for FORMATS (run command bcdedit.exe /? FORMATS [enter]). Please note that these device types may not be supported in other versions of bcdedit.

The following sections expand on the Device types used in BCD Stores -


Using the BOOT device type will specify the boot drive is used as a relative path for corresponding elements in the object - this will be the drive from which the Windows Boot Manager (BOOTMGR on BIOS systems or bootmgfw.efi on UEFI systems) is loaded.

On partitioned storage devices (e.g. a hard disk drive) using BOOT as the device type for the element will specify the use of the partition from which the Windows Boot Manager is loaded. Assuming a default Windows setup is used this will be the active primary partition on the first hard disk (BIOS systems) or the EFI System Partition (UEFI systems).

Unlike some of the other device types (e.g. partition=) setting the device as boot will not lock the entry to a particular device or system as unique drive and partition information is not used - paths are relative to the Windows Boot Manager. This potentially allows for the use of a generic BCD store providing that certain restrictions are met - the operating system being loaded must be on the same partition as the Windows Boot Manager and BCD Store. This has very limited application and will be of little use on multiboot systems. The use of a generic BCD Store is discussed in the Create a Windows System From Scratch Using Linux topic on the forum.

Setting the device as boot is particularly useful when cloning a system - using the Sysprep tool in Windows Vista will change device paths as boot for example.


Using a drive letter (e.g. Partition=C:) will create an entry in the BCD store containing information unique to the disk and partition specified.

This information effectively locks the Object to a drive. This has the added advantage of making the system less susceptible to boot problems arising from device changes. As an example, Windows NT 5.* versions use arcpaths to identify the location of the operating system (see here). For a typical Windows XP install the boot entry will be multi(0)disk(0)rdisk(0)partition(1)\WINDOWS. This tells Windows to boot the first partition (partition one) on the first hard disk (disk zero). The disk number is however allocated by the BIOS and can change in some situations - such as changing the boot device. If the disk number for the Windows installation changes then the multi(0)disk(0)rdisk(0)partition(1)\WINDOWS entry will now be pointing to the wrong device. This is no longer an issue due to the use of unique data (disk signature and partition offset values (BIOS) or disk and partition GUID (UEFI)) in the BCD store. Consequently it is possible to backup the BCD store to another bootable device - it will still load the existing operating system entries. The partition number is no longer an issue either, as once the correct disk has been identified by its signature (or GUID) the partition offset (or GUID) is automatically used. Unfortunately any legacy operating system entries (e.g. {ntldr}) could still be affected by device/partition changes.

Note - the appendices includes a more detailed look at the element data in Partition type Devices (see here).


In my brief tests there does not appear to be any difference between using HD_PARTITION or PARTITION device types. Specifying HD_PARTITION on the bcdedit.exe command line (e.g. bcdedit.exe /set {bootmgr} device HD_PARTITION=C: [Enter]) returned the following output when the bcdedit.exe /enum [Enter] command was used to check the entry -


The VHD device can be used to boot a VHD type image file containing a Windows Operating System - this is referred to by Microsoft as Native Boot VHD.

VHD device types must specify a parent device type (either Partition, Boot or Locate) followed by the path to the .vhd file - path is relative to the device root. E.g. -


Windows 7 introduced a new device type - locate. This can be used to scan drives for a path that has been set in another element within the same Object. Using locate is covered elsewhere in these notes (see here).

Unmounted Partitions

A drive letter can be substituted with a \Device\HarddiskVolume# entry if the drive has not been mounted - where # is a numeric value starting from 1. This is not recommended if multiple devices are attached to the system as it can be complicated to predict the volume number.


Assuming we wanted to add a menu entry to boot WinPE from the first partition on hard disk zero (partition is mounted as C: drive and is the boot partition containing BOOTMGR and the BCD store) we could use any of the following commands -