Let's have a look at the CID-chain stuff: the example you will see next is taken from some case I had in the german-forum recently.

The next 3 descriptorfiles are taken from a corrupt snapshot - the user had accidentaly moved the basedisk and had started it without the snapshots. He noticed the problem just in time and didn't do anything in the VM and powered it down at once.
He had used disks of type monolithic-sparse (one piece growing) - this made the whole think really tricky as we had to discuss this via posts in a forum.
I send him a little tool that I have made that can extract the descriptorfiles out of monolithic-sparse disks. The batch I told him to use produced this output:

When he had moved back the basedisk to the original directory VMware complained:
can't open snapshots because basedisk has been changed!

Let's find out how VMware noticed that ...
look at the descriptions of the snapshots: each of them has a line
parentFileNameHint = "path_to_parent" - this is used to find the parent-disk when VMware launches a vmx-file that has a snapshot as disk-reference.
This paths must point from child - child - .... - child - parent.

Check if this correct in this case:

yes - no problem.

Now every disk-description also uses two lines with CID-notes.
The CID is a random value that gets autocreated by VMware.
To check if any changes have been made to a parent - a child always notes the CID value of its parent.
If this is still the same next start everything is fine - if not all alarmbells ring.
Let's check this case:

the second child expects this value parentCID=06ebe4dc on his parent.

the first child has this CID=06ebe4dc and expects this parentCID=daf6cf10 on his parent

the parent has this CID=3160ee93

Noticed anything:

Yes - the CID of the parent-disk is not the one that was expected by the child.

So this snapshot chain is broken - you can not use it in a VM any longer.

Can we fix that?

That depends - if you have done no changes to the basedisk you may be lucky and come out with a disk that is clean and readable.
If you have done something like a defrag in the basedisk while you used it on its own the result can force a checkdisk at startup and can end with a complete data loss.

So whenever you do something like this don't panic - think twice before you do anything at all. First understand what has gone wrong!

Back to the example:
This is the repaired version that ||I send back to the poster. He had to use my tool again to inject the descriptors again.
Here is what I send him:

Looks almost identical - but I'm sure you will find what I have edited.