I had this problem while trying to boot my Arch Linux guest. It caused the VM screen to be completely black and consume 100% CPU. I could not even get into boot options or boot from a live ISO.
I wasn't aware of doing anything to cause it. I initially suspected a corporate security update or that Parallels had automatically updated, so it took me a while to find the actual cause. I could see nothing in the logs to give me any clue. It turned out the VM's NVRAM had somehow got corrupted. This is how I solved it:
- I renamed NVRAM.dat to NVRAM.dat.bak (this is found in the virtual machine package, e.g. ~/Parallels/Windows.pvm)
- I booted the VM, which caused a fresh NVRAM.dat file to be created
- I used an Arch Linux live CD to restore the UEFI entry in the NVRAM
- I rebooted the VM
Even though this is Linux, I'm not sure the problem is specific to Linux, so it might still be worth trying with Windows. I am not sure how you would go about restoring the UEFI entry for Microsoft Windows, though. The problem was a firmware issue, so it was happening before Linux had even booted. It's possible Linux caused the issue; however, usually Linux doesn't meddle with things like NVRAM without asking you first. It's still a mystery what caused this in the first place.
I hope someone else finds this information useful.
