Additional Findings from Crash Analysis After analyzing multiple WindowServer crash reports, I noticed that the crashes are highly consistent. Both crash logs terminate with an internal assertion (__assert_rtn) inside the same Apple display pipeline function: CA::WindowServer::AppleDisplay::max_src_rect_width_by_pipes() The call stack is consistently: __assert_rtn CA::WindowServer::AppleDisplay::max_src_rect_width_by_pipes() CA::WindowServer::Server::get_display_info() _XGetDisplayInfo This suggests that WindowServer is failing while calculating display pipeline parameters during display information processing, rather than due to a GPU hang, Metal failure, or a third-party application. I also reviewed the CPU Resource Diagnostic generated for WindowServer. During periods of high CPU usage, most of the activity is concentrated in WindowServer’s display update and Core Animation pipeline (display updates and rendering preparation), rather than GPU recovery or driver timeout paths. In addition, I did not find evidence of AGX GPU panics, IOAccelerator timeouts, Metal command buffer failures, or DisplayLink-related components in the collected logs. These observations suggest that the issue may be located within WindowServer’s AppleDisplay/display pipeline implementation when driving this external high-resolution, high-refresh-rate display configuration.

Case / Feedback Reference Feedback ID: FB23616959 (Captured after the system format)

system version is 27.0 Beta (26A5378j)