VBox 6.1.34 and Windows XP

[MietekN]

After updating Virtualbox from version 6.1.34, the virtual machine with Windows XP stopped starting. The host is Windows 10 21H2. Only "Error loading operating system" is displayed in the virtual machine window. Rolling back to the previous version 6.1.32 fixes the problem.

[scottgus1]

Please provide two VM logs, one from 6.1.32 and the other from 6.1.34:

Start the VM from full normal shutdown, not save-state. Run until you see the problem happen, then shut down the VM from within the VM's OS if possible. If not possible, close the Virtualbox window for the VM with the Power Off option set.

Right-click the VM in the main Virtualbox window's VM list, choose Show Log. Save the far left tab's log, zip it, and post the zip file, using the forum's Upload Attachment tab.

[MietekN]

Logs of both versions.

[mpack]

This is very strange.

This is what appears in the log in the 6.1.34 version:

00:00:11.871429 VMMDev: Guest Log: BIOS: int13_harddisk: function 02, disk 80, parameters out of range 0000/0020/0021!
00:00:11.871447 PIIX3 ATA: Ctl#0: RESET, DevSel=0 AIOIf=0 CmdIf0=0xc4 (-1 usec ago) CmdIf1=0x00 (-1 usec ago)
00:00:11.871491 PIIX3 ATA: Ctl#0: finished processing RESET
00:00:11.872132 VMMDev: Guest Log: BIOS: int13_harddisk: function 02, disk 80, parameters out of range 0000/0020/0021!
00:00:11.872150 PIIX3 ATA: Ctl#0: RESET, DevSel=0 AIOIf=0 CmdIf0=0xc4 (-1 usec ago) CmdIf1=0x00 (-1 usec ago)
00:00:11.872192 PIIX3 ATA: Ctl#0: finished processing RESET
00:00:11.872827 VMMDev: Guest Log: BIOS: int13_harddisk: function 02, disk 80, parameters out of range 0000/0020/0021!
00:00:11.872844 PIIX3 ATA: Ctl#0: RESET, DevSel=0 AIOIf=0 CmdIf0=0xc4 (-1 usec ago) CmdIf1=0x00 (-1 usec ago)
00:00:11.872885 PIIX3 ATA: Ctl#0: finished processing RESET
00:00:11.873521 VMMDev: Guest Log: BIOS: int13_harddisk: function 02, disk 80, parameters out of range 0000/0020/0021!
00:00:11.873538 PIIX3 ATA: Ctl#0: RESET, DevSel=0 AIOIf=0 CmdIf0=0xc4 (-1 usec ago) CmdIf1=0x00 (-1 usec ago)
00:00:11.873579 PIIX3 ATA: Ctl#0: finished processing RESET
00:00:11.874213 VMMDev: Guest Log: BIOS: int13_harddisk: function 02, disk 80, parameters out of range 0000/0020/0021!
00:00:11.924709 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=720 h=400 bpp=0 cbLine=0x0 flags=0x0 origin=0,0

My immediate reaction is that this is drive corruption, but the 6.1.32 log doesn't have these lines.

Another possibility is that it is drive corruption, and 6.1.34 just does a better job of detecting it.

I notice that the drive is 16GB, so a bit on the small side - it's possible you have filled it and this led to unusual consequences. You might like to try cloning the the drive using CloneVDI. Set the "Keep UUID" option, increase size to 32GB and have it increase the main partition size too. The clone VDI will be a drop-in replacement for the old one, which you should set aside for now. Let's see if that changes things, or if CloneVDI will even let you (it looks for bad offsets in the block map as part of validation).

[MietekN]

The disk has been checked (chkdsk /f) and has about 5GB of free space.

[fth0]

00:00:06.196845 VMMDev: Guest Log: BIOS: ata0-0: PCHS=16383/16/63 LCHS=1024/255/63

00:00:09.372066 VMMDev: Guest Log: BIOS: ata0-0: PCHS=16383/16/63 LCHS=1024/171/2

In VirtualBox 6.1.34, the auto-detection of the LCHS geometry has been changed, and we're probably seeing unexpected consequences here.

[fth0]

Can you provide the MBR (Master Boot Record) of the virtual hard disk, either as a file or a hexdump (I'd like to see the partition table in its raw form)?

[MietekN]

MBR

[fth0]

Please open a Windows Command Prompt on your host and use the following commands to show the current state of the VDI file, to modify the VDI header and to show the new state:

Code: Select all

cd "C:\Program Files\Oracle\VirtualBox"
vbox-img info --filename "VDI file"
vbox-img geometry --filename "VDI file" --cylinders 1024 --heads 255 --sectors 63
vbox-img info --filename "VDI file"

Run the VM and provide the output of the commands above and the new VBox.log file.

[mpack]

Before we get too complex here, did you try cloning the VDI using CloneVDI yet?

[fth0]

Before we get too complex here

FWIW, I just tried to leave the complexity out by not explaining the finer details (yet) and by just providing the preferred solution.

The current behavior is well understood (at least by me), and the first vbox-img command will provide the final proof. I'll be happy to explain it afterwards.

[mpack]

There's no need to explain it. Geometry info is not copied in a CloneVDI clone, so it should make the problem irrelevant. It will also fix the likely problem of the VDI being too small.

[fth0]

Geometry info is not copied in a CloneVDI clone

If the CloneVDI clone has LCHS=0/0/0, the VirtualBox 6.1.34 auto-detection will bite the OP nonetheless.

[MietekN]

On version 6.1.32, I have this result:

vbox-img info --filename "d:\VPC\Windows XP\Windows XP.vhd"

--- Dumping VD Disk, Images=1
Dumping VD image "d:\VPC\Windows XP\Windows XP.vhd" (Backend=VHD)
Header: Geometry PCHS=33288/16/63 LCHS=0/0/0 cbSector=512
Header: uuidCreation={4ce9fbcd-96d4-4a67-a2b6-ef9b4e051622}
Header: uuidParent={00000000-0000-0000-0000-000000000000}

[fth0]

Thanks for the output of the vbox-img info command, which matches my expectations. It doesn't matter that you're using the VHD format, the vbox-img geometry command should work nonetheless and solve the problem for you. Please proceed with my instructions.

As always, it doesn't hurt to have a (restorable) backup of important data when using computers. If anything goes wrong, you can restore a previous state.