Fixing BOOTMGR blinking cursor of death when moving Windows across different partitions

5.00 avg. rating (94% score) - 1 vote

Recently I attempted to transfer the Windows 8 installation from my desktop machine to my Thinkpad laptop by using Clonezilla to clone the Windows partition on the desktop machine, and restore it to my Thinkpad laptop. The process should be as simple as booting to the Windows 8 installation DVD after the restore, following this tutorial to re-initialize the bootloader and running the EXTEND FILESYSTEM command from DISKPART to resize the Windows NTFS filesystem to fit the new partition size if that has not already been done by Clonezilla. Upon first boot on the new machine, Windows 8 should detect the hardware changes and display ‘Getting devices ready’ while it attempts to setup the device drivers for the new machine. Within a couple of minutes, Windows should be ready for use without the need to reinstall everything from scratch.

The problem

Sound straightforward, isn’t it? Or so I thought. However, this time around, things were a bit different. After the restore and despite running bootsect and bootrec from the Windows installation DVD multiple times, Windows still refused to boot, showing just a black screen with a blinking cursor after BIOS POST. I even ran bootrec /fixmbr, bootrec /fixboot as well as bcdboot in various combinations to no avail. The Automatic Startup Repair in the installation DVD is of no use too – it simply reported an error trying to repair the Windows installation despite detecting correctly that Windows 8 was installed on the machine. I even played around with the setting “clone the hidden area between MBR and the first partition” in Clonezilla, which did not help. So something must be seriously wrong here.

My research on this yielded little useful information. Most sources suggest a clean install, which would be a waste of time, while others suggested the same steps which I have already tried. Even the Easy Recovery Essentials live CD could not fix the issue – it reported that the Windows installation is not supported, despite the website listing Windows 8 among the list of supporting operating systems. I tried to use the Super Grub2 live CD to boot from the Windows partition, but the same thing – a blinking cursor – persisted. I also attempted to install GRUB and boot the Windows partition using chainload but encountered the same issue once I chose to boot the Windows partition.

By now I am a bit exhausted. It’s like I am leaving no stone unturned and yet I still cannot fix the issue. In one last try before proceeding with re-installing Windows, i decided to use Hiren Boot CD’s ‘Boot from Hard Drive’ feature to see what will happen:


And guess what, the machine could boot to the Windows desktop properly, after just a few minutes showing ‘Getting devices ready':


This confirms that the Windows installation still works fine and the issue is perhaps due to some subtle problems with the bootloader installation.

Typical boot process

I decided to find out the root cause of the issue, starting from the typical boot process on a PC, summarized below:

  1. After POST, the BIOS will transfer control to the very first sector of the device to boot from. For partitioned devices such as hard disks, this is usally the Master Boot Record (MBR). For non-partitioned devices such as floppy disks, this is the boot sector containing code for operating system such as MS-DOS.
  2. The code in the first sector will decide what to do next. For bootloaders of early operating systems such as MS-DOS (created by fdisk /mbr), this consists of selecting the first active partition on partioned devices, known as the Volume Boot Record (VBR) and transferring control to that sector. For non-partitioned devices such as floppy disk, the first sector of the device will simply boot the operating system in question, e.g. MS-DOS.
  3. Assuming we are on a partioned device, control will be transferred to the VBR at this point. The VBR will contain initialization codes for the appropriate operating system (MS-DOS), or codes for a bootloader (NTLDR, BOOTMGR, GRUB) that allows users to select an operating system to boot to from a list.

If you are using rEFIt as the boot manager on a Mac, rEFIt will scan the installed media on your machine looking for partitions with a boot sector. When a partition is selected, control will be transferred to the boot sector of that partition (step 2 above).

In my case, the fact that Windows could boot from Hiren Boot CD whereas it could not boot natively from the hard drive implies that the machine has the correct BCD configuration but with a faulty Volume Boot Record (VBR), causing the boot process to hang once control is transferred to the VBR. The reason why it worked when using Hiren Boot CD is because the ‘Boot from Hard Drive’ function on the CD bypasses the MBR or VBR and instead uses NTLDR, a feature of GRUB, to load BOOTMGR directly. Once BOOTMGR is loaded, Windows could boot normally as the BCD configuration is still fine.


So is there a way to make this a permanent solution, e.g. boot Windows from the hard drive without using Hiren Boot CD? The answer is amazingly simple, just add the following entry to GRUB and Windows should boot from GRUB:

