Drive letters and repetitive cloning for multi-booting Windows (Vista)

Discussion in 'Acronis True Image Product Line' started by JustAnotherNoob, Mar 30, 2008.

Thread Status:
Not open for further replies.
  1. JustAnotherNoob

    JustAnotherNoob Registered Member

    Mar 9, 2008
    As I have recently experienced, getting a multi-boot system to fully function isn't a very simple operation - there are so many things that can go wrong. Although there is a lot of information on the internet, it often does not apply to your particular situation, because there are an almost unlimited number of scenario's, depending on your exact configuration, needs and wants. In this thread I will document one particular scenario, by describing the method I use(d) to setup a multi-boot based on cloning an existing Windows installation to other partitions on the same disk.

    What you will find in my post:
    - a general recap of some of the goals for multi-booting, and the methods used to achieve it
    - a general outline on how to (repetitively) clone a Windows installation to obtain a multi-booting system,
    with specific emphasis on the problem of the assignment of drive letters in the cloned installations
    - some tips on how to make the whole process more user-friendly, such that repetitive cloning becomes a realistic option

    What you will NOT find in my post:

    - details on how to multi-boot with different operating systems (e.g. Win2000 / XP / Vista / Linux / etc.). If you are interested in this, you may want to read Daladim's post "An easy way to multiboot for newbies", which uses Acronis OSS as a boot manager.
    - details on how to use or configure any particular boot manager: everything I describe should be applicable to any third party boot manager (e.g. OSS, GAG, XOSL, etc.) ; it does NOT apply to the Windows-style multi-boot setup !!

    To keep some clarity in this thread, I will outline a step-by-step procedure in the following post. Before moving on to that, it may be useful if I start by explaining what my goals are (i.e. how I want to set up and maintain a multi-boot) and what exactly constitutes the drive letter issue mentioned in the title.

    Setting up a multi-boot: different goals, different techniques
    "Multi-booting" can mean different things to different people. One reason to multi-boot is so you can use different operating systems (e.g. Win2000 / XP / Vista / Linux / etc.) on the same computer. Setting up the multi-boot then means finding a way to install all these systems consecutively on the same computer. A second approach is to use only one type of Windows, but have separate installations, for different users (e.g. Dad, Mum, children) or for different purposes (e.g. office, gaming, video editing). Setting up this type of multi-boot can be achieved by installing from the same installation disc to different partitions, or you can do it by cloning an existing installation to other partitions on the same computer (e.g. using Acronis Disk Director), or similarly, by making a disk image from the existing installation and "restoring" this image to the other partitions (e.g. using Acronis True Image). The cloning/imaging approach has the advantage that Windows configuration / software installation / etc. you want applied in all installations, need to be done only once (before the cloning), which may save you a considerable amount of time. A third approach to set up a multi-boot is to have separate instances of the same version of Windows that are kept almost identical. While at first sight this may seem to contradict with the very idea of multi-booting, the purpose of such a setup is to have one general-purpose main Windows system, and one or more for testing purposes only. E.g. this allows you to work during the week on your main Windows, while evaluating new software on a test Windows over the course of several weekends. Since the test Windows is used only as a temporary "sandbox to play in", rather than as an end in itself (as it is in the "office, gaming, video editing" setup), you may want to regularly repeat the cloning process from the main to the test partitions. Keeping the partitions very similar to each other has the advantage that all changes to Windows configuration, Windows updates, software installations (except for the software you are explicitly testing), etc. have to be applied only once, i.e. in the main Windows. Also, keeping the test system very similar to the main system ensures the relevance of your test "results" for the main system.

    In this thread, I will discuss some of the practical aspects encountered when cloning an existing Windows installation to other partitions in the same computer. These are relevant both to one-time-only cloning (the "second approach") as to repetitive cloning (the "third approach"), but the latter requires some additional work to make things user-friendly enough in the long run.

    The drive letter issue: the problem and the solution
    When I first tried to setup my multi-boot system, I got confronted with the infamous 'empty light blue screen'. As k0lo pointed out to me in this thread, the problem originates from Windows wanting to use C: as its system drive letter, while the registry links C: to a different partition on the same computer (i.e. the source partition of the Windows clone). Even if you have a third-party boot manager that hides the other Windows partitions on boot-up, Windows' disk management knows they're still around and refuses to free the letter C: required by the rest of Windows. As a consequence Windows locks up on the light blue screen, and you even don't get to logon (although you may have some basic functionality nonetheless). You can read more about it on the webpages by Dan Goodell and McTavish. As you can read there (and in my procedure in the next post), the solution is actually pretty simple: you have to delete certain entries from the "MountedDevices" registry key just before cloning or imaging Vista. Once you know this particular trick, you can use ADD and/or ATI to clone an existing Vista and end up with a functioning multi-boot system.

    Cloning the partition directly VS. making an image, then "restoring" it

    To copy your main Windows, you can either clone the partition directly to the other partitions (using Disk Director) or you can make an image from the main Windows and "restore" it to the other partitions (using True Image). When all is OK, both should yield exactly the same result. In the post below, I only discuss "cloning by restoring images" using True Image. Why? As I mentioned before, multi-booting isn't an end to itself for me, it's just another element in my toolbox for maintaining my computer in good order, just like regular system images and data back-ups. From that perspective, I want the maximum amount of flexibility, i.e. I want to be able to restore any image I make (and keep in my archive) to any partition on the same computer, at any given time (i.e. immediately, or at some point in the future). That faces me with a practical problem: I like to image my main Windows regularly (I make an incremental image at least once a week), but given that I want to keep the option open of cloning that image to a different partition, it isn't very practical to manually delete registry keys every time before making an image. Fortunately, I think I have found a procedure that automates this, so the process involves as little effort as possible (after the initial setup).

    A few caveats
    - As should be clear from my nick, I'm no expert, just someone who likes to determine how his computer should operate (instead of the other way around) and has done some research to get there. For now, the procedure I describe seems to work for me, but I haven't done extensive testing on all possible scenarios - I thought I'd write up everything while it's still fresh. If you want to try it yourself, take the usual precautions.
    - There are no grand technical innovations in this post, just a compilation of a few rather simple steps, some common logic, and some links for further info. A lot of it may be obvious for experienced users, but I still think it might be useful for people who are new to multi-booting from a cloned Windows.
    - It is assumed you know how to use Registry Editor and how you can create and edit .reg files with Notepad. If you have never worked with the registry before, this might not be the best place to start learning it.
    - In the procedure below, it may be possible to cut some corners, and several variations are possible. Please read it carefully, then decide what is best suited for your needs. Always make sure you know what you are doing.
    - I only tested this on a new OEM version of Vista Home Premium, but I think everything I write can be applied to all versions of Vista. Also, I *think* it can be applied to Windows XP as well (this part of the registry does not seem to have changed much); the main difference would be in the Windows boot configuration (changes that have to be made to Vista's BCD file / WinXP's boot.ini file).

    - Everybody interested in multibooting will benefit greatly from reading some of the material on the excellent webpages by Dan Goodell (focus on Win2000 / XP) and McTavish (focus on Vista). My thanks to both of them !
    - My thanks to all the contributors on this board - I have learned a great deal on this forum ...
    - My special thanks to k0lo and MudCrab for their replies in the thread where I posted my original logon problem.

    If you experiment with this procedure, or if you spot a blatant pitfall in it, or if you have any suggestion or comment, please reply - we are all here to learn ...

    Thank you,

    Last edited: Mar 30, 2008
  2. JustAnotherNoob

    JustAnotherNoob Registered Member

    Mar 9, 2008
    Warnings and notes
    1. If you haven't already, read the caveats in the post above
    2. As always with this type of thing: first back-up your data / image your system !! (even better: do it on a fresh system where you have little to lose)
    3. Although the description is rather lenghty, everything can be done in under one hour (except for the time necessary to install/configure your boot manager, and the time to make and restore images).

    A. Install a boot manager (once only)
    If you haven't done so already, you may want to do this first.
    I work with GAG, but any independent boot manager should be OK, provided the boot manager is able to hide partitions selectively.

    B. Edit the boot file (once only)
    If you are working with Vista and you haven't done it already, don't forget to edit the BCD file, as described by MudCrab here.
    If you are working with XP or an older Windows version, you may have to perform similar actions - but I haven't researched that issue.

    C. Clean up the "MountedDevices" registry key (once only)
    (This step is optional in some cases, but it will lead to a better overview, especially on older installations that have accumulated a lot of obsolete entries in this registry key ; also, it's a good way to check that the actions that are performed on the registry key go according to plan, before you move on to making the image)
    1. In regedit, go to "HKEY_LOCAL_MACHINE\System\MountedDevices"
    2. Export this key (for backup / restore purposes only)
    3. Exit regedit, then merge a .reg file containing the following code (this will remove all entries from this key):
    Windows Registry Editor Version 5.00
    4. Reboot
    IMPORTANT: using your boot manager, make sure the partitions to which you are going to clone your system later are hidden at this point
    (if they even already exist on your system).​
    5. Upon boot, Windows recreates the essential parts of the registry key
    6. If necessary, re-assign drive letters as desired. Make sure all devices for which you want Windows to assign a consistent drive letter (local partitions, optical drives, external hard disks, memory sticks, etc.) are made visible to Windows now.

    D. Prepare two .reg files (once only)
    1. In regedit, go to "HKEY_LOCAL_MACHINE\System\MountedDevices"
    2. Export this key - you will need the exported file !
    3. Exit regedit, then create "Run_before_imaging.reg" :
    Windows Registry Editor Version 5.00
    where * * * represent all entries from the exported key, EXCEPT:
    $ : the entry "\DosDevices\C:"
    € (£) : the other entry (maybe entries) with an identical data value as "\DosDevices\C:"
    (in a cleaned registry key, look for the first "\\??\\Volume{...}" and the first "\\DosDevices\\" entry)
    Remark 1: I use * $ € £ just as symbolic placeholders, don't go looking for "*", "$", "€" or "£" literally !!
    Remark 2: Obviously, if your system drive has a drive letter other than "C:", then look for the entry with your letter ...​

    4. Create "Run_post_imaging.reg" :
    Windows Registry Editor Version 5.00
    where $ € (£) represent the entries identified above

    E. Make a disk image
    1. Double-click "Run_before_imaging.reg" and confirm you want to merge it with the registry.
    2. Make an image of the system partition with True Image
    3. Double-click "Run_post_imaging.reg" and confirm you want to merge it with the registry.
    How to make things easier
    If you make images frequently, having to find and run these .reg files every time is a bit annoying. Fortunately, recent versions of Acronis True Image have a very useful feature you can put to good use for this. Go to "Standard Back-up options", where you can define files you want ATI to run before and/or after making an image. Click "Edit" and browse to the .reg file you just made. When making an image, you will still get the confirmation dialogs from Registry Editor (that is good !), but otherwise the process becomes fully automated. What a luxury !!​

    F. Set up the multiboot (once only)
    1. If necessary, create the partition(s) to which you want to clone your original Windows. In most "simple" cases, you probably will want to work with primary partitions only.
    TIP: if you plan to clone repetitively, make the partitions of similar, but not exactly the same, size. E.g. I use three partitions with sizes 35.19 / 35.29 / 35.39 GB, (showing up in Windows Explorer as 35.1 / 35.2 / 35.3 GB) so that I can recognize immediately whether I booted into the correct partition.​
    2. Clone the image you just made to the destination partitions you just made (see next step for details on this).
    3. If necessary, finish the configuration of your boot manager.
    IMPORTANT: when ATI 10 restores a partition, it will almost always place this partition in the first position of the Master Partition Table. In other words, your MPT may look different after conducting a restore operation. This is something to take into account when configuring your boot manager !! Different builds of ATI behave differently with regard to this issue, read more about this issue here and here.​

    G. Cloning by "restoring" an image
    1. Use ATI to clone the source Windows to the destination partitions - choose to "restore" the image you just made. If you want to clone to more than one partition, all restorations can be performed in one operation - choose "Yes, restore other partition" when asked.
    2. Restoring the image to partitions other than the source partitions (as you are doing now) is probably done best from a bootable Acronis CD. If it is done from within the Windows version of ATI, Windows *may* perform some "repairs" that may complicate things for you. As for creating the image, I don't think it matters wether it is done from the CD or from within Windows. (edit: read the reply by k0lo below !!)
    3. On the first boot into a restored partition, you may get a black Windows Error Recovery screen ("Windows did not shut down succesfully" etc.). Don't worry too much about this, just choose "Start Windows Normally" (the default option) - Windows will boot up correctly, without doing any form of repair (as far as I can see). I get this screen on every first boot into a restored partition, both on the original as on cloned partitions - may be this is because Windows detects that drive letter C: has been removed from the registry ?? (edit: read the reply by k0lo below !!)
    4. When booting into a "restored" partition, Windows will automatically create the registry entries for the system partition "C:", while the drive letters for non-bootable volumes (data partitions etc.) are kept unchanged.
    5. The cloned partitions will carry the label the destination partition had when the image was created ; it is a good idea to re-label them, as this may make things easier for you in future disk management (in addition to making your partitions slightly different in size).

    H. You're done !!
    You now should have a fully functioning multi-boot system. It's your choice if, and how regularly, you want to repeat this "cloning by restoring" process. All images made with this system can be restored to any partition at any given time, giving you a maximum degree of flexibility in managing your computer.


    Addendum: When to update the two .reg files
    There are too many possible scenarios to describe them all, so I'll limit myself to few remarks that should cover most situations. If you understand what happens, you should be able to adapt to your particular situation. In contrast to the steps above, I have not tested what follows, I'm simply applying some logic here. I you spot an error, please comment !!

    1. "Run_before_imaging.reg" will remove drive letter associations that are defined after you make this .reg This clean-up may be a good thing if your PC frequently encounters e.g. many different memory sticks ; on the other hand, it may be useful to recreate this .reg after adding a new external hard disk or other storage device (and you want fixed drive letters for those), and highly advised to recreate it after repartitioning your local hard disk(s).

    2. Because of this behaviour, it is even no problem if ever the cloned partitions become visible to your source Windows - "Run_before_imaging.reg" will remove these references before any image is made. Just remember to hide these partitions in the boot before making a new "Run_before_imaging.reg" file (for that reason, it is also highly advised you perform the "Clean up" step before making this new file).

    3. "Run_post_imaging.reg" should normally never be renewed, unless you undertake some drastic action that would alter the source partition signature, such as moving (the beginning of) the source partition. Strictly speaking, "Run_post_imaging.reg" is even not always necessary, because Windows will recreate these entries upon the first reboot of the source Windows. However, using it allows you not to worry about when the next reboot will happen, and it is probably the safest way to keep the registry key in good order.

    Addendum: Realized the problem too late ?
    If you have an old image to which you did not apply the registry fix, but that you still would like to use in a multi-boot setup, you may want to consider Method#1 or Method#3 ("Kawecki's Trick") here. I'm just referring this for the sake of completeness, I haven't tried this myself !!
    Last edited: Mar 30, 2008
  3. K0LO

    K0LO Registered Member

    Mar 9, 2006
    State College, Pennsylvania

    Very nice writeup and I commend you on the level of detail. But I think you will now need to change your name from JustAnotherNoob to something else!

    This occurs with Vista even when making no changes to the registry. I see it happen whenever I restore a Vista partition. I believe the reason to be that the image is created while Vista is running (hot imaging) and then restored when it is not running, so Vista considers the first startup after imaging to be after an "Unexpected Shutdown". No harm is done when this occurs other than your Vista Reliability Index will have a few points deducted.
  4. JustAnotherNoob

    JustAnotherNoob Registered Member

    Mar 9, 2008
    Thank you, Mark !

    Aha - that's what causes that !! I made my first images of the Vista installation from a bootable Acronis CD. I then started using ATI within Windows, but I immediately applied the above procedure to these images. If I remember correctly, I didn't get a Windows Error Recovery Screen when restoring from a "cold image". So in all likelihood you're right again, it is caused by the hot imaging. Because I changed two things in one go, I mistakenly linked it to the missing registry key.

    In any case, there indeed seems to be no harm done. I certainly do not wish to give up the convenience of making images from within Windows just to preserve my Vista Reliability Index (I had to look up what that is - another thing I learned today ...)

    JustAnother"Semi"Noob :D
  5. mumdigau

    mumdigau Registered Member

    Mar 5, 2005

    I had similar needs as JustAnotherNoob: A well functioning, optimal configured system (Windows XP Pro), but lots of changes - almost on daily basis - for more than 200 applications installed, of course for Windows itself, and new applications to check if they could be improvements compared to existing apps or fill gaps. I didn't like to spoil my main system, so I installed a 2nd system, mainly for testing purposes and checking if updates to existing SW will do any harm, and sometimes for helping repair the main system.

    At the time I installed the test system I wasn't aware of implications to follow MS's way to do multibooting (one boot partition C:, and then switching to different system partitions according to entries in boot.ini). Thus systems aren't really independent from each other, because they are all tightend to C:. Even more, I didn't hide the main system when I installed the test system, so latter was assigned a different drive letter. This leads to lot of surplus work (repeating program settings, adapting scripts etc.).

    I want to get rid of these caveats. So I searched the net, and came across this excellent article, as well as the magnificient publications of Dan Goodell (see I followed the path JustAnotherNoob showed up, and will shortly explain which tools and programs I used to do so. In addition, I slightly enlarged the scope: Cloning is now feasible in both directions (let's call it shuffle): When after some time things are going well in the test system, it would be annoying to rebuild the modifications in the main system. Therefore the test system is cloned back to the main system which can save a lot of time. Consequently, we are now talking of source system and target system.

    The daily handling should be simple, and stable. Some preparational work is needed. Astonishingly, its's not too much.

    1. Prerequisites

    1.1 First, we have to get rid of MS's way to boot in order to completely separate main and test system, i. e. we need an external boot manager. My choice was the freeware BTTR BootMgr (see It's a small, neat, simple to use program which completely integrates in the MBR without occupying any additional space on the disk, its main advange over its competitors. It can selectively hide/unhide partitions, a must as can be seen from JustAnotherNoob's article. But being so small it lacks the possibilty to hold different boot scenarios. We need three of them:

    - the "normal" boot where the user selects to boot either to the main or the test system while both systems can see each other; the system partition's drive letter doesn't change regardless which system is being booted to
    - boot to the source system while the target system is hidden
    - boot to the target system while the source system is hidden

    Of course, BootMgr can do some basic MBR handling. But I prefer to do all my MBR and Track 0 related work with an other nice program.

    1.2 MBRtool (see is the freeware tool which will do all MBR tasks for me. It's very easy to work with, and I used it to save (to file) and switch between the three needed MBRs:

    - BOTH for the "normal" boot
    - MAIN for boot to the main system (test system hidden)
    - TEST for boot to the test system (main system hidden)

    As both BootMgr and MBRtool just work from pure DOS, we need an DOS booting floppy. Images can easily be found all over the net. I used one, and integrated both programs onto it selectable via a simple menu. In addition, the floppy holds also the three MBRs (BOTH, MAIN, TEST), so MBRtool can get them to switch the boot environment as needed.

    1.3 In order to overcome Windows drive letter problems as described by JustAnotherNoob we have to build the appropriate pre and post commands for Acronis TrueImage's backup process. I decided to build these commands dynamically so as to avoid to manually correct them when the system configuration has changed. I made up two small scripts built on the freeware script language AutoIt (see They do the following:

    - save the current mounted devices (HKLM\System\MountedDevices)
    - discard all source and target partition entries
    - restore to prior state when the backup has finished

    Especially, in the 2nd task it's important to include both source and target entries so we can clone and reclone - the shuffle! These two scripts have been selected as pre and post backup commands in TI.

    1.4 Finally, if you are on Windows XP, move ntldr,, and boot.ini to the root of main and test system. Each boot.ini must not contain than one line under [operating systems] referencing the correct partition where to boot to. If there is only one line, the contents of boot.ini will not be shown during the boot process (because there is no choice).

    (For Vista see tons of documents in the net.)

    That's it more or less. Now let's go to see how everything fits together in practice.

    2. The shuffle

    2.1 Boot to DOS. In MBRtool load the MBR where the source partition is active, and the target partition is hidden (either MAIN or TEST). Reboot.

    2.2 Backup the source partition.

    When you want to clone/reclone proceed as follows:

    2.3 If your source partition is hidden, and your target partition is visible you can proceed to 2.4. Otherwise:
    Boot to DOS. In MBRtool load the appropriate MBR (either MAIN or TEST).

    2.4 Boot to the TI rescue CD. Restore the target partition. Be shure not to include MBR and Track 0 (partition only). Reboot.

    (If you want to see the source partition afterwards, too:

    2.5 Boot to DOS. In MBRtool load MBR BOTH. Reboot.)

    I hope I could make as clear as possible what I've built up for me here. Feel free to ask questions and/or give comments.

    Best regards


    EDIT: I forgot two things to mention:

    1. Before you reboot (step 2.4) you should check if the boot.ini of source and target partition have the correct partition number in their multidisk partition entries. I'm on TI 9.5 Build 8115 which properly sets the partition numbers, but that might be different with the TI version you use. So boot to DOS and check with EDITBINI.EXE against the partition table as it is shown in BootMgr. With EDITBINI.EXE (see you can read and change, if necessary, from DOS any boot.ini on a NTFS partition.

    2. If you're done you should rename the target partition which simply can be done within Windows Explorer.
    Last edited: Sep 11, 2008
  6. Kritker

    Kritker Registered Member

    Sep 20, 2007
    Hmm, I must be one of the lucky ones. When I reconstituted my system (clean install of Windows XP Pro SP3), I simply installed GAG to handle my two, nearly identical, Win XP partitions (which were and are hidden from each other) so either serves me as my C: drive. I did nothing else. I have encountered no problems yet and haven't notice any interactions.

    Am I missing something? Should I expect some problems?
  7. mumdigau

    mumdigau Registered Member

    Mar 5, 2005

    No, you shouldn't be worried.

    Do you remember how you installed the 2nd system? Did you hide the 1st one during install of the 2nd? Otherwise, Windows will assign a different drive letter to the 2nd system - with all the annoyances I had to struggle with. Obviously, this is not the case for you. Good.

    But that's only one part of the story. We are talking of cloning here, so you are able to double your system, and copy it forward and backward. This has some advantages over having two "similar" systems installed:

    - The systems are really identical, so test results are absolutely relevant.
    - When something goes wrong, you can simply throw the cloned system away
    and make an other clone.
    - If your modifications of the cloned system are worth to be carried on: fine! Reclone, i.e. copy your cloned system to the 1st system so they are both identical again. Thus you don't have to rebuild the modifications in the 1st system.

    The techniques described above just should show a secure and simple way to fulfill the necessary tasks.

  8. Xpilot

    Xpilot Registered Member

    May 14, 2005
    To avoid all possible multi-boot problems there is of course a hardware solution.
    All that is required is the installation of a main harddrive caddy/drawer system. I use these as the main part of my TI backup/recovery procedure. With the addition of another drive/drawer I can clone by restoration to this extra drive,install a new OS or do anything else that is required.
    To boot to a different system it is just a matter of swapping over hard drives.

Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.