DeleteSnap ERROR with aRC=VBOX_E_FILE_ERROR (0x80bb0004)

[snoopy26]

I am running VBox 5.2.8 under fc26. When I tried to delete the oldest snapshot from my Guest Win10x64 it showed progress 4, 3, 2 minutes, but the all of a sudden the CPU consumption of all 4 cores went up and the Delete Snapshot ended with a dialog message "Callee RC: NS_ERROR_CALL_FAILED (0x800706BE)". In the VBoxSVC.log I found the last message:

00:11:03.872176 DeleteSnap ERROR [COM]: aRC=VBOX_E_FILE_ERROR (0x80bb0004) aIID={4afe423b-43e0-e9d0-82e8-ceb307940dda} aComponent={MediumWrap} aText={Could not merge the medium '/home/ksp/VB/Machines/Win10/Snapshots/{299f0e8c-9fca-4d32-be09-8e3201ee7117}.vdi' to '/home/ksp/VB/Machines/Win10/Win10-disk1.vdi' (VERR_INVALID_PARAMETER)}, preserve=true aResultDetail=0

The problem is reproduceable

[snoopy26]

VBoxSVC.log

[snoopy26]

selectorwindow.log

[ckujau]

Same here with VirtualBox 5.2.8 on a Fedora 27 desktop machine (x86-64) when trying to delete an old snapshot from a Windows 10 VM.[0]

$ vboxmanage snapshot win10 list
   Name: 2018-02-20.1 (UUID: 3a63610b-9431-4ab7-b3aa-21defbf2bcaa) *
   Description:
win10_32bit


$ time vboxmanage snapshot win10 delete 3a63610b-9431-4ab7-b3aa-21defbf2bcaa
Deleting snapshot '2018-02-20.1' (3a63610b-9431-4ab7-b3aa-21defbf2bcaa)
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...
Progress object failure: NS_ERROR_CALL_FAILED
VBoxManage: error: Snapshot operation failed
VBoxManage: error: Code NS_ERROR_CALL_FAILED (0x800706BE) - Call to remote object failed (extended info not available)
VBoxManage: error: Context: "RTEXITCODE handleSnapshot(HandlerArg*)" at line 539 of file VBoxManageSnapshot.cpp

real    0m36.941s
user    0m0.116s
sys     0m0.182s

There's a core dump too:

# gdb -c core.VBoxSVC.1000.ce7036263ed5438195ea376f6431b352.3353.1523694917000000 /usr/lib/virtualbox/VBoxSVC
(gdb) bt
#0  0x000000000052ab20 in std::__cxx11::_List_base<MediumLock, std::allocator<MediumLock> >::_M_clear() ()
#1  0x000000000052a3c3 in MediumLockList::Clear() ()
#2  0x000000000052a491 in MediumLockList::~MediumLockList() ()
#3  0x000000000050954d in Medium::i_cancelMergeTo(MediumLockList*, MediumLockList*) ()
#4  0x000000000054d45e in SessionMachine::i_cancelDeleteSnapshotMedium(ComObjPtr<Medium> const&, ComObjPtr<Medium> const&, MediumLockList*, bool, MediumLockList*, ComPtr<IToken> const&, com::Guid const&, com::Guid const&) ()
#5  0x0000000000553212 in SessionMachine::i_deleteSnapshotHandler(SessionMachine::DeleteSnapshotTask&) ()
#6  0x0000000000559315 in SessionMachine::DeleteSnapshotTask::handler() ()
#7  0x0000000000430f7a in ThreadTask::taskHandlerThreadProc(RTTHREADINT*, void*) ()
#8  0x00007f836728247c in rtThreadMain () from /usr/lib/virtualbox/VBoxRT.so
#9  0x00007f836731499c in rtThreadNativeMain(void*) () from /usr/lib/virtualbox/VBoxRT.so
#10 0x00007f836761c50b in start_thread () from /lib64/libpthread.so.0
#11 0x00007f836619b16f in clone () from /lib64/libc.so.6

[0] Not sure if this is relevant, but: this particular snapshot is called "win10_32bit" because back in February the VM was indeed a 32-bit Windows 10 VM, now it's a 64-bit Windows 10 VM ("GuestOS: Windows 2016 (64-bit)")