virtualbox.org

After 4 days of testing Win10 and Vbox as well as rolling back to Win8.1 and Vbox 4.3.30 and again upgrading step by step to 5.0.1, I am now certain that 5.0.1 (beta) has messed up with the physical (raw) disk access. At least with my config, that is Win8.1 / 10 Hosts (same behaviour); LinuxMint16 guest.
At first I assumed it was a Win10 issue and in the Win10 Hosts Generic topic is some of the history (page 10 and further).
Rolling back to Win8.1 and 4.3.30 Vbox was again fine; upgr to 5.0.0 still fine; 5.0.1 both the 101957 or the 1020 version: read access errors.
Under 1957 I would receive an error message on the Vbox GUI, the 1020 never stops booting Linux but both log files show the same read error. (rc=VERR_ACCESS_DENIED and 'BLKCACHE_IOERR').
Pls let me know if I should report these beta related issues in another way than writing on the forum (couldnt find an alternative in the FAQ).

The errors happen during writes not reads. We introduced a mechanism in the current testbuilds which should prevent the problem of concurrent access we had reports for earlier where a VM wouldn't work if the host has the volume mounted. VBox now actively tries to unmount the volume and takes it offline to prevent concurrent access but for some reason this introduces the access denied errors during writes. Unfortunately I can't reproduce this with my tests on Windows 10 so far the changes just work as expected, in fact without the recent changes I'm running into the problems described above so they are definitely an improvement.
There is a public ticket about this issue (can't tell whether you or someone else created it), see https://www.virtualbox.org/ticket/14425. Would be great if we can continue there, I would require your exact storage setup as it appears in the Windows Disk management utility including the used filesystems, whether the disk use MBR or GPT partitioning so I can create a setup for testing as close as possible to yours. Having the raw vmdk descriptor files would be great too. You can attach everything to the public bug ticket.

Thanks, I will provide the details in the ticket; some vmdks were in the log files already (not all folders). BTW I just had the error (after some 10 minutes or so) in 5.0.0 again (downgraded to 4.3.30 then again upgraded to 5.0.0) so now suspect 5.0.0 as well. Although .. some left overs from the 5.0.1 uninstall? Are the raw disks vmdks specific to a release? It almost seems so. Anyway going back to 4.3.30 but the up/downgrade/create vmdk now is a matter of a few minutes. One gets experienced.