What causes "A disk read error occurred, Press Ctrl + Alt + Del to restart"?
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
andFixMBR
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
, whereX:
is the drive letter of the mounted volume. (The location of the tool is likely to beC:\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?
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.
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.