virtualbox.org

Hi,

suddenly one of my VirtualBox VMs won't start. It says:

Failed to open a session for the virtual machine <name>.
Sharing violation, file is being used by another process.
(VERR_SHARING_VIOLATION).

Details:
Result Code:
E_FAIL (0x80004005)
Component:
Console
Interface:
IConsole {1968b7d3-e3bf-4ceb-99e0-cb7c913317bb}

Rebooting the WIN7 host haven't solved the error.
File / Virtual Media Manager scans all files, but the one for this VM has a yellow Exclamation mark with no futher details.
I tried some of similiar answers from searching the forums here, but they are not working for me.

Log File of the startup is attached.

VBox.log wrote: 00:00:01.396 Executable: C:\Games\Oracle\VirtualBox\VirtualBox.exe

That is not the normal location for the VirtualBox executable. It implies that you may have been moving files around in unsual ways, which possible could explain the sharing violation.

The location was choosen at the time of installation and hasn't changed before or after the error.

Well, perhaps it would help if you were more specific, like telling me which file "the one for this VM" refers to, since VMs typically consist of several files. An exclamation mark in media manager usually means that the referenced file has been moved or deleted. It should be easy to confirm that the file exists, and also make sure it's in a folder accessible to the correct user, isn't marked read-only, and isn't locked for use by some other application (e.g. if it's an ISO, perhaps a virtual CD app).

The error message ultimately comes from the host OS, so I would look for obvious host OS issues.

The file i'm talking about is the vmdk file, which represents the hdd of that virtual machine.
From the error message i assume that another process is also accessing that file, but after reboots and restarts of the vm the error is still there.
vmdk files can be checked/repaired thru a program?

The vmdk file was placed on a network drive and the OS of that drive has made a media search at the drive.
After a reboot of that drive the lock was no longer at the vmdk file and the vmdk file could be loaded thru VirtualBox.
Problem solved.