Jeremy- i have the same problem= i tried to copy the files out of the PVM folder to an external drive, and they all were copied except the windows 7 hdd parallels image- it keeps crashing 2/3 through... did you ever find a solution? thanks Mike
Repeated Corrupt .PVM file
- Thread starter SkipH
- Start date
Maria@Parallels
Problem solver
Which version of Parallels Desktop and macOS are you using?
I'm running into the exact same issue. This is my bug report that I just filed today:
Ok so after filing this report and force rebooting my Mac, the PVM file is corrupted (100034). This is the umpteenth this has happened. I don't have a recent backup... so this means I get to spend my whole working day tomorrow on reinstalling everything. This is absolutely bananas!
Ok so after filing this report and force rebooting my Mac, the PVM file is corrupted (100034). This is the umpteenth this has happened. I don't have a recent backup... so this means I get to spend my whole working day tomorrow on reinstalling everything. This is absolutely bananas!
Well, I figured out some way to work around the error reading the hard disk file. Disk Utility won't fix anything, and the default copy provided by the OS will abort when it hit an error. However in this case we can use dd to make a copy of the hard disk file while ignoring the errors:
dd if=/Users/yourname/Documents/Parallels/xxx.pvm/something.hdd/something.hds of=/Volumes/New\ Volume/destination/copy.hds conv=noerror
conv=noerror means you will ignore the errors.
I assume from my experience that proceeding while ignoring errors won't cause any harm to the system, but that may not apply for every case, so do it at your own risk.
Then create a .pvm folder and copy everything except the hds file, so that the files resembles the ones in the original pvm.
Now you should be able to turn on the VM, though the os may not be able to boot because of corruption in HDS. You can try booting the system using a floppy disk mounted with Windows ISO. For example this one had a command-line and support of external hard disks so you can copy all the data that is accessible to a hard drive.
https://www.microsoft.com/en-US/software-download/windows10ISO
Now regarding the issue 100034, I believe is somehow OS specific and a search on internet didn't yield anything meaningful, and I believe it is not fixable in the near future. I would just let the corrupted.pvm file occupy in the faulty place on disk as a way to mitigate the damage.
dd if=/Users/yourname/Documents/Parallels/xxx.pvm/something.hdd/something.hds of=/Volumes/New\ Volume/destination/copy.hds conv=noerror
conv=noerror means you will ignore the errors.
I assume from my experience that proceeding while ignoring errors won't cause any harm to the system, but that may not apply for every case, so do it at your own risk.
Then create a .pvm folder and copy everything except the hds file, so that the files resembles the ones in the original pvm.
Now you should be able to turn on the VM, though the os may not be able to boot because of corruption in HDS. You can try booting the system using a floppy disk mounted with Windows ISO. For example this one had a command-line and support of external hard disks so you can copy all the data that is accessible to a hard drive.
https://www.microsoft.com/en-US/software-download/windows10ISO
Now regarding the issue 100034, I believe is somehow OS specific and a search on internet didn't yield anything meaningful, and I believe it is not fixable in the near future. I would just let the corrupted.pvm file occupy in the faulty place on disk as a way to mitigate the damage.
I forget to add the step of "copying the hds file you copied using dd to the pvm" and there is not a edit post button.
I also had this EXACT same issue as described in the initial post and actually independently discovered the same "dd" workaround (after many, many hours of frustration and panic). I came here looking to spread my wisdom and discovered there are no new ideas 
Also I could have saved myself hours...
For the Parallels team - first of all, this issue still exists in Parallels 15. Second, maybe these additional observations will help track down the problem.
I have iStat menus and observed that prl_disp_service would peg at 30MB/s disk read; this was when everything went to hell. Killing prl_disp_service wouldn't clear the 30MB/s read, it would just move it to kernel_task or hide its source from Activity Monitor/iStat altogether. CPU load for prl_disp_service was slightly elevated but nowhere near pegged. Also, 30MB/s is nowhere near pegged for disk I/O on my machine either. I tried capturing a problem report to submit to Parallels but it was unable to finish generating it.
After (stupidly) trying to reclaim disk space before moving 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 would speculate that the corruption may have resulted from expanding the disk image size. The issue started after (during?) a Windows update, but I had also just installed SolidWorks (many GB), and had recently updated parallels from 15.1.4 to 15.1.5. At first, rolling back to 15.1.4 seemed to help but it didn't last.
Macbook Pro (Retina, 15-inch, Mid 2015)
Mac OS Mojave 10.14.6
Parallels 15.1.4 or 15.1.5 (hangup/unresponsive Mac occurred on both)
Windows 10 19042.928
Also I could have saved myself hours...For the Parallels team - first of all, this issue still exists in Parallels 15. Second, maybe these additional observations will help track down the problem.
I have iStat menus and observed that prl_disp_service would peg at 30MB/s disk read; this was when everything went to hell. Killing prl_disp_service wouldn't clear the 30MB/s read, it would just move it to kernel_task or hide its source from Activity Monitor/iStat altogether. CPU load for prl_disp_service was slightly elevated but nowhere near pegged. Also, 30MB/s is nowhere near pegged for disk I/O on my machine either. I tried capturing a problem report to submit to Parallels but it was unable to finish generating it.
After (stupidly) trying to reclaim disk space before moving 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 would speculate that the corruption may have resulted from expanding the disk image size. The issue started after (during?) a Windows update, but I had also just installed SolidWorks (many GB), and had recently updated parallels from 15.1.4 to 15.1.5. At first, rolling back to 15.1.4 seemed to help but it didn't last.
Macbook Pro (Retina, 15-inch, Mid 2015)
Mac OS Mojave 10.14.6
Parallels 15.1.4 or 15.1.5 (hangup/unresponsive Mac occurred on both)
Windows 10 19042.928
I haven't trusted the automatic TRIM option for a while. I would disable it, then use the procedure below:
1. Periodically, check the space that can be reclaimed, and leave it alone until it hits an intolerable level.
2. When it hits that level, shut down both Windows and Parallels, and copy the entire .pvm somewhere for safe keeping.
3. Restart Parallels.
4. Click the Reclaim button on Configure -> General.
5. If this corrupts the existing .pvm, delete it and drag the copy back over to restore it.
This seems to be the only way to do this safely without losing anything.
1. Periodically, check the space that can be reclaimed, and leave it alone until it hits an intolerable level.
2. When it hits that level, shut down both Windows and Parallels, and copy the entire .pvm somewhere for safe keeping.
3. Restart Parallels.
4. Click the Reclaim button on Configure -> General.
5. If this corrupts the existing .pvm, delete it and drag the copy back over to restore it.
This seems to be the only way to do this safely without losing anything.
Thanks Mark. My VM has NVMe1 configured as the drive location, which apparently does not have the option to disable trim. Interestingly, it was not auto-trimming before - the aforementioned reclaiming of disk space was something I manually initiated, and even then only after the problem already existed. Interestingly it is auto-trimming now and the "Reclaim" button displays a dialog telling me that real-time optimization is enabled. It's possible the drive location changed to NVMe1 as a byproduct of moving the constituent components of the .pvm to my external drive and back; however, that seems unlikely and the "TRIM" option was never available to me (I had read that might be related to the issue) which strongly suggests the previous location was also NVMe1.
For what it's worth, this worked for me too. When I upgraded to a new Mac and restored the hard drive via Time Machine, my pvm would not boot Parallels 19. Somehow some of the hds files had been corrupted. I mounted the old machine's drive as an external volume, right-clicked the pvm file to "show package contents", similarly right-clicked into the hdd file, and restored the damaged hds files from the external drive using dd as described above.