Repeated Corrupt Parallels .PVM file

I have seen the exact same issue, just happened again this week, Disk Utility sees an issue in that file (and a file copy isn't able to complete once it's in that state) but Disk Utility isn't able to repair (even when Mac booted to Repair mode), only fix I've seen is to kill/restore the PVM, I also do a reformat of the SSD but don't think it's necessary.

My guess is that it's an edgecase Mac filesystem bug exposed through how Parallels does PVM, perhaps related to Win10 disk mgmt that does interesting things under the covers (defrag etc. is now all hidden and happens behind the scenes).

Similar specs (Parallels 14.1.2, Win10, Mojave (currently 10.14.3), also 500G 16GB Macbook Pro Retina 15 but mine is a late 2013.

TLDR;

In case anyone else runs into this issue, I appear to have been able to fix it AND save my VM:

• Copy the .hds disk image (inside the .hdd bundle inside the .pvm bundle) to another drive using the dd command with Terminal

Copying via the Finder fails as described above. It still works after copying it back to the internal SSD.

I had the EXACT same problem, right down to trying to copy my VM to an external disk (to see if it was an SSD error) and getting the 100034 error and needing to reboot twice to get Parallels to launch. I came across this post by googling that error code.

I have iStat menus and observed that frequently, while using my VM - I'm not sure of the trigger prl_disp_service would peg at 30MB/s disk read; this was when everything went to hell. My Mac host OS would go from sluggish (blocking on disk IO?) to frozen altogether. Killing prl_disp_service wouldn't clear the 30MB/s read, it would just move it to kernel_task or hide its source altogether. CPU for prl_disp_service was slightly elevated but nowhere near pegged. Also, 30MB/s is nowhere near pegged for disk I/O either.

After (stupidly) trying to reclaim disk space so I could move my VM to an external drive - and having the disk reclaimer fail with the same 30MB/s lockup and system fault, ultimately freezing the entire host OS - I could no longer start my VM at all. No reports of corruption, just the same hangup. But the disk resizer is a different process and Windows is not running.

I would also add that the failure of Parallels to launch after the first reboot was the Parallels application, not the virtual machine. But maybe it does some scan or something if it was force-quit while a VM was running that triggered the issue?

I'm not sure what the root cause is, but I suspect Jim hit the nail on the head: that it's Parallels exposing some bug in the file system. Maybe resulting from the switch to APFS? I would further speculate that it may have been related to expanding the disk image size. The issue started after a Windows update, but I had also just installed SolidWorks, and had recently updated Parallels from 15.1.4 to 15.1.5. At first rolling back to 15.1.4 seemed to fix the problem - or at least cause it to recover sometimes - but it quickly became unusable.

Macbook Pro (Retina, 15-inch, Mid 2015)
MacOS Mojave 10.14.6
Parallels 15.1.4 or 15.1.5
Windows 10 19042.928

I have encountered this issue several times over the years. Sometimes, it can be fixed by right-clicking on the PVM file and selecting “Show Package Contents,” then right-clicking the .hdd file and selecting “Get Info.” Scroll down to ”Sharing & Permissions.”

If the staff permission is “No Access”, change it to “Read & Write”. All users who should have access to the Windows file should be “Read & Write”.

You may need to enter an Admin password to authenticate. (Parallels should of course not be running when you do this, and you should reboot afterwards)

This doesn’t always work for me, but it has helped enough to be a good tip.