The Symptom

Recently this Intel MacBook Pro has been randomly black-screening and kicking me back to the login screen. The apps and windows I had open get closed, looking very much like a logout or a desktop crash.

Machine info:

  • Model: Intel MacBook Pro with a T2 chip
  • OS: macOS 26.x
  • GPU: Intel Iris Plus Graphics
  • External devices: no external display or Thunderbolt devices connected during troubleshooting

After the incidents, the system diagnostic directory contained multiple WindowServer reports:

ls -lt /Library/Logs/DiagnosticReports/WindowServer*

In a few days, I found 6 WindowServer watchdog timeouts. This is not an ordinary app crash, but macOS’s graphics service being killed and restarted by the system watchdog after it stopped responding.

What WindowServer Is

WindowServer is macOS’s core graphics service. It handles window drawing, desktop compositing, animations, and display management.

When it crashes or gets killed by the watchdog, you typically experience:

  • The screen suddenly going black
  • An automatic return to the login screen
  • The apps in the current graphics session being closed
  • The desktop coming back after you log in again

So when troubleshooting this kind of issue, you can’t just look at which app happened to be in the foreground. You should also check WindowServer crash reports, display state, and power logs.

Clue #1: Every Crash Happened While the Screen Was Off

Going through the diagnostic reports one by one:

head -25 /Library/Logs/DiagnosticReports/WindowServer-*.ips

All 6 reports contained the same information:

namespace: WATCHDOG
Display ... not ready
DisplayID: 0x...
displayState: OFF

This shows that all incidents point to the same display, and all occurred while the screen was off.

Confirming further with ioreg:

ioreg -r -d 1 -c AppleBacklightDisplay -l

The display in the report is the MacBook’s built-in screen, not a non-existent external monitor.

Clue #2: The Built-in Display Reports Per-Frame Timestamp Anomalies

Pulling the unified log from before the crash:

/usr/bin/log show \
  --style compact \
  --last 10m \
  --predicate 'process == "WindowServer" AND eventMessage CONTAINS[c] "Invalid actual_host_time"'

The log keeps showing:

Invalid actual_host_time received from display: 0x...

The errors appear extremely densely, with intervals close to a 60Hz frame period. One thing is certain: WindowServer continuously considers the display timing information submitted by the built-in screen to be invalid.

Just before the crash, the log finally showed:

display ... has become stuck after 10 seconds of unreadiness
Inform the watchdog that all displays are stuck.

So the full trigger chain becomes clear:

Built-in display keeps submitting abnormal display timing info
→ Display transactions fail to complete while the screen is off
→ Built-in display stays unready for 10 straight seconds
→ WindowServer is force-killed by the watchdog
→ User is bounced back to the login screen

Clue #3: Intel framebuffer responds sluggishly

The power log also shows multiple occurrences of:

AppleIntelFramebuffer driver is slow

You can check the related log with:

pmset -g log | rg 'AppleIntelFramebuffer|Display is turned|Sleep|Wake'

Combined with the facts below, the issue is more likely to lie in the built-in display, the Intel graphics driver, or the display power-state transition path:

  • Every crash points to the same built-in display
  • At the time of every crash, displayState is OFF
  • No external display is connected
  • No third-party display drivers like DisplayLink are installed
  • System agents, Docker, Codex, WeChat, and similar apps were running, but there is no evidence they directly caused the display to hang

Even so, we can’t yet definitively conclude from the logs alone whether the root cause is a macOS Intel graphics driver bug, or a hardware fault in the display cable, the panel timing controller, or the mainboard’s display subsystem.

Temporary Workaround: Prevent the Display from Auto-Sleeping

Since the issue clearly happens while the display is off, the first step is to temporarily set auto-display-sleep and auto-sleep to “Never”:

pmset -g custom

Make sure the output contains:

displaysleep         0
sleep                0

Where:

  • displaysleep 0: the display will not auto-sleep
  • sleep 0: the computer will not auto-sleep

This only sidesteps the trigger condition; the underlying problem is not fixed. Closing the lid will still put the laptop to sleep, so avoid closing the lid during troubleshooting.

A Plain Reboot Did Not Solve It

After a normal reboot, the system did not crash again immediately, but Invalid actual_host_time errors kept pouring in.

In one reboot session, ~4,500 related errors appeared in just 10 minutes; in another, more than 30,000 accumulated in about half an hour after boot.

Counting command:

/usr/bin/log show \
  --style compact \
  --last 10m \
  --predicate 'process == "WindowServer" AND eventMessage CONTAINS[c] "Invalid actual_host_time"' \
  | wc -l

This shows a regular reboot only restarts the graphics session and does not clear the abnormal state.

Final Action: Full Shutdown and SMC/NVRAM Reset

This machine is an Intel MacBook Pro with a T2 chip, so I followed the procedure below.

1. Full Shutdown

  1. Save your work and choose Apple menu → Shut Down
  2. Uncheck “Reopen windows when logging back in”
  3. Wait for the screen and Touch Bar to go completely dark
  4. Unplug the charger and all USB/Thunderbolt devices
  5. Wait at least 30 seconds

2. Reset the SMC

  1. Keep the machine powered off
  2. Hold down the left Control, left Option, and right Shift keys simultaneously
  3. After holding for 7 seconds, also press and hold the power button
  4. Keep all four keys held for another 7 seconds
  5. Release everything, wait 10 seconds
  6. Press the power button to start normally

3. Reset the NVRAM

  1. Shut down again
  2. Press the power button, then immediately hold Option + Command + P + R
  3. Keep holding for about 20 seconds, then release

Result After the Procedure

After a true full shutdown and a fresh SMC/NVRAM reset:

  • No new WindowServer crash reports
  • No further display-hang records
  • No new AppleIntelFramebuffer driver is slow
  • Only a small number of Invalid actual_host_time errors during startup
  • No fresh timestamp errors being generated continuously in the last minute

Compared to thousands of errors per minute before, the improvement is dramatic.

To avoid retriggering the problem right away, I’m still keeping:

displaysleep 0
sleep 0

Continued observation is still required. If the errors or crashes come back, the next steps should be: test in safe mode, try reinstalling macOS from recovery, or have Apple inspect the built-in display, the cable, and the mainboard’s display subsystem.

Reusable Troubleshooting Checklist

When you hit a Mac black-screen-and-back-to-login issue, work through the following in order.

Check WindowServer crash reports

ls -lt /Library/Logs/DiagnosticReports/WindowServer*

Search the cause of a stuck display

rg -n -i 'watchdog|displayState|not ready|DisplayID' \
  /Library/Logs/DiagnosticReports/WindowServer-*.ips

Inspect display devices

system_profiler SPDisplaysDataType SPThunderboltDataType
ioreg -r -d 1 -c AppleBacklightDisplay -l

Inspect sleep and graphics-driver logs

pmset -g custom
pmset -g log | rg 'AppleIntelFramebuffer|Display is turned|Sleep|Wake'

Count WindowServer display-timestamp errors

/usr/bin/log show \
  --style compact \
  --last 10m \
  --predicate 'process == "WindowServer" AND eventMessage CONTAINS[c] "Invalid actual_host_time"' \
  | wc -l

Summary

The biggest lesson from this troubleshooting: don’t blame whichever app happened to be in the foreground right before the crash.

The genuinely valuable evidence came from stable, repeated patterns across multiple diagnostic reports:

  • The same built-in display DisplayID
  • The same displayState: OFF
  • The same “display not ready” and watchdog timeout
  • Continuous Invalid actual_host_time
  • Slow Intel framebuffer power-state transitions

In the end, a full shutdown plus SMC/NVRAM reset temporarily cleared the persistent errors; disabling auto-display-sleep sidestepped the known trigger. As for whether the deeper root cause is in the macOS driver or the hardware, more time is needed to draw a conclusion.