virtualbox.org

Just surrendered to the nagging, and updated to the latest, including extension pack. Now my VM won't boot. Running Win10Pro host, Win7Pro guest, using raw physical disk rather than virtual disk. The error pop-up says under Details:

Could not open the medium 'C:\Users\PAULD\VirtualBox VMs\PAULD\PAULD-C.vmdk'.
VD: error VERR_ACCESS_DENIED opening image file 'C:\Users\PAULD\VirtualBox VMs\PAULD\PAULD-C.vmdk' (VERR_ACCESS_DENIED).

The entire contents of the VBox.log is:

00:00:02.465928 VirtualBox VM 6.1.22 r144080 win.amd64 (Apr 28 2021 17:23:11) release log
00:00:02.465932 Log opened 2021-05-10T05:21:45.088035400Z
00:00:02.465932 Build Type: release
00:00:02.465934 OS Product: Windows 10
00:00:02.465935 OS Release: 10.0.19042
00:00:02.465936 OS Service Pack:
00:00:02.533105 DMI Product Name: Alienware m17 R3
00:00:02.535863 DMI Product Version: 1.8.0
00:00:02.535867 Firmware type: UEFI
00:00:02.536096 Secure Boot: VERR_PRIVILEGE_NOT_HELD
00:00:02.536103 Host RAM: 32496MB (31.7GB) total, 22774MB (22.2GB) available
00:00:02.536106 Executable: C:\Program Files\Oracle\VirtualBox\VirtualBoxVM.exe
00:00:02.536106 Process ID: 21404
00:00:02.536106 Package type: WINDOWS_64BITS_GENERIC
00:00:02.536638 Installed Extension Packs:
00:00:02.536652 Oracle VM VirtualBox Extension Pack (Version: 6.1.22 r144080; VRDE Module: VBoxVRDP)
00:00:02.537270 Console: Machine state changed to 'Starting'
00:00:02.537384 Qt version: 5.6.2
00:00:02.538516 Console: Machine state changed to 'PoweredOff'
00:00:02.538987 GUI: UIMediumEnumerator: Medium-enumeration finished!
00:00:02.539117 GUI: Show mini-toolbar for window #0
00:00:02.540966 GUI: Adjust mini-toolbar for window #0
00:00:02.540982 GUI: Map mini-toolbar for window #0 to screen 0 of 1
00:00:02.540987 GUI: Resize mini-toolbar for window #0 to 1920x1080
00:00:02.548750 Power up failed (vrc=VINF_SUCCESS, rc=E_FAIL (0X80004005))
00:00:03.048991 GUI: Aborting startup due to power up progress issue detected...

I'm a little puzzled by the UEFI and Secure Boot error messages, since this is an old MSDOS format disk, and EFI isn't enabled in the VM.

I made sure the PhysicalDrive number hadn't changed, and made sure everything VirtualBox related had shut down. Nothing else changed other than the upgrade.

Those messages detail the host system, not what the VM uses. You can ignore these.

Raw Disk Access on a Windows host requires Virtualbox to be Run As Administrator, and the disk needs to be offline in Disk Management. Have either of these been skipped?

pderocco wrote:Just surrendered to the nagging

You can stop the nagging by turning off Update checks in the main Virtualbox window, File menu, Preferences, Update tab.

You can also roll back if you want to.

No, I'm running as admin, and the physical drive is offline. As I said, this was working fine before the upgrade.

VBox.log seems to be what is normally used to diagnose this sort of thing. If that should be "ignored" then all there is beyond that is VBoxHardening.log. I've attached this, in case it's helpful, but it's completely cryptic to me. I assume it could be relevant because it has roughly the same timestamp as VBox.log.

pderocco wrote:As I said

You did not state the procedure you used. And you may have forgot something. Thus my suggestion to check all steps. And I only asked if you skipped a step. VERR_ACCESS_DENIED for Raw Disk usually means the host OS won't let Virtualbox at the disk, usually because of not being Run As Administrator or the drive not being offline.

pderocco wrote:VBoxHardening.log ... completely cryptic to me.

Most of it is cryptic to us, too. The devs play those cards very close to the chest. However, if the log ends with "ExitCode=0x0", as yours does, then your host does not have hardening problems.

I do not know any other reason for VERR_ACCESS_DENIED than that the host is blocking Virtualbox from accessing the disk, or that the actual .vmdk is blocked.

Please downgrade back to the version you were using before, see if the VM immediately begins running again.

On a whim, I tried something simpler: I created a new .vmdk file for the disk. And it worked. When I compared the two, the CID, ddb.uuid.image, and ddb.uuid.modification had all changed. Since this is an MBR disk which has no UUIDs, and the 8-digit serial number shown by diskpart doesn't match anything in this file, I suspect these are just random numbers generated when the .vmdk file is created. But none of the other parameters are different, and there was nothing wrong with the NTFS permissions on the old file. I don't know why it suddenly decided not to like the old .vmdk file, and likes this one. The error message doesn't seem to have been designed to be very useful. But I'm up and running again.

That's good news! Good to know, too. The .vmdk can go "bad", so to speak, if the host computer re-enumerates the drives. Checking the validity of the .vmdk would b a good idea.