WindowServer crashing repeatedly since upgrade to Ventura

I believe that the problem comes from the external screen when it is in "main display" and not in "extended display". Before the Ventura update it was in extended and it moved to main view with the update. Since I put it back in extended display, I no longer have windowServer crashes.

I saw a reddit thread that said that it was related to command-tab and apps running in full-screen mode. I have a 16" 2019 MBP (i9), and have stopped running any apps in full-screen mode. I haven't had a window server crash since then.

To coin a phrase from another post, I'm cautiously optimistic :-)

Here's a link to the thread: https://www.reddit.com/r/MacOS/comments/yczalk/ventura_random_window_server_crash/

It's happened consistently since I upgraded to Ventura (never happened before). It seems to happen ONLY when I run an app in full screen mode (I have two external monitors attached to my Mac mini 2018). It crashes everything except the Apple applications (Mail, Calendar) and locks the screen.

I avoided full screen apps for 3 or 4 days and had no issues. As soon as I went full screen with an app (not an Apple app), I crashed within 5 minutes.

The problem occurs in both 13.0 and 13.0.1.

I only started experiencing these WindowServer crashes on 13.0.1. Like the other reports, connecting to an external thunderbolt display seems to be a factor since I am not experiencing the issue using only my internal display or with an HDMI display on my MBP M1 16" (it has a HDMI port).

However, I CAN make it happen on command. When using my thunderbolt LG external display the WindowServer only crashes when I use the ⌘+tab shortcut to switch apps.

I had the same crashes, but currently it seems to run stable again.

For me, I think the trick was to switch off AMD FreeSync in the settings of my screens.

I also noted, that with other screens I didn't have such problems.

So my guess is some screens might have features leading to the crashes we observed.

No. Have you installed and run any "cleaning", "optimizing", "speed-up", anti-virus or VPN apps on your Mac?

Give this a try: boot into Safe Mode according to How to use safe mode on your Mac and test to see if the problem persists. Reboot normally and test again.

NOTE 1: Safe Mode boot can take up to 3 - 5 minutes as it's doing the following; 

• Verifies your startup disk and attempts to repair directory issues, if needed

• Loads only required kernel extensions (prevents 3rd party kernel/extensions from loading)

• Prevents Startup Items and Login Items from opening automatically

• Disables user-installed fonts 

• Deletes font caches, kernel cache, and other system cache files

NOTE 2: if you have a wireless keyboard with rechargeable batteries connect it with its charging cable before booting into Safe Mode. This makes it act as a wired keyboard as will insure a successful boot into Safe Mode.

I have this issue as well, only on external monitor (HP in my case).

A possible workaround, which has worked for me so far (no crash in 2 weeks):

Enable "Displays have separate Spaces" in System Settings -> Desktop & Dock

I have the same 16 inch 2019 intel MacBook Pro and graphics processor. I have 2 Dell P Series 27 inch external monitors. I work from home and use Citrix to access my work system - it started crashing when I began working from home due to Covid and bought the dual monitor setup, so I’ve been assuming the Windowsserver crash reports were related to Citrix timing out due to inactivity frequently. I even reformatted my hard drive recently and did a clean install on everything.

My monitors are connected to my CalDigit TS3 Plus Thunderbolt 3 Dock - 87W Charging, 7X USB 3.1 Ports, USB-C Gen 2, DisplayPort, UHS-II SD Card Slot, Gigabit Ethernet for Mac & PC, Thunderbolt 4 Compatible (0.8m/2.62ft Cable). One monitor was connected to the dock via the Display port. The other was connected to a Thunderbolt port on the dock via USB-C cable. After reading all these comments yesterday I unplugged the USB-C cable from my left external display and plugged it in directly to my MacBook Pro USB-C port on the right hand side.

where I would usually have 3 or 4 crashes per day with the Windowsserver error report, I’ve not had one crash since plugging my external display to my MacBook Pro directly. Crossing my fingers this is all the fix I need and hope this information helps everyone else.

Solution: change the color profiles of both internal and external monitors to their DEFAULT ones.

It has been over 4 days, and not been a single crash!!!

This was fixed for me in 13.1. Hasn't happened once since I took the update.

I have been having different flavors of the WindowServer crashes with both 13.0 and 13.0.1. To be honest I think that the patch has made the issue even worse!

In general I get about 10 crashes a day, although they are not all from WindowServer. Docker Desktop Helper (Renderer) also crashes regularly despite updating to the latest version.

Here is my setup:

• MacBook Pro 2019
• Dell P2421D external monitor
• Initial connection: generic active USB-C to HDMI cable
• Current connection: Apple USB-C Digital AV Multiport Adapter + HDMI cable (with Ethernet)

What works:

• Just using the Mac seems to do the trick.
• Using the external monitor only, regardless if I use full screen apps or any number of browsers/code editors...

Patterns that I identified:

• when using the USB-C cable it used to crash even when closing the lid.
• using the apple AV adapter looked to have solved it, but clearly not for long.
• since 13.0.1, when coming back from sleep the os would try to restore the desktops or reconnect the external display, but it gets stuck in what looks like an infinite loop flickering the displays on/off alternatively. This did not lead to any crashes.. so nothing to send to Apple.
• in most cases the crashes happen when switching tabs with cmd+tab.

Crash frequency: It varies wildly, sometimes 3 times in a minute, sometimes after an hour or so.

Crash flavors:

1. I have 2 of these although they seem to crash at a different point in the execution stack.

Crashed Thread:        13  com.apple.windowserver.root_queue  Dispatch queue: com.apple.coreanimation.mtl_dealloc

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)

2.

Crashed Thread:        0  ws_main_thread  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)

3. this one looks different, could not get the exact thread that cause the crash.

"exception" : {"codes":"0x0000000000000000, 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":"SIGABRT"},

4. another one that looks completely different

"exception" : {"codes":"0x0000000000000001, 0x0000000000000000","rawCodes":[1,0],"type":"EXC_BAD_ACCESS","signal":"SIGSEGV","subtype":"KERN_INVALID_ADDRESS at 0x0000000000000000"},
  "termination" : {"flags":0,"code":11,"namespace":"SIGNAL","indicator":"Segmentation fault: 11","byProc":"exc handler","byPid":8022},

A couple of days ago, I hypothesized that the crashes are caused by some sort of race condition: for example, some in-memory structure gets used before it's fully constructed. And based on the evidence, it seems that the condition happens when switching apps on an external monitor. I'm not completely sure, but I think the condition also might depend on switching desktops.

To test this, I've modified my behavior a bit for the past couple of days. Instead of switching apps as fast as I like, when I use command-tab, I choose the app that I want, then I hold it for a moment to make sure all displays on my current desktop are fully updated. Then I let go.

So far, no crashes.

This might be interesting as a workaround and as a diagnostic observation. I can't claim that this is real cause and effect and don't want to create a superstition :) but thought I'd share here, since we're grasping at straws.

FTR: I'm still on 13.0.1. (At time of writing, there is no 13.0.2.)

I've had no crashes since I wrote that three days ago, and have been using my machine heavily with external monitors. I'm getting more and more confident in the race-condition theory.

On a practical level, it means using command-tab slowly, as I described above: "I hold it for a moment to make sure all displays on my current desktop are fully updated. Then I let go."