Pv5 - prl_disp_service consuming 99% cpu

  • Thread starter Thread starter Parallels User
  • Start date Start date
Update on my Parallels 8 experience

Now that a month has gone by since I started using XP on Parallels 8, I wanted to post an update. But before I do, let me give some brief background. I had the prl_disp_service problem on my 10.6.8 MacBook Pro 5,5 when I was running Parallels 6; I'm now running Parallels 8. Since prl_disp_service is not active when Parallels 8 is off (it was active all the time under Parallels 6), I never have any problems when I'm not using Parallels 8. And so far, I have not had any problems when I am using it either.

I do have to add a disclaimer: I use Windows only when I want to print something (b/c my old printer is not compatible with OSX) or when I need to use some Windows-specific software. Thus, I seldom have Windows on for more than a few hours at a time. Maybe developers who have Parallels 8 on all the time have some problems with prl_disp_service; I don't know. But I haven't had that experience.

The only problem I've seen so far with Parallels 8 is scrolling. Sometimes the scrolling will get super jittery--to the point of being uncontrollable. It happens less often under WinXP than it did under Win8 Release Preview, but it still happens often enough to be irritating. I never had that problem with Parallels 6. Other than that, I have not had any problems with Parallels 8 or any problems in OSX caused by Parallels 8.
 
Last edited:
Having this issue with 9.0.24

44448256 submitted.

has anyone found a solution for this?

This is new for me. I didn't have this issue with previous versions of parallels.
 
thanks Ram,

That didn't do the trick.

This is a machine (mid-2010 MacBookPro6,2 Intel Core i7 2.66 GHz 8gig memory) that what was wiped clean, had OS X 10.9.3 installed and a clean install of Parallels 9. Previously I ran parallels 7 with OS X 10.7 without any problems.

I've tried turning off as many sharing features as I can thinking that might help reduce processing issues, but it hasn't.

If parallels is simply open with NO VM running, prl_disp_service chews up 100% cpu (or more) (bouncing between 70% and 101.3%).

What is this service doing?

I've set exclusions for parallels, the app, the vm, the main folders the vm shares with the mac, etc in MacAffee. No difference. I've completely turned MacAffee off - no difference. The same thing happens at work and at home (wired network and wireless).

What else can I try?
 
I'm very happy to find this forum, since I'm been suffering through this problem for years. I'm running 10.6.8 because my company runs some proprietary software that requires Rosetta. I'm using Parallels 6 to run my Windows software, and I routinely suffer the prl_dsp_service problem causing extremely high CPU temps.

Was there ever a fix released for this?
 
Well, I just ran into this and I think I have some clues. For me, when this occurs, it's related to my 2 external LG 4K monitors hooked up to my Mac Book Pro.

If I unplug both monitors, the spinning stops. Sometimes when I plug them back in it starts back. I just tried unplugging both and then removing power from them too and it stopped the spinning this time.

We'll see if that always works....
 
Just had this happen again and this fixed it:
1. Disconnect your external monitors from your computer.
2. Remove power from your external monitors (unplug them from power).
3. Restore power to your external monitors.
4. Plug your monitors back in.
Just worked for me w/ 2 external LG 4K monitors.
 
Well, the fix seems to work sometimes and not others. When I sample the prl_disp_service process, it is doing a lot of IOKit and XML work and it seems directly related to my external monitors.

Can @Ram@Parallels do something to help get this tracked down and fixed?
 
Well, this time the fix required powering down the laptop and powering down both external monitors. Then power on the laptop and then plug the monitors back in.

That finally settled it down.
 
Interestingly enough, I tracked it down this time to being caused by a Samsung Galaxy S6 being plugged in over USB.

Rebooting the phone settled it down this time.
 
So, I think this is the bottom line. If prl_disp_service starts consuming CPU, it appears to be reacting to a peripheral that is misbehaving and causing IOKit to report a lot of device activity that prl_disp_service is looking for and reacting to. So, take this approach:

1. Use Activity Monitor to run "Sample Process" on prl_disp_service
2. Check the resulting sample to see if the thread CDspHwMonitorThread is doing all of the work in a lot of IOKit calls.
3. If so, the likely cause is a misbehaving peripheral. Start unplugging all of your attached devices one at a time and see if one causes prl_disp_service to settle down. If none of them do, it might be a piece of builtin hardware. Do a full power off shutdown of your computer.
4. When you've identified the problem peripheral, reboot/power cycle it and plug it back in.
 
You must log in or register to reply here.
Back
Top