Opened 13 years ago

Closed 8 years ago

#9410 closed defect (obsolete)

Strange VDI Corruption Incident

Reported by: Justin Gottula Owned by:
Component: virtual disk Version: VirtualBox 4.1.0
Keywords: corrupt vdi Cc:
Guest type: Windows Host type: Windows

Description (last modified by aeichner)

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.

Attachments (2)

vdi_128k.bin (128.0 KB ) - added by Justin Gottula 13 years ago.
First 128 KiB of the offending VDI file.
VBox.log (51.5 KB ) - added by Justin Gottula 13 years ago.
VirtualBox log file of the boot when the error happened.

Download all attachments as: .zip

Change History (4)

by Justin Gottula, 13 years ago

Attachment: vdi_128k.bin added

First 128 KiB of the offending VDI file.

by Justin Gottula, 13 years ago

Attachment: VBox.log added

VirtualBox log file of the boot when the error happened.

comment:1 by Ingo, 13 years ago

Probably this bug report 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).

comment:2 by aeichner, 8 years ago

Description: modified (diff)
Resolution: obsolete
Status: newclosed

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

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use