Pv5 - prl_disp_service consuming 99% cpu

  • Thread starter Thread starter Parallels User
  • Start date Start date
Hello.

Sorry for these issues. Could you please send us problem report (Help->Report a Problem) and post here it id. Also please check wwhether problem persists on host reboot.
 
Omen,
The CopyPasteTool.dll crash is known bug and it has been already fixed. This fix will be available in the next update of PD. The problem with 99% CPU consumed by prl_disp_service isn't connected with the CopyPasteTool crash and this bug will be investigated by our development team.
Sorry for inconvenience.
 
5 months later and this is still most definitely happening in the latest version of Parallels...

attachment.php


The Parallels app isn't even running anymore; it's been long closed by the time I took this screenshot.
 

Attachments

  • Picture 1.png
    Picture 1.png
    90.3 KB · Views: 390
I would like to suggest that you uninstall, restart the Mac, and then and re-install Parallels Desktop (reinstall using the latest version). The uninstaller will ask you whether you'd like to keep your VM files; say "yes". Hope that'll help.
 
actually pure Mac OS or even restart of Parallels Desktop services enough in order to resolve issue. Use follow steps in order to restart PD:

1. shutdown or suspend your Windows VM
2. open Terminal app (/Applications/Utilities/Terminal.app)
3. perform follow commands:
sudo launchctl stop com.parallels.desktop.launchdaemon
sudo launchctl start com.parallels.desktop.launchdaemon

It's known very rare case and we doesn't have solution for it yet - sorry for inconveniences.
 
Thanks sandro for reporting this solution. I was also experiencing this issue that prl_disp_service was consuming 99% of a cpu. Stopping and starting the launchd service as you suggested solved the problem, when even rebooting had not.

Version: 5.0.9370.589435
 
Thanks sandro for reporting this solution. I was also experiencing this issue that prl_disp_service was consuming 99% of a cpu. Stopping and starting the launchd service as you suggested solved the problem, when even rebooting had not.

Version: 5.0.9370.589435

I've written a service that stops the Launch Daemon, and another one that starts it up again.

Unzip the attached services (they're Automator services, so you can view them in Automator when you double-click them) and put them into your library's "Services" folder (~/Libary/Services). Then you can start and stop the dispatcher from your File>Services menu. Start the dispatcher before you launch Parallels, and stop it after you've quit Parallels. Don't stop the dispatcher while you're running Parallels or Parallels will crash.

Hope this helps
 

Attachments

I've written a service that stops the Launch Daemon, and another one that starts it up again.

Unzip the attached services (they're Automator services, so you can view them in Automator when you double-click them) and put them into your library's "Services" folder (~/Libary/Services). Then you can start and stop the dispatcher from your File>Services menu. Start the dispatcher before you launch Parallels, and stop it after you've quit Parallels. Don't stop the dispatcher while you're running Parallels or Parallels will crash.

Hope this helps

so, with parallels 6, i have the problem where prl_disp_service is hogging all of one CPU at 99% .

i tried these services as quoted, making certain to shutdown parallels first, but prl_disp_service was running at 99% still after the messages about this came up.
 
so, with parallels 6, i have the problem where prl_disp_service is hogging all of one CPU at 99% .

i tried these services as quoted, making certain to shutdown parallels first, but prl_disp_service was running at 99% still after the messages about this came up.

turns out the scripts contain an internal password. if changed, they work for parallels 6.
 
This is really annoying; I have NOT even ran Parallels since the last reboot, but every day or so that stupid process starts running and goes to 100% of CPU on one thread, and the only way to kill it is to go into activity monitor.

I should not have to go into terminal to kill a process (which I tried and it did not work). Please fix this, ASAP.
 
Yes,it will turn out the scripts contain an internal password,if changed, they work for parallels 6. I really prefer to parallel 6.
1.gif
 
This is really annoying; I have NOT even ran Parallels since the last reboot, but every day or so that stupid process starts running and goes to 100% of CPU on one thread, and the only way to kill it is to go into activity monitor.

I should not have to go into terminal to kill a process (which I tried and it did not work). Please fix this, ASAP.

If you have 100% reproduction of problem could you please do follow next time you'll face with it:

1. open Terminal app (/Applications/Utilities/Terminal)
2. perform follow command:
sudo killall -ABRT prl_disp_service
3. wait for a minute and perform next command:
prlsrvctl problem-report --send --stand-alone

Please post here report id which you'll see from utility output after problem will be sent.
 
Absolutely. The next time it happens I will do that.

For the record, I like Parallels, nice way to access the few windows programs I use.
 
3. wait for a minute and perform next command:
prlsrvctl problem-report --send --stand-alone

Please post here report id which you'll see from utility output after problem will be sent.

I'm not the original poster, but I just had the same problem today. Using --stand-alone didn't produce any output (and it'd return right away, so I guess it wasn't doing anything. But without --stand-alone, the output was:


% prlsrvctl problem-report --send
Operation progress 100%
The problem report was successfully sent with id: 9398469

Please let me know if you need more information from me. Thanks!
 
Me too

Came back to my laptop and found this service chewing up resources despite Parallels not running and not having been run at all recently. Submitted, id: 9416304
 
Back
Top