Need to see a directory listing of the files that comprise the VM showing filename, filesize and date/time stamp. Do this in a Command Prompt and redirect the output to a text file. Then archive (compress) the filelist.txt file and all vmware*.log files in the VM's folder and any VMware related logs in the %TEMP% folder into a single .zip archive and attach it to a reply.
In a Command Prompt change to the VM's directory and use the following command:
dir /oen > filelist.txt
BTW So there is no confusion with the information I'm going to present, "slices" is not the correct term, the binary portion of the virtual hard disk is called an "extent" or the plural is "extents". 
I guess the user has not been maintaining proper backups!?
Understand that there are no substitutes for maintaining proper backups and in a case such as this if there is some mission critical data on the virtual hard disk that really needs to be recovered then what I'm presenting is in some way a last ditch effort and I have done this in the past for other uses mainly just to attempt to recover data not necessarily have a working VM again. This has had mixed results in the past, in other words to the point all data is recovered or some data or no data. I have users be able to completely repair the VM however this is usually when an empty extent was corrupt and replaced by another empty non-corrupt extent. The bottom line is it's just going to depend on which extent is corrupt and how corrupted it is. As an example, if it's the extent containing the MFT of the NTFS Filesystem then that will not be good! 
Hopefully what I will find in one of the logs is an error pointing to the corrupt extent and will only have to try swapping out that extent in an attempt to mount the disk for data recovery. Otherwise it will need to be done in a round-robin fashion. This will also assume that the Disk DescriptorFile and the first and last extent are not corrupt and more on that later after I review the requested information.