Strange VDI Corruption Incident

[Justin Gottula]

I was running a Windows 7 32-bit guest on Windows 7 64-bit host today and happened to be pausing/resuming with some regularity (trying to balance CPU time between a pair of running VMs by pausing the one I didn't need running at the moment). At one particular moment on one particular boot, and, according to the log, just as I told the VM to pause for a moment, I got a 'VDI: invalid header in <the vdi file the VM booted from>' error message, which I simply ignored at first. However, attempts to continue execution of the VM were unsuccessful, so I reset it, after which every attempt to boot resulted in the same error:

Power up failed (vrc=VINF_SUCCESS, rc=E_FAIL (0X80004005))

Also, the virtual disk showed up with a warning icon throughout the VirtualBox GUI. So, I concluded that the VDI file had become corrupted somehow. Being a curious person, I popped open my hex editor and compared this VDI file with the VDI file for the boot drive from the other VM I had been running. With this comparison, and a handy reference to the VDI file format with hex offsets, I made the following observations:

1) The VDI file appeared to have been overwritten by something that definitely did not belong in a VDI file from address 0x40 (64 bytes into the file) to around 0x11d8 or so (give or take a few 0x10).
2) This something had overwritten very important header fields like the size of the drive, and the UUID, making it totally unmountable (hence, the errors).
3) The offending overwrite appeared (by comparison to several valid VDI files) to have overwritten important data starting at offset 0x1000 and ending at 0x11d8 or so (again, the end is hard for me to determine since I'm unfamiliar with the structure of that part of the file). It is abundantly obvious that important stuff was overwritten with something that definitely did not belong in that part of the file.
4) The binary content that was written to this portion of the VDI file appeared abundantly similar to parts of an NTFS partition that I was able to also open in a hex editor (strings like 'FILE0', unicode strings like 'S.E.C.U.R.I.T.Y...L.O.G' and 'S.Y.S.T.E.M', plenty of what appeared to be isolated unicode backslashes).

From this, I hypothesize that the virtual hard drive code wrote some sector of the guest NTFS filesystem into the header part of the VDI file, possibly for reasons relating to pausing and resuming often, but just as probably for other reasons entirely.

The first 128 KiB (0x20000) of the VDI file is attached to this ticket.

It might be relevant to note that this was a 20.0 GiB dynamic VDI file, connected to a SATA controller in the VM, with the SSD mode turned on. The guest drivers were installed on the guest at the time of the failure.

Fortunately, I didn't lose any important data (I was not yet finished installing and updating the guest operating system and the purpose of the VM was to be a driver development testbed/debugging environment anyway). However, I think this bug deserves a close look because of just how fatal it could be.

[Justin Gottula]

First 128 KiB of the offending VDI file.

[Justin Gottula]

VirtualBox log file of the boot when the error happened.

[Ingo]

Probably this bug report ​http://www.virtualbox.org/ticket/9427 is somehow related?

If you asume that pausing a VM is equivalent to suspending the host while VM running. I did not examine the *.vdi files, as there are are 3 differential images and the base *.vdi attached immutable is not altered (a unchanged copy of the one still in use in VBox 4.0.4).

[aeichner]

Closing as obsolete, please reopen if still relevant with the most recent VirtualBox release.