Virtual Box 5.1.18 corrupted vdi drives on Windows 10

[JohnP123]

I recently upgraded to VirtualBox 5.1.18r114002 and started a few Virtual Box Images which just worked fine under Virtual Box 5.0.32. However, after a restart the guest's Linux file system got corrupted. Too many multiply claimed blocks (fsock error and device no longer found). I also notices slower performance. HDD on the host is SATA. The guest uses a sata (AHCI) controller as well.

After digging around, I saw that there was a similar problem in 2012, so I decided to use the IDE Controller on the guest instead of the SATA controller. Corruption of file system no longer occurs. Problem fixed with a work- around but still thought this bug should be reported as I lost a few hours getting this to work.

[Socratis]

• You didn't mention your host. Windows is too generic. Even the build version matters.
• You didn't mention your guest. Linux is too generic. Even the kernel version matters.
• You didn't mention the similar problem from 2012. A reference thread in the forums or a ticket would help.
• You didn't include any VBox.log. Zipped first please. See "Create New Ticket".
• You didn't mention if these were warnings or errors.
• You didn't mention the exact error/warning message.
• You didn't mention if the workaround fixed the existing guest, or if you created a new guest from scratch which didn't show any errors after you've changed the controller to IDE.
• All of my Linux clients use a SATA controller, which is also the default for most of the guest, so it's not as widespread, otherwise most of the users would be affected. Something else must be going on.

[JohnP123]

Replying to socratis:

• You didn't mention your host. Windows is too generic. Even the build version matters.

John: Windows 10 Pro, Version 1607, OS Build 14393.969

• You didn't mention your guest. Linux is too generic. Even the kernel version matters.

John: Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux

• You didn't mention the similar problem from 2012. A reference thread in the forums or a ticket would help.

John: Irrelevant because file system corruption just happened again. Shut down the guest cleanly last night after 4 hours of working on it. Same problem even with IDE controller!

• You didn't include any VBox.log. Zipped first please. See "Create New Ticket".
• You didn't mention if these were warnings or errors.

John: There were no warnings or errors from VirtualBox. Occasionally, I do get errors Memory Access Violation from VBox on the Host but that didn't not occur this time.

• You didn't mention the exact error/warning message.

John: Error on file system: multiply claimed blocks. John: Additionally, fsck results in "device not found".

• You didn't mention if the workaround fixed the existing guest, or if you created a new guest from scratch which didn't show any errors after you've changed the controller to IDE.

John: As indicated above, this is now irrelevant. This time the problem occurred using the IDE controller.

• All of my Linux clients use a SATA controller, which is also the default for most of the guest, so it's not as widespread, otherwise most of the users would be affected.

Something else must be going on.

John: I doubt it. No disk errors on host. Checked with disk info, chkdsk and crystal hardware info (which is showing SMART info). No other errors on host. Only the guest file system is impacted. This also happened with older UBUNTU images that worked just fine with the previous version of Virtual Box. Now, these images are all corrupted thanks to VBox.

John: I did forget to mention that I am also using the VBox Extensions but I doubt it has anything to do with my problem.

[JohnP123]

John: And before I forget: VirtualBox Version 5.1.18r114002 (Qt5.6.2).

[Socratis]

So, the controller is out of the equation. Again, if this is reproducible in your case, please provide the exact steps to reproduce it. Full details.

Follow a "start the VM from cold-boot"/"observe error"/"shutdown the VM" cycle. With the VM shut down completely (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".

If it takes two runs of the VM to have the problem manifested (i.e. one run, the 2nd show the problem), then zip and attach both "VBox.log" and "VBox.log.1". Otherwise, just the "VBox.log".

[JohnP123]

Steps to reproduce:

• Create a new Virtual Box Machine,
• Settings: 2 CPUs, 8192 MB, Graphics 32 MB, 3 VDI drives on SATA Controller, bidirectional drag'n'drop/clipboard,
• Add netinstaller ISO image (Debian 8 64-bit),
• Start the Virtual Box,
• Run thru installer, use LVM with only the root VDI image,
• install the remainder of the system,
• reboot (which still worked),
• do some work (like apt-get ...) and reboot again and you run into trouble with the disk system.

Strangely enough I tested the same installer and an similar configuration on VMWare and it worked just fine. It would be nice if you could fix VBox. Used to be a good product.

A good engineer knows: Laissez faire won't fix it :)

[Frank Mehnert]

Please do also add a VBox.log file of such a VM session when the guest disk was corrupted. At the moment I suspect some problem with the host drive where the disk image is stored.

[Alex]

Unable to reproduce problem with the same setup. No errors after installing packages, copying files and reboot. Please attach VBox.log

[JohnP123]

I keep getting timeouts on that particular instance of the VM. Maybe, the whole problem has to do with the fact that the guest attempts to shut down and a timeout occurs. Just a guess. Attaching the VBox Logs.

I am also not sure what the following means:

00:00:02.326804 supR3HardenedErrorV: supR3HardenedScreenImage/NtCreateSection: rc=VERR_BAD_EXE_FORMAT fImage=1 fProtect=0x5 fAccess=0x2 \Device\HarddiskVolume2\Windows\System32\DriverStore\FileRepository\c0311199.inf_amd64_71ef621a77f87d8c\atikmdag.sys:

Is that related to a graphics driver?

[JohnP123]

You can close the defect. No longer reproducible with VirtualBox 5.1.20.

[Frank Mehnert]

Thanks for the information.