menuentry "Windows 8" --class windows --class os {
    insmod part_msdos
    insmod ntfs
    insmod ntldr
    set root='(hd0,msdos1)'
    ntldr ($root)/bootmgr

The last line ntldr ($root)/bootmgr is very important – it tells GRUB to use its NTLDR (NT Loader) module, the default bootloader that comes with Windows XP and earlier, to load BOOTMGR. This helps us bypass the VBR and allows Windows to boot normally. Had we used chainloader +1, the default configuration that is usually automatically created via update-grub, the blinking cursor issue would still persist as chainload will simply transfer control to the VBR causing the boot process to hang again.

Take note that you may have to play around with the partition number (hd0, msdos1) to get it to boot properly. If your machine can boot to the Windows Boot Manager screen but complains that the BCD configuration cannot be loaded even though the file C:\BOOT\BCD exists, try to install BCD to a different partition. This needs not be a primary partition – a logical partition is fine. In my case, Boot Manager first reported error 0xc0000225 and could not display the boot menu, but could boot fine to Windows once BCD was moved to a different partition. I do not know the reasons why it could not load the BCD configuration – perhaps it is simply some hard-coded behaviour to prevent people from moving their Windows installation around.

A closer look

I am not satisfied with having Windows up and running because I am still not clear what causes BOOTMGR to hang despite proper setup. Therefore I decided to retrieve the boot sectors from the original desktop machine and from my Thinkpad laptop for comparison. Using Linux, this can be as simple as running the following command:

dd if=/dev/sda1 of=/path/boot.bak bs=512 count=1

where /path/boot.bak is the name of the file storing the sector. Replace /dev/sda1 with the correct identifier for your Windows installation partition. To retrieve the MBR instead of the boot sector, replace /dev/sda1 with a disk identifier, e.g. /dev/sda.

After retrieving the MBR and the VBR (download both files here), I compared them using AptEdit, a free text/binary comparison tool. The MBRs from both installations are similar, except for some differences at the end:


The VBRs are also similar, except for some differences at the beginning of the files:


Some text string containing typical bootloader error messages can also be recognized from the VBR:


Next, I attempted to use ndisasm to disassemble the boot sector to see the exact differences:

ndisasm -b16 -o7c00h -a -s7c3eh boot.bak 

However, the resulting assembly code for the VBR from the different Windows installations is too complicated for me to analyze to make sense of the differences and at this point I had to stop the research due to time constraints.


The question remains as to what differences in the VBR cause BOOTMGR to stop with a blinking cursor when Windows is transferred to a different machine. Some websites stated that this is due to hard-coded checks deployed when BOOTMGR is installed from the Windows installation DVD. These checks will hang the boot process with just a blinking cursor if BOOTMGR detects that Windows is not present on the same partition as what was recorded during the setup phase. I do not have the time to verify this theory, but the partition structures on the two machines are indeed different in my case. Perhaps Windows could have booted natively for me without much hassle if the partition structures were the same. Unable to find any official documentation on this, I can only suggest people to use the NTLDR command from GRUB to boot Windows as a workaround for this issue, and hope that some readers with expertise in bootloaders can help me answer this question.

5.00 avg. rating (94% score) - 1 vote


A tough developer who likes to work on just about anything, from software development to electronics, and share his knowledge with the rest of the world.

2 thoughts on “Fixing BOOTMGR blinking cursor of death when moving Windows across different partitions

  • August 14, 2023 at 11:08 pm


    Thanks for this wonderful and very helpful article. It helped me to get my cloned (legacy/BIOS) Windows 10 partition to boot again. The problem in my case was that the cloned partition was not starting at the same sector as on the previous SSD. (I had moved the partition from Sector 409640 to Sector 411648 in order to have a 1MB sector alignment. ) This caused the bootstrapping to not find the BOOTMGR.

    After using the Hiren Boot CD solution I found a permanent fix in my case:
    The only thing I had to make was to adjust the 4 byte value starting at offset 0x0C into the NFTS partition to the correct number of sectors BEFORE the partition. So check the starting sector of the NTFS partition (in my case 411648), obtain the HEX representation (for me 0x00064800), then replace the 4 bytes at offset 0x0C by this number (in reversed/little-endian order): I had to overwrite the incorrect/old value of “28 40 06 00″ (corresponding to 409640 sectors) by “00 48 06 00″ (corresponding to 411648 sectors).
    The following webpages helped me to sort this out:

    Good luck for those struggling with the same problem! :-)

  • ToughDev
    August 14, 2023 at 11:28 pm

    Hi Maga,

    Thanks a lot for sharing your knowledge and I’m glad the article helped you. From experience, Windows almost always required manual changes during migration if the partition structure changes whereas Linux will boot just fine with just a simple update-grub.

    Thanks for the links on the details of the NTFS boot records. I am sure it will help many others.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>