MacBook Pro 13-inch (Intel) reboots with 'Windowserver' crash after installing macOS Tahoe and activating screensaver

emteeell wrote:

Yes I forgot to mention that I did also run the OS in safe mode and it made no difference. You may have seen that I also installed Tahoe on a new volume along with nothing else and the crashes kept coming. That should exclude the influence of the "old extensions" you mention. While I should probably do a bit of app housekeeping, some of those really old extensions may be being used by Parallels when I run Mojave in order to use some old software I still need.

Thank you.

FWIW, I think (though I don't have Parallels and have not emulated an older macOS) that it would make sense that, if needed, they would be installed within Mojave, and not for Parallels use in Tahoe. (I could be wrong, but I don't think I am).

When I was running Sequoia everything was fine. The problems coincided with the installation of Tahoe and they started immediately after doing so. When something goes wrong. My first question is always, "what changed in the meantime?".

This is a common argument. It can of course be a problem in Tahoe, but in many cases (not yours, apparently, since the problem persists in Safe Mode) it is a problem of old extensions that still worked in one OS but break in the new one. Again, by all indications, that is not the case here.

Ok, giving what you provided me a quick look, let's start with what kind of "crash" this appears to be.

The clues are:

• bug_type: "409"
• variant: "stackshot"
• termination: { "namespace": "WATCHDOG", "indicator": "monitoring timed out for service", "code": 1 }
• procName: "WindowServer"

That’s a *watchdog termination*, not a traditional crash. The system’s display watchdog monitors WindowServer; if WS doesn’t check in as “healthy” on time, the watchdog kills it and grabs a stackshot instead of a normal crash backtrace. That is, “WindowServer stopped making progress → watchdog killed it from the outside.” The “stackshot” variant clue is explicitly used for these “hung, not crashed” situations.

From the termination.details array:

• Display … not ready: DisplayID: 0x4280f40 → one display pipeline never reached the “ready” state.
• “On Glass SurfaceIDs: 4 12 2” with one Active and two Waiting → WS has a set of surfaces (windows/layers) whose transactions are stuck in flight to that display.

I'm assuming that there's only one monitored display here, so on a 16,2 with no external monitors this almost certainly corresponds to the internal panel. Ok, so what does that meam? Basically that the internal display’s on-glass pipeline is wedged: WindowServer is waiting on it, it never becomes ready, and the watchdog decides WS is unhealthy and kills it.

A few more key fields that relate to timing and the state at the time of the capture:

• uptime: 70000` → ~19.4 hours since last boot. No sign of immediate post-boot instability.
• displayState: "OFF" → the display was off when the stackshot was taken. That fits exactly with:
  • screensaver active with display turned off
  • display sleep
  • wake transition where the screen hasn’t come back up yet
• thermalPressureLevel: "ThermalPressureLevelModerate (1)"` → some thermal load but not critical; this isn’t a thermal emergency shutdown.

Based on what you provided, I'm guessing that this is repeatable with the following set of events:

1. Display turns off / goes into screensaver / enters a low-power state.
2. At some later point, either during screensaver animation or on wake, that display pipeline is supposed to come back to “ready.”
3. For this internal DisplayID, it never does. That stalls the transaction chain WS is managing.
4. Watchdog sees that WS hasn’t reported a healthy state for that display → kill WS.

So, what could this be telling us?

We get a kernel-level snapshot with a big `processByPid` structure. The snippet you shared mostly shows `kernel_task` threads in `TH_WAIT | TH_UNINT` state, doing normal kernel housekeeping. No obvious smoking-gun thread screaming GPU panic or NVMe fatal error in what I can see.

For a bug type 409 / WATCHDOG*event, that’s expected:

• The stackshot is taken because WS stopped responding, not because the kernel hit an internal fault.
• The kernel itself is awake, doing normal things; the problem is at the level of the WS + GPU/display pipeline.

So I’d classify this as a pure OS stack / hardware interaction issue, not an app or third-party driver issue.

Alright, with all that said, here are the likely subsystem(s) and cause(s):

• WindowServer → internal display on-glass / framebuffer pipeline for DisplayID `0x4280f40`.
• Likely involving GPU driver, display driver, and the WS transaction/health-check logic.

My suggested next steps for you:

• Check multiple WindowServer reports on their machine. If all say `Namespace WATCHDOG`, `Display … not ready`, same `DisplayID: 0x4280f40`, you’re dealing with a single, repeatable failure path.
• See if you can reduce it with power/display tweaks:
  • On AC, try keeping the system from doing deep sleep, leaning on display sleep only.
  • Disable things like: Power Nap, and Wake for network access.
• Configure screensaver to something very simple or even disable it temporarily in favor of pure display sleep, to see if the *screensaver path* is a strong trigger.
• Run Apple Diagnostics and keep an eye out for GPU/display codes.
• Finally, submit a bug report to Apple.

Hopefully, this will help lead you to a solution. Good luck!

FWIW, I think (though I don't have Parallels and have not emulated an older macOS) that it would make sense that, if needed, they would be installed within Mojave, and not for Parallels use in Tahoe.

The key is which CPU (Intel or Silicon) Parallels runs on. Pretty much Parallels uses the same kexts for a number of macOS versions, including Tahoe, running on an Intel box. A different story for Silicon Macs.

A easy way to locate them would be to use this command in the Terminal: kextstat | grep -i prl

To the OP: I am running Parallels on my 2020 MacBook Pro, and I am not seeing this issue with it either being installed or running VMs. Those VMs include older versions of macOS/OS X, Windows, and Linux variations.