Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a virtual machine containing Windows XP SP3.

When I resized the VHD file (and the embedded partition), and tried booting, I got:

A disk read error occurred
Press Ctrl + Alt + Del to restart

Some notes:

  • FixBoot and FixMBR don't help.

  • ChkDsk doesn't help.

  • The partition is indeed active.

  • The partition starts at sector 63 (it also did so before the problem) of cylinder 1, head 1, and is marked as type 0x07 (NTFS)

  • My host OS reads the VHD and the partition completely fine

  • I'm interested in knowing the cause rather than the fix. So "re-format the disk", "reinstall Windows", etc. aren't valid solutions.

    It's a virtual machine after all... I have nothing to lose, so I don't care about fixing it.
    I just want to know what's causing this problem, in case I run into it again on a physical machine (which I have done before).

More info:

I made a sample VHD file illustrating (almost) the same problem which you can download here.

To reproduce the problem:

  • Download the file (it's highly compressed, be careful!), and try booting it in VirtualBox (or some other VM). Notice that you'll be told "Error loading operating system". (While the error is different, it's the same issue.)

  • Now try mounting the VHD in Windows's Disk Management, and running BootSect.exe /NT60 X: /MBR, where X: is the drive letter of the mounted volume. (The location of the tool is likely to be C:\boot\bootsect.exe, but if it's not there on your system, then you'll need to find it somewhere else...) Now un-mount it, and try booting. The boot should now proceed correctly. (Although it won't find Hal.dll, at least you know it's working.)

  • Now do the same thing as the last step, but use /NT52 instead of /NT60. You will now be greeted with the first error -- indicating that the Windows XP loader doesn't like the disk.
    So my question is: Why?

share|improve this question
@Moab: What you said makes no sense. :( I resized it on my host system, and even if I had done it on my guest system, it's not like the software would be behaving differently... – Mehrdad Mar 31 '12 at 22:22
@Moab: Are you assuming it's dynamically sized? Because it's definitely a fixed-size drive... and like I said, it's fine in my host OS, so it's not like it's unreadable or something. – Mehrdad Apr 1 '12 at 0:26
I would have assumed that resizing the disk would have modified the some vital information in the disk that the OS uses to work out the partition it needs to boot from, but as you've tried the main tools to repair that kind of thing it may be something in the OS itself. When does the error occur? Is it immediately after the VM starts up or can you get to the Boot Menu screen where you select safe mode or normal boot? – Mokubai Apr 15 '12 at 19:31
Another thing to try would be to create a new (larger) vhd and within the VM use Clonezilla to copy the old partition to it and see what it does then. – Mokubai Apr 15 '12 at 19:33

The cause is either that bootloader is calling the BIOS to read other disk sectors and that call is failing, or the bootloader does not consider the partition table valid.

If I am not mistaken, when Windows formats a disk, doesn't it create a small partition at the very end of it, or leave an unpartitioned area there? Did your resize utility recreate that? Sounds silly but this might be the reason why it is complaining. Weird, but I wouldn't put it past Windows (and possibly something in newer versions) to have such a quirk.

share|improve this answer
I tried leaving a small unpartitioned area at the end (10 MB -- I remember XP is usually 8 MB), but it didn't work. – Mehrdad Apr 15 '12 at 21:19
I have just done it for my VHD. I resized the partition and left 20MB free unallocated space. It worked. Thanks, get +1. – Jet Feb 4 '15 at 16:32

File-systems are intricate, complex, finicky things. For example, an old copy of Partition Magic complains about some little numeric inconsistency or something about the partitions on one of my disks while Windows (XP) and Easeus Partition Master and such all chug along without issue. Even an old copy of Norton Disk Editor doesn’t complain about that disk.

The fact is that there are a lot little things that can go wrong, or worse, that can “go not wrong” yet still be incorrect (i.e., an incorrect value could show no symptoms).

What likely happened was that when you resized the VHD file, the tool that you used had a bug and did not (correctly?) update a field somewhere in the file-systems of the disk (partition table? boot-record? boot-sector? NTFS meta-files?)

As others have pointed out, the error you are getting is usually a BIOS error as opposed to an OS error. What is likely happening is that the field that was not correctly updated was early in the disk (e.g., in the boot-record or partition table) so when the VM BIOS tries to read the disk, it is finding incorrect/inconsistent values and throwing an exception. You did not mention what kind of resizing you did. Did you shrink or expand it?

My hypothesis is that you resized it down, and the BIOS is reading the partition table and trying to read beyond the disk (to non-existent sectors) because the size of the disk was not properly updated.

As for the host, I would surmise that the reason that it can correctly read the disk is because the software that mounts the VHD file is somehow masking the error. After all, to the host, the “disk” is not a real disk and is actually just a (.vhd) file, while to the guest, the disk is supposedly a real, physical disk. As such, the host can error-correct problems that the guest cannot.

You can check to see if there is an updated version of the tool or use a boot disk like CloneZilla (or find a copy of PTEdit) to run in the VM and examine the “disk” from within the host.

share|improve this answer
I just ran another partition manager on it, and like the ones before, it didn't report a single error. So confused... (also, something else that's weird: if I boot the working disk as a Primary Slave instead of a Primary Master, I get the same error...) – Mehrdad Apr 15 '12 at 20:49
I just confirmed that it isn't a partition issue, but a disk issue. The problem happens when I use VHDResize to resize it... the partition inside is left untouched, but the disk is resized to a size greater than that of the partition. – Mehrdad Apr 15 '12 at 21:18
Looking at the table you added to the question, it looks like the partition remains the same, but the disk is reduced to only 1,147 sectors more than the partition. The values in relation to the partition remain unchanged, so what is likely to be happening is that some of the meta-data in the .vhd file that controls the size of the disk itself is incorrect. Any tools run from within the VM (including the BIOS) would be limited to whatever the VM tells it about the disk. – Synetech Apr 15 '12 at 22:39
Oh, so you think the VHD itself is corrupted (even though the contents are fine)? That's an interesting idea... I haven't come across any errors while mounting it in Windows, but maybe that's just luck... – Mehrdad Apr 15 '12 at 22:50
In addition to the contents of the disk itself, the .vhd file contains meta-data about the disk. Perhaps VHDResize is not updating a field when it performs the modifications. The specs for the VHD format are available, so it doesn’t need to be reverse-engineered; so maybe it’s just a bug. >I haven't come across any errors while mounting it in Windows Can you mount it and then format and fill it up without errors? – Synetech Apr 16 '12 at 0:06
│   Sectors:     3149824          Disk Signature:  0xEE3EEE3E                 │
│Pos Idx Type/Name Size Boot Hide  Start Sector  Total Sectors  DL Vol Label  │
├─── ─── ───────── ──── ──── ──── ────────────── ────────────── ── ───────────┤
│ 1   1  07-NTFS   1.5G  Yes  No              63      3,148,677 F: <None>     │

3,148,677 / 3,149,824 = 0.999636 = 1 - 0.000364

1.5G * 0.000364 = 0.000546G

There only seem to be about 546 KB free, it might be possible that it can't write a file upon boot.

share|improve this answer
I think you're taking the "1.5G" too literally. I'm pretty sure it's rounding/truncating. – Mehrdad Apr 16 '12 at 5:31
@Mehrdad: Then, still. What if it needs to expand the page file during boot? Expand it a few G and see what happens. If it's still broken then some essential bits were gone or the VHD is corrupt; if it works, you didn't leave it enough room. You might say that I take it too literally; so, please also take a look at the drive's properties using Windows Explorer (mount it in the disk manager) which should give the exact free count... – Tom Wijsman Apr 16 '12 at 5:40
You do know that the page file is only used after the kernel has finished booting, right? (i.e. about the same time as BootExecute is being run.) This thing isn't even loading boot.ini. – Mehrdad Apr 16 '12 at 5:50
If you're interested, I've uploaded a sample with instructions in my update. (It might take a bit of time to reproduce it, though.) – Mehrdad Apr 16 '12 at 7:13
Tom: You'll see if you download the VHD I posted. There's nothing on that drive other than a boot loader (i.e. no registry, no kernel, no page file settings, not even a hal.dll... nothing), so the existence of a page file isn't exactly exactly relevant (see the NT startup process... notice that page file creation is waaaay later than kernel loading)... and besides, how would that explain the fact that it works correctly when I use bootsect /nt60?! – Mehrdad Apr 16 '12 at 15:32

One possibility I see is that after resizing the VHD, some incompatibility exists between what the BIOS thinks it knows about the hard disk and the disk itself.

Another possibility is that the free space on the disk is too small or too fragmented for Windows to boot. Sometimes defragmenting a disk with this error makes it bootable.


According to your added info, you have drastically reduced the VHD from 127GB to 1.5GB, so there might not be enough space for the pagefile. The resizer you have used may have been too aggressive, or it may have moved such unmovable Windows system files and therefore rendered the disk unbootable.

For proper operation, Windows needs quite a lot of free space on the disk, with some of it contiguous (for at least the pagefile).

I think that the correct procedure should have been from the 127GB VHD to turn off in XP the pagefile and system restore, clear the Recycle bin, defragment the disk with a defragmenter that can consolidate used space at the top (or free space at the bottom), then do the resize leaving free space that is several times the defined RAM size.

With this procedure you might have ended up with a viable and bootable disk to start with.

Sometimes these problems clear up with repeated reboot, maybe by Windows finally managing to rearrange the disk to its liking.

share|improve this answer
Yeah I'm wondering what the incompatibility might be. – Mehrdad Apr 15 '12 at 20:52
I have added some more guesses. – harrymc Apr 16 '12 at 6:02
Page files aren't even used until the the kernel has finished loading. The problem here is that boot.ini isn't even loaded properly in the first place, let alone even starting the kernel... the problem here simply can't be due to this. – Mehrdad Apr 16 '12 at 7:04
What Windows does exactly during boot remains a mystery. All I can say is that I have seen similar behavior in XP computers that have over-filled the system drive. My solution was always to reformat and install, so I have never found out exactly what the problem is. – harrymc Apr 16 '12 at 7:20
That's what I mentioned yesterday. I doubt though if Mehrdad has even tried it, there is various stuff written at boot as can be seen in tracing tools like Process Monitor and Windows Performance Analyzer. @harrymc: As you said mistery I would suggest you to do at least a Process Monitor boot log, because the booting sequence is not a mystery at all... :) – Tom Wijsman Apr 16 '12 at 10:26

(Adding another and somewhat different answer.)

You say that booting with the NT52 boot-sector does not work, but that NT60 does.

The difference may be in the boot process. NT52 is the XP boot that uses NTLDR, while NT60 is the Vista method that uses Bootmgr.

NTLDR uses the boot.ini file to locate hard drives and partitions. It consults the computer's firmware (BIOS) to find out which hard drive is considered to be drive zero, then looks at the partition table on that drive to find out which partition is number one. Once it knows the location of the partition it can then find the Windows\system32 folder of the OS it has been asked to start.

Bootmgr consults the BCD file in the Boot folder for the information it needs to find for the correct drive and partition, but it does not use the firmware to find the hard drive, or the partition table to find the partition. Instead it uses the unique Disk Signature in the MBR of a hard drive and the partition offset (starting sector) of a partition.

Apparently while resizing the disk you have destroyed an element that is used for the NTLDR boot process but is not used by Bootmgr. This could be the BIOS, in the sense that the information it holds about the hard disk is no longer correct, such as the number of cylinders or sectors, or something in boot.ini itself.

In addition, bootsect updates the volume boot code, not the master boot code. The master boot code is part of the master boot record (MBR) and there's only one per physical disk. The volume boot code is part of the volume boot record and there's one per volume. It may have been that with your tries at making the disk bootable, some incompatibility has crept in between the two that requires better knowledge than mine of the boot process to analyze.

As Bootmgr does not use the BIOS or boot.ini, it apparently manages to use the MBR and to boot.

share|improve this answer
FYI: bootmgr isn't even on the disk (nor is boot\BCD, nor is anything else Vista-related)... you can check this by downloading my example, and opening it with something (e.g. 7-zip). The only Vista-related thing is whatever the boot sector has, because of bootsect.exe... that's all. – Mehrdad Apr 16 '12 at 9:17
Both the NTLDR and Bootmgr boot codes only set up the environment used for invoking the NTLDR and Bootmgr programs. I would theorize (guess) that either (1) If Bootmgr is missing, the NT60 boot code fails-back to NTLDR but does a better job of setting up the environment for it than the NT52 code, or (2) The NT60 code in your XP bootsect is still not the Vista version but is still an improvement over NT52. I would expect that (1) would rather cause a Bootmgr missing message, so believe more in (2). – harrymc Apr 16 '12 at 9:37
Huh, I was actually under the impression that (1) is likelier than (2)... interesting... – Mehrdad Apr 16 '12 at 9:38
Both are equally likely for now. You could maybe test this by copying bootmgr and a Boot folder from Vista and deleting ntldr, to see if the NT60 boot can succeed. But this is just guesswork on my part (never tried these games). – harrymc Apr 16 '12 at 9:44

I had a similar problem. xp with the same error. bootsect /nt52 wouldn't fix the problem. I cloned the drive out and cloned it back in, and presto- it boots. The lesson is that you have to be an expert in partitioning to pinpoint the problem. the rest of us have to resort to hacking around and whatnot. someone on the internet said that these problem can be caused by a bios limit of 137gb. might be, but it actually has several causes.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .