ColorSync hang in MacOS Tahoe 26.3.1 - solved by disabling colorsyncd and colorsync.useragent

[bdjben]

Issue: When turning on more than one virtual monitor in BetterDisplay 4.2.3 Build 48120 (and perhaps earlier versions as well), BetterDisplay freezes / hangs and colorsyncd and colorsync.useragent show extremely high CPU usage. It appears that colorsync profile synchronization, or the way BetterDisplay handles it, cause some sort of conflict that does not resolve, leading to high CPU usage by these two ColorSync processes and leading BetterDisplay to stop responding (including in the Activity Monitor).

Temporary fix: I have found that this can be fixed well by permanently disabling colorsyncd and colorsync.useragent with the commands below, and I don't experience any compromised functionality of BetterDisplay or of my system or other apps yet, but I suspect that some apps that rely on ColorSync might experience issues, so a better fix is likely in order at this time. In any event, the fix for now is to run the following two commands:

launchctl disable system/com.apple.colorsyncd
launchctl disable gui/$(id -u)/com.apple.colorsync.useragent

[waydabber]

Hmm. Interesting. I never saw this issue - can you give a bit more details about the setup, how virtual screens are configured and a bit more detail about the Mac?

The app does not do colorsync profile synchronization (it does list installed profiles for the app menu though). How many profiles do you have installed and are you using custom profiles?

[bdjben]

Thanks. A few more details.

First, I should clarify terminology: when I said “ColorSync synchronization,” I did not mean that BetterDisplay itself has a profile sync feature. I meant that the hang appeared to be in macOS ColorSync helper/cache/profile-enumeration activity. In the samples I took while it was frozen, BetterDisplay’s main thread was blocked under installed-profile/profile-cache querying, while colorsyncd and colorsync.useragent were consuming high CPU.

Setup:

• Mac: Mac mini, Mac16,10
• Chip: Apple M4, 10-core GPU / 10-core CPU, 16 GB RAM
• macOS: Tahoe 26.3.1
• BetterDisplay: currently 4.2.3 build 48120
• I also reproduced the same issue after downgrading to 4.1.1, so it does not seem specific to 4.2.3.

Physical display:

Virtual screens:

Currently, with the ColorSync services disabled, I can run multiple BetterDisplay virtual screens successfully. Current active setup is six virtual monitors and one plugged-in real HDTV. All are online, mirror off.

Reproduction pattern before disabling ColorSync:

• BetterDisplay launched normally.
• Creating virtual screen definitions did not itself trigger the hang.
• Connecting one virtual screen was fine.
• Connecting a second virtual screen triggered the freeze/hang.
• When the hang happened, BetterDisplay became not responding, and colorsyncd + colorsync.useragent used high CPU.
• Killing/disconnecting the second virtual screen usually allowed the system to settle back down.
• This reproduced with old virtual monitor names / monitors and with fresh ones I had never used before that had fresh UUIDs, so it did not appear to be tied to a particular display name or cached store of old monitors.
• I also removed old BetterDisplay prefs and old BetterDisplay-created ICC files, reinstalled, and reproduced again. So stale old profile files did not seem to be the whole cause.

Color profiles:

I am not intentionally using custom color profiles.

Current profile counts on the machine:

• /System/Library/ColorSync/Profiles: 14 ICC profiles, all standard Apple/system profiles such as sRGB, Display P3, Adobe RGB, Generic RGB, ITU-709, etc.
• /Library/ColorSync/Profiles: 8 ICC profiles total.
• ~/Library/ColorSync/Profiles: 0 profiles.

The only display-specific profile currently installed is:

• /Library/ColorSync/Profiles/Displays/SAMSUNG-[redacted].icc

That file is a small Apple/ColorSync display profile for the physical Samsung display. I do not currently have per-virtual-display ICC profiles installed; however, before disabling colorsyncd and colorsync.useragent, it seemed that creating new virtual displays would automatically trigger attempts to create new color profiles rather than using an existing color profile. After disabling them, BetterDisplay simply used one of the system default profiles, without any issues at all.

The other /Library/ColorSync/Profiles files are standard-looking effect profiles:

• Black & White.icc
• Blue Tone.icc
• Gray Tone.icc
• Lightness Decrease.icc
• Lightness Increase.icc
• Sepia Tone.icc
• WebSafeColors.icc

BetterDisplay color settings:

• allowColorManipulation = 0
• allowColorManipulationForAllDisplays = 0
• protectSDRProfile = 0
• protectHDRProfile = 0
• protectSDRColorMode = 0
• protectHDRColorMode = 0

Workaround state:

The workaround that made BetterDisplay stable was disabling both:

launchctl disable system/com.apple.colorsyncd
launchctl disable gui/$(id -u)/com.apple.colorsync.useragent

[waydabber]

Thank you. I will try to reproduce this issue.

[wajinshu11]

I experienced this bug today, the problem is it keeps rewriting the .icc of both physical monitor that I have.

It triggered when I start betterdisplay too. I can't click and type because it keeps writing those .icc. I seen the "date modified" keeps changing every 1 minute and hammering the cpu in the /Library/ColorSync/Profiles/Displays/

colorsyncd and colorsync.useragent is the culprit

I fixed it because of this thread:
https://www.reddit.com/r/MacOS/comments/1rlfe7r/fix_colorsync_deadlock_100_cpu_when_using_two/

The fixed on this thread did not worked for me.

Using the latest version too and same bug

[waydabber]

Ahh, so the problem is that multiple virtual screens have the same name/vendor, model ID and serial number? BetterDisplay tries to avoid that for virtual screens (it gives a random serial number and model id to make sure different UUIDs are generated), the probability of having a clash is astronomically low. You can check the identifiers under "Additional settings" for the virtual screens.

[waydabber]

(or maybe one of your virtual screen copies the identifiers of a real display?)

[wajinshu11]

Ahh, so the problem is that multiple virtual screens have the same name/vendor, model ID and serial number? BetterDisplay tries to avoid that for virtual screens (it gives a random serial number and model id to make sure different UUIDs are generated), the probability of having a clash is astronomically low. You can check the identifiers under "Additional settings" for the virtual screens.

Not the virtual, it's the 2 physical display, here's the screenshot

look at the time, that date modified is stopped because of the fixed on reddit, but it will push the time every 1 minute, no problem on virtual because I tested it on moonlight and it create tons of virtual display. The physical devices have problem

here's the screenshot with virtual display, look at the date modified, they didn't move like those 2 physical monitors.

[waydabber]

Oh, ok. But do you have multiple identical physical displays then?

[wajinshu11]

Oh, ok. But do you have multiple identical physical displays then?

yes, LG Ultrawide and AOC monitor, both 1080p.

My troubleshoot was that .icc don't rewrite when betterdisplay is closed or uninstall. That thread on reddit says it's on MACOS bug but based on my testing it always occur when I start betterdisplay.

Moonlight is the virtual only

I just leave it here if someone experience the same problem.

[waydabber]

Hmm. Two displays with the same resolution are not the same, so I think this problem is different than the one mentioned in the Reddit post. This can very well be a macOS bug but the cause may be different this time.

[waydabber]

I have some trouble reproducing this, colorsyncd just does not seem to be doing this on my setup. Maybe it's some macOS installation bug that happens sometimes (I suspect the Reddit poster might have something special going on as well - as many people run multi-monitor setups with similar displays and macOS should tolerate that obviously otherwise this would be a well known issue).

I'll move this to discussions for now as the steps required to fix the issue is useful + maybe someone else will experience the same and we can figure out what circumstances are required to reproduce this reliably.