The timestamp of the ctk.vmdk is not fully readable but it looks like you have an automatic backuptool (Veeam or similar ...)
that is actively monitoring all VMs or only those that are part of an active job.
So I would check if any backup-appliance still has that vmdk mounted.
Try to resolve that problem first.
Remove the VM from inventory - close datastorebrowser.
Check if other hosts still list that VM.
Open diskmanagement inside the backup-appliance and check if your vmdk is listed.
Check the VM-configuration if your vmdk is attached.
Check the backuptool for active jobs and check if the VM is part of any.
When you are sure there is no problem from that direction
check the vmx-file of the powered off VM.
If not already done remove the VM from inventory and then doubleclick the vmx in winscp.
Search for ctk-parameters and remove them.
There should be one per vmdk and one global:
ctkEnabled = "true"
scsi0:0.ctkEnabled = "true"
scsi0:1.ctkEnabled = "true"
Next edit/check all vmdk descriptors that are referenced in the vmx-file.
If version is not set to 1 and instead uses 2 or 3 assume that a backuptool uses change-block-tracking.
version=3
Search for
# Change Tracking File
changeTrackPath="whatever-ctk.vmdk"
and delete both lines.
Search for
ddb.deletable = "true"
and remove the line if it exists.
If the vmx-file references snapshots open all descriptors that are listed and also follow the parentfile name hints.
Save all vmdk-descriptor-files and the vmx.
Seach in winscp for ctk-vmdk files and delete/ or rename them.
None of the involved vmdks, vmx and vmsd-files should have active references to any ctk-files now.
Via putty run lsof and grep for the vmdk-name.
If lsof has no match - open Datastorebrowser again and re-add the VM to the inventory.
Try to start now.
If you still have problems try to power off the backup-appliance.
DISCLAIMER: this instructions assume that you use Winscp embedded editor for all edits of VM-config-files.
Never use Datastorebrowser while troubleshooting problems with VMs.
Ulli