VirtualBox harddisk registry is corrupted

[Tom79]

On Windows10 hosts sometimes I get in a state where the VirtualBox harddisk registry is corrupted. In this state all VBoxManage commands fail with following error:
VBoxManage.exe: error: Failed to create the VirtualBox object!
VBoxManage.exe: error: Cannot register the hard disk 'C:\xyz.vmdk' {e71033b4-26d4-47bd-842c-903a9cf59b65} because a hard disk 'C:\xyz.vmdk' with UUID {b301353b-b126-4709-9091-1609da297756} already exists

Is there a way via VBoxManage (or via VBox interop dll) to get out of this state?
At the moment I use a manual workaround. From VirtualBox.xml I remove all <Harddisk> entries under <MediaRegistry\Harddisks> and restart the PC.

Generally I do all commands via VBoxManage. I use an own storage location for the image files (vmdk, vhd). But when I delete a VM the used image remains in list of harddisks, "VBoxManage.exe list hdds" shows still the unregistered image.
I suppose this could be the reason for the message "Cannot register the hard disk because a hard disk with UUID already exists".

Create a VM is done as follows:
VBoxManage.exe createvm --register --name "%VM_NAME%" --ostype Debian_64
VBoxManage.exe storageattach "%VM_NAME%" --storagectl flash --port 0 --device 0 --type hdd --medium "%VM_IMAGE%" --setuuid ""

Delete a VM is done as follows (the image should not be deleted):
VBoxManage.exe storageattach "%VM_NAME%" --storagectl flash --port 0 --device 0 --type hdd --medium none
VBoxManage.exe closemedium disk "%VM_IMAGE%"
VBoxManage.exe unregistervm "%VM_NAME%" --delete

For one image (eg. C:\xyz.vmdk) the Create-VM/Delete-VM is done multiple times, eg:
Create-VM with C:xyz.vmdk, start this VM, Delete-VM and then again Create-VM with C:xyz.vmdk, start this VM, Delete-VM.

When using the GUI "Oracle VM VirtualBox Manager / Manager for virtual media" with the "Remove" button the image disappears from output of "VBoxManage list hdds" output.

Generally it is no problem if the unregistered images remain in harddisk registry (output of VBoxManage list hdd) but as I mentioned sometimes my VirtualBox is fully damaged with the "harddisk UUID conflict".

I tried different VirtualBox version (6.1.20, 6.1.22, 6.1.24, 6.1.28).

[scottgus1]

Yes, if the drive file is still registered with Virtualbox, then you cannot register it again. And that means that VMs with the drive file won't register because the drive file is already registered.

So you have to change how you're driving Virtualbox so you don't trip up over this.

"Vboxmanage list hdds" will show what drive files are still registered in Virtualbox. There's also "Vboxmanage list dvds" and "Vboxmanage list floppies".

The output is:

UUID:           df575abc-4a34-497f-8280-36b7e43e9555
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       C:\Users\SnC\Virtualbox VMs\DOS\DOS-disk1.vdi
Storage format: VDI
Capacity:       2048 MBytes
Encryption:     disabled

This output, redirected to a file or a pipe, is parseable with a scripting language to see if your intended disk files are already registered. (Lines starting with UUID: or Location:, space-padded to the start of the data, data is the 17th character from the beginning of the line.) Or error-catch the error in the script.

[Tom79]

But why is an image still registered in VirtualBox when a "VBoxManage.exe closemedium disk "%PATH_TO_VM_IMAGE%"" is done?

I would expect that with "VBoxManage.exe closemedium disk "%PATH_TO_VM_IMAGE%"" an image gets "unregistered", so that it is not listed anymore in "VBoxManage list hdds".
Do I have to adapt the "closemedium" command? Or do I have to call the commands in an other order?

As I mentioned when using the GUI "Oracle VM VirtualBox Manager / Manager for virtual media" with the "Remove" button the image disappears from output of "VBoxManage list hdds" output.
What is done behind the "Remove" button in the GUI, is there a difference to the "VBoxManage.exe closemedium disk "%PATH_TO_VM_IMAGE%" command?

[mpack]

This is something I haven't done for a while, but in the past the background VBoxSVC had a memory of media even after that media was unregistered. You had you wait a while for the background task to unload itself after the last transaction was complete.

[fth0]

FWIW, when the last VirtualBox frontend (e.g. VirtualBox Manager, VBoxManage, ...) and the last VM have been terminated, the VBoxSVC process keeps running for 5 seconds.

[Tom79]

Ok, thanks for this information.

But I have 2 more questions:

A) How can I prevent or avoid that VirtualBox gets to the state "Failed to create the VirtualBox object! / Cannot register the hard disk because a hard disk with UUID already exists"?
Do I have to check registered hard disks by means of "VBoxManage list hdds" and if a hard disk "C:\xyz.vmdk" is already listed/registered then I may not register again a hard disk "C:\xyz.vmdk"?
Respectively do I have to check UUIDs from the hard disk listed by "VBoxManage list hdds" and the UUID of the hard disk which should be registered again / new?
I use the --setuuid "" option at VBoxManage.exe storageattach so I think I don't have to check the UUIDs.

B) Is there a possibility to recover VirtualBox from state "Failed to create the VirtualBox object! / Cannot register the hard disk because a hard disk with UUID already exists" automatically/programmatically, eg. by means of VBoxManage (or by VBox interop dll)?
Respectively what is the recommended way to recover from this state?

[mpack]

You need to give the background VBoxSVC task time to unload, that's all. That eliminates the problem, provided the same UUID or file path is not registered in multiple places.

Yes, VirtualBox also doesn't like it if the same path/filename is registered twice, even without a UUID clash. The cure is the same: make sure VBoxSVC can't still be running with a memory of the previous instance.

To be clear: there is no corruptable file on disk which holds the global media registry. The global registry is built in RAM, from the validated local registries of all registered VMs, by VBoxSVC when it starts up. Obviously this structure cannot persist after VBoxSVC unloads itself, nor can it be corrupted.