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
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).
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?
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.
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.
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.
╒═════════════════════════════════════════════════════════════════════════════╕ │ 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.
(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.
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.
To solve this problem, Acronis was used. I made a copy of the boot disk, then I restored it and the system started up.