2019 16" MBP running 10.15.4. WindowServer is eating a lot of CPU, idling at 10-20%-ish even with nothing much running. Fans are constantly going because of it.

I've disabled transparency and stopped (virtual) screens having their own spaces (as recommended elsewhere), to no avail. Also tried killing random things to see if anything sorts it out - no luck.

Running log stream --predicate '(process == "WindowServer")' --debug I can see it's dumping the following into its debug logs very frequently, 10+ times per second, which seems like it may be related:

2020-05-06 23:54:23.680073+0100 0x4e7 Debug 0x0 228 0 WindowServer: (CoreDisplay) [com.apple.CoreDisplay:default] [DEBUG] - On display 0x2b287853, surface is not detached, CoreDisplay is detached (0x00000000), DetachCode = 0

Any ideas what's going on?

Edit: as someone asked: The screens I was referring to are virtual screens. I do have an external monitor, but this still happens with it detached.

  • Does quitting Safari help? It seems to, for me. (Just as a test; of course Safari is a pretty essential app to have open most of the time.)
    – tml
    Commented May 9, 2020 at 21:23
  • @tml Nope. Tried killing things randomly, tried no browser running, no matter what happens WindowServer will eat a fair bit of CPU.
    – Dan
    Commented May 11, 2020 at 0:01
  • 1
    What if you kill Finder? I've occasionally seen Finder windows and/or the desktop itself be the culprit for such things.CMD-OPT-ESC won't do it. In Terminal do this: defaults write com.apple.finder QuitMenuItem -bool true. Then: killall Finder. Note the Finder menu now has a Quit option in it. You can reverse that by changing the "true" to "false" in the first command. Commented May 17, 2020 at 15:34
  • 1
    Based on this discussion, I turned off logging like sudo log config --process=$(pgrep WindowServer) --mode "level:off". Logging has stopped, but the CPU usage of WindowServer remains at 30%.
    – jolvi
    Commented May 21, 2020 at 10:44
  • 2
    I also get it when I have no monitors plugged in. And when I plug in my second monitor, I get it twice as much with WindowServer CPU increasing accordingly.
    – Hari Honor
    Commented Aug 10, 2020 at 8:11

8 Answers 8


I have DELL UP3216Q external monitor. I had the same problem with "surface is not detached, CoreDisplay is detached" errors being spammed when I run log stream --predicate '(process == "WindowServer")' --debug. I'm using the external monitor with the Mac lid closed.

The errors stopped when I changed System Preferences > Displays > Display scaling settings so that scaling is not maximum on the external monitor. If I change the scaling back to maximum (more space) the errors start again on logging mode.

WindowServer CPU use was reduced slightly, but it is still around 30 %. Atleast the fan stopped spinning so fast.

  • 1
    Could this be because Mac uses some virtual display tech to render the screen? Looks like that also some of the lower resolution modes causes Mac to report errors. Check out the right setting for your monitor by starting the log and then changing scaling on your system.
    – Jari
    Commented May 26, 2020 at 13:18
  • 1
    I don't think it's to do with the resolution specifically, any non-HiDPI resolution seems to cause the problem. Using SetResX I'm able to select a HiDPI resolution that matches the monitor's native res and eliminate the errors.
    – Dan
    Commented Aug 15, 2020 at 12:13
  • Max resolution is already 1080p, so...
    – fuat
    Commented Feb 26, 2021 at 14:10
  • I have the issue on my MBP without external monitors. It goes away only when I choose "Scaled" and higher than default (so out of 5 levels that are available #4 and #5 work). If it's default or below default, I'm getting the debug message. Commented Mar 24, 2022 at 23:01

Try https://chromeisbad.com/. In my case Google Chrome was the issue and uninstalling it (and, most important, Keystone) solved all my problems.

  • 2
    Just deleted Chrome/Keystone this morning and first impressions are that things are... better. WindowServer certainly peaks still, but it seems to settle down to ~5% CPU which it wasn't doing before. I'll reserve judgement until I've put a day's work through it but this might be the problem...!
    – Dan
    Commented Mar 17, 2021 at 10:03
  • 2
    Hm. Encouraging results to begin with, but after uninstalling Chrome and working with Firefox for a day... Not significantly better.
    – Dan
    Commented Mar 18, 2021 at 1:11
  • Also seeing improvement. The machine is cooler than before when idle, but still pretty warm. WindowServer still sits at around 7% usage. surface is not detached is still there in the logs. Commented Mar 24, 2022 at 20:54

Answering my own question with what I've learned:

  • HiDPI resolutions eliminate the error message from the logs. SetResX has a HiDPI resolution for my monitor's native res - using that looks the same as the "more space" scaling, but without the errors. This reduces CPU use and heat a bit.

  • As dumb as it sounds, "clamshell mode" (ie, shutting the lid) helps quite a bit. I guess it helps not having to render the built-in screen

WindowServer is still using quite a bit more CPU than I'd like, but those two things have reduced it a fair bit.

Other things that I've seen others have success with but haven't been able to confirm myself: Using charging ports on the right rather than left reduces heat, and tweaking refresh rates by as little as 0.1Hz has dramatically reduces energy usage for some people.

EDIT: Clamshell mode seems to let me use the monitor's native res without using SetResX without causing the errors. I think this is down to having the machine render standard and HiDPI resolutions at the same time.

  • 2
    Having read this I just switched my USB cable from left side to right, and saw an immediate drop in CPU usage from 30% to 10%. And that's even with the surface is not detached debug logs still streaming by (I don't like any of the other res options, and haven't yet installed SetResX to get deep into it). Thanks!
    – John Hart
    Commented Aug 17, 2020 at 16:37
  • @JohnHart Interesting. That made zero difference for me, but I'm glad it's helped you!
    – Dan
    Commented Aug 17, 2020 at 18:00
  • My issue is definitely with the built-in screen, but clamshell didn't help. Only setting scale on main screen to something above default makes the debug message go away. Commented Mar 24, 2022 at 23:03

I, too, have run into consistently high WindowServer CPU usage since upgrading to Big Sur (a few weeks ago).

After upgrading to Big Sur I ran into generally sluggish window management / movement, and macOS feeling like it was "very tired", and have looked for answers for some time. Today things got really slow, with missed keystrokes while typing into iTerm, and WindowServer CPU usage running at 95% consistently. Reboots "solved" the problem for a while, but always after a short time things got slow again.

Then I found this article and the link to "Chrome is Bad". I followed the instructions (in Chrome is Bad) to remove Chrome and Keystone to the letter, rebooted, and switched to Brave.

The difference is literally night and day. Switching between apps / windows is now, once again, snappy. No more dropped keystrokes in iTerm and other apps. Moving windows from the internal display to my external (4K Dell) monitor is smooth as butter, where before it would become jerky as windows moved onto the external display.

I am still struggling to believe that Chrome / Keystone are the culprits—since neither shows high CPU when the problems show themselves—but I am (very) happy with the result.

In short, it will take a great deal for me to switch back to Chrome now, especially since all of my Chrome extensions work flawlessly in Brave.


Macbook pro 2019 16 has a well-known problem regarding high CPU/GPU usage when external displays are connected (See related thread here). The problem is due to the fact that external display connection is hard-wired to external GPU. If you are using the computer with external displays attached, you can test to see if the problem continues when you detach all external displays.

Additionally, you can try to set the screen resolution to default if you are using one of the scaled modes. It is also well known that the scaled resolutions in MacOS tasks the CPU and GPU considerably.

  • 2
    Still happens with external displays disconnected. Non-scaled modes do reduce CPU usage a bit, but not enough to make the difference - it's still hammering the CPU enough that the fans are making a lot of noise even when idle.
    – Dan
    Commented May 24, 2020 at 15:43
  • 1
    Can you also try to setting the screen resolution to exact pixel doubled scaling? I believe it should be the "looks like 1536x960 option". This will rule out the scaling algorithm. Commented May 24, 2020 at 15:45
  • 1
    I tried all resolutions and scaling options but the CPU usage stayed the same. I suspect it has something to do with the temperature since I never noticed an issue until August, when the temperature has stayed constantly above 30 Celsius. Still this should be a completely normal temperature range that a €3000+ laptop should be able to handle. Really frustrating.
    – xji
    Commented Aug 13, 2020 at 21:25
  • Thanks for the thread. With such a huge amount of replies it's clear that this has been an issue for quite a while and is likely caused by inadequate cooling for the heat produced by the CPU + dGPU combined. Using an eGPU apparently would solve it but feels like such an overkill. Having good ventilation (maybe even with a desktop fan) seems to help but it can only do so much.
    – xji
    Commented Aug 13, 2020 at 21:50
  • @AlperKocatas I'm sorry it's taken me so long to respond. Turns out when connected to an external monitor, if I select the "looks like 3200x1333" option, CPU usage is quite a lot more reasonable, and the log entries stop... Thank you!
    – Dan
    Commented Aug 14, 2020 at 22:28

I'm facing this too with messages like surface is not detached, CoreDisplay is detached for every screen I have connected, clam shelling didn't have a visible affect.

What did have an affect:

  1. Firefox 84.0.2, seems to have a significant change when I close it and open it (with 17 windows and probably 2-10 tabs each, I know it's a problem...).
  2. iTerm2 had the status bar on with many windows open too each with a status bar that was indicating Git Branch/CPU%/MEM%/Battery/etc. Disabling the status bar had the biggest effect on the WindowServer process.

13" MBP 2016, on Big Sur

  • That iTerm thing is interesting, I basically always have it running (although not with the status bar)...
    – Dan
    Commented Jan 26, 2021 at 22:47
  • @Dan, the problem persists but more reasonable CPU% <50% normally and sometimes as low as 2%, that status bar had a huge role, I saw a couple GPU/kernel panics and before normally >100% and up to 850% CPU! Though wish I could find out more about surface is not detached, CoreDisplay is detached
    – joelpittet
    Commented Jan 28, 2021 at 0:57
  • For me iTerm was the culprit too. See the issue gitlab.com/gnachman/iterm2/-/issues/8640 Commented Jun 24, 2022 at 21:04

My problems were completely identical with OP's, and my logs were showing the exact same results as well.

I tried many things to work this one out from my research on the Internet, but no luck.

In my case the issue was resolved by changing the refresh rate from 75Hz to 60Hz. I don't know the reason but it is magically decreased as soon as I did that. CPU usage is better than ever, no fan noise which was the most problematic issue for me. Also, changing Displays > Color > Display Profile from PHL245E1 to SD170M-A might have helped as well, but after I changed it back to HD one, no significant CPU increase or fan noise detected. Btw, I realized that the Color profiles have HD and SD modes, and in my case PHL245E1 profile is HD one while SD170M-A is, well, obviously the SD one. If someone has a 4K monitor and having issues like this, it might be of help checking these settings as well.

My system properties is like beloew btw:

  • MacBook Pro 15 Inch, 2019
  • macOS BigSur v11.3.1
  • External monitor: Philips 245E QHD

If there is anyone having the same issue and resolved it like this knows the real reason why, I'd love to hear that.


Sounds ridiculous, but try cleaning the trackpad on your laptop.

It appears dust and debris can cause WindowServer to spend lots of CPU time processing what it thinks is motion on the trackpad just to determine it needs to ignore it.

Here's what my log stream --predicate '(process == "WindowServer")' --debug showed, with tons and tons of messages about ignoring motion and MTHandMotion::resetHandMotion

2024-05-16 12:09:35.474731-0700 0x9b977b   Debug       0x0                  391    0    WindowServer: (MultitouchHID) [com.apple.Multitouch:Plugin]     DHML:  P7 Identity=7 <- 7 (ignoring motion)
2024-05-16 12:09:35.474760-0700 0x9b977b   Debug       0x0                  391    0    WindowServer: (MultitouchHID) [com.apple.Multitouch:Plugin]     DHML:  MTHandMotion::resetHandMotion(0)

As soon as I dusted off the trackpad, the log messages disappeared and so did my high CPU (WindowServer down from over 50% to 7% on an M1 Pro).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .