WindowServer crashes in GenerateModeListForDisplay while BetterDisplay repeatedly creates virtual displays

[allonli]

Summary

My Mac mini was forcibly logged out on October 6. The logs show WindowServer aborting while BetterDisplay was creating and applying settings to a virtual display. This initially looked like a system freeze/restart, but the machine did not reboot: its boot time remained 16:35:41, and only the graphical session was restarted.

I previously observed two crashes at the same stack location on September 21. I would appreciate help determining whether this is a BetterDisplay issue, a macOS virtual-display API issue, or an interaction between the two.

Environment

• Hardware: Mac mini M4, Mac16,10, 16 GB RAM.
• macOS: 27.0.1 (26A434) for the October 6 crash; 27.0 (26A428) for the September 21 crashes.
• BetterDisplay: 5.1.1, build 53767, as inspected immediately after the October 6 incident.
• Version note: By the time this report was prepared, the installed app was 5.1.1 (53783). I have not confirmed reproduction on build 53783. The update channel has not been independently verified.
• Display: LG TV, identified as LG TV SSCR2. After recovery, system_profiler reports UI Looks like: 2560 x 1440 @ 120.00Hz, with 5120 x 2880 reported pixel dimensions. This is not a claim that the TV has a native 5K panel.
• System Integrity Protection: enabled.
• All timestamps below are UTC+08:00.

What happened

1. Between 21:51:25.742 and 21:54:27.860, the unified log recorded 55 successful RPC spawnProxy responses for BetterDisplay virtual-display creation. This counts creation events, not 55 simultaneously active displays.
2. At 21:54:27.860, BetterDisplay created virtual display 0x7f and called applySettings.
3. At 21:54:28.155, applying the settings returned FAILURE, and launchd recorded WindowServer exiting with SIGABRT—about 295 ms after that creation event.
4. At 21:54:28.272, loginwindow explicitly terminated the session because WindowServer had exited.
5. The desktop was restored at 21:57:12.098.

I do not yet have deterministic steps to reproduce. The exact user action or setting that starts the repeated virtual-display creation has not been established, and I have not performed an isolation test with virtual-display features disabled.

Expected: Virtual-display creation/settings changes should complete or fail gracefully without terminating the desktop session.

Actual: WindowServer aborts and the user is forcibly logged out.

Key log excerpts

2026-10-06 21:54:27.860 BetterDisplay[3260] RPC spawnProxy client<-server displayID=0x7f kr=0x0((os/kern) successful)
2026-10-06 21:54:27.860 BetterDisplay[3260] RPC applySettings client->proxy <private>(0x7f)
2026-10-06 21:54:28.155 BetterDisplay[3260] exit CDVirtualDisplayApplySettingsDictionary: FAILURE
2026-10-06 21:54:28.155 launchd[1] WindowServer[177] exited due to SIGABRT | sent by WindowServer[177]
2026-10-06 21:54:28.272 loginwindow[182] ERROR | Window Server exited, closing down the session immediately
2026-10-06 21:54:28.272 loginwindow[182] directLogoutReason:WindowServerExited

The excerpt above shortens logging prefixes for readability. The attachment contains the full extracted lines.

Crash signature

EXC_CRASH (SIGABRT) / Abort trap: 6; application-specific information: abort() called.

Triggered thread: ws_main_thread, com.apple.main-thread.

libsystem_kernel.dylib  __pthread_kill
libsystem_pthread.dylib pthread_kill
libsystem_c.dylib       abort
SkyLight               WS::Displays::GenerateModeListForDisplay(WS::Displays::SLCADisplay*) + 16456
SkyLight               WS::Displays::SLCADisplay::reevaluate_modes(bool) + 308
SkyLight               WS::Displays::CAWSManager::refresh_display_modes(WS::Displays::SLCADisplay*) + 56
SkyLight               invocation function for block in WS::Displays::CAWSManager::process_deferred_hotplug_events() + 4164

Previous occurrences

On September 21 at 14:33:48 and 17:56:35, WindowServer crashed with the same symbolized stack sequence and offsets.

For the 14:33:48 September incident, BetterDisplay created display 0xa; about 282 ms later, WindowServer logged:

Preferred mode 1x1 filtered out for display 0xa, ca_modes_count=0
Preferred mode 1x1 NOT found in ca_modes (count=0) for display 0xa
GenerateModeListForDisplay FATAL: preferred mode not found. display=0xa (Unknown) virtual=1 mvd=1 strict=0 use_mvd_pref=0

These explicit 1x1/FATAL messages are from September, not the October incident. The September excerpts were retained from an earlier diagnostic session; the original September crash files are no longer available in the currently inspected diagnostic directory.

Possibly related issue

Possibly related: #5672, which is closed and concerns WindowServer crashes after disconnecting macOS Screen Sharing. My exact trigger has not been established, so I cannot confirm that this is the same issue or that the workaround described there applies.

Attachments and investigation status

The attached ZIP contains the redacted October WindowServer .ips report, focused unified-log excerpts, hardware/software information, and the historical comparison. Personal identifiers were redacted while preserving stack frames, binary-image UUIDs, timestamps, display IDs, and process IDs.

The evidence links the failures closely to repeated virtual-display creation, but it does not establish which component is responsible for the underlying defect. Please advise whether this matches a known issue, whether build 53783 is expected to address it, or which additional diagnostics/settings would help investigate.

BetterDisplay-diagnostics-2026-10-06.zip

[waydabber]

The issue may be related to BetterDisplay virtual screens or Screen Sharing virtual screens or both. The issue is clearly a macOS bug, but for sure there must be an interplay with the app based on the logs, although the app I think does everything by the book.

It may be that a windowserver settings reset would help as it sometimes fixes unexplained WindowServer crashes.

[waydabber]

Although the unified-log-excerpts.txt file seems to contain a bunch of virtual screen creations and exits in quick succession, which is kinda not normal and may explain why WindowServer eventually quits. Something seems to get into a kind of loop here.

If there is a way to properly recreate the situation, it would be great to have BetterDisplay internal logs attached as well. You can start the app with unbuffered logging so it survives a crash:

/Applications/BetterDisplay.app/Contents/MacOS/BetterDisplay -v2e 2>>"$HOME/Desktop/betterdisplay.log"

This should create a log file on your desktop which can be investigated in case of a crash. If having a log file on the desktop too annoying, you can of course use any other path you'd like to store the log file until needed.