Hi team, probably I’m not the first or only, but I’m running MacOS 27 and the client launches, I can create a character, however when loading into the game the loading screen itself causes my entire PC to lock up and freeze, and I need to do a hard shutdown (push to hold button in). MacOS M4 Mac mini MacOS 27 24GB unified
I’m experiencing the same symptoms on an M1 Pro running macOS 26.5.2. I checked the local diagnostic logs and found the following:
System
- MacBook Pro (MacBookPro18,3)
- Apple M1 Pro, 32 GB RAM
- macOS 26.5.2 (25F84)
- WoW Beta 1.60.1.69893, native ARM64 client
- Built-in display plus two external 1920×1080 monitors
What happened
- Launched the beta and attempted to enter the game.
- The entire Mac froze at the loading screen.
- The issue occurred again during a subsequent attempt.
Findings from local diagnostic reports
In both incidents, the WoW main thread was waiting inside Metal. Other WoW thread stacks passed through Apple’s IOGPUFamily and AGXG13X graphics drivers.
During the second incident, the WindowServer main thread was also waiting in this graphics path:
com.apple.SkyLight.mtl_submit
→ Metal
→ IOGPU
→ IOGPUFamily
→ AGXG13X
The associated kernel panic report states:
userspace watchdog timeout:
no successful checkins from WindowServer (2 induced crashes) in 120 seconds
WindowServer has not exited since first loaded
Other monitored services, including logd, opendirectoryd, and configd, were still responding.
The WindowServer report showed normal thermal pressure. The panic report described memory compression and swap status as OK.
Additional WoW client errors
The client also generated these errors during the affected or earlier launches:
ERROR #135 / AssertSafe
GraphicsSettingCallback Error loading RAIDbloomUserMult
This appeared twice.
ERROR #135 / AssertSafe
Unable to determine locality for BGDL.
FileData ID 8470130 with CAS error not found
This appeared three times for the same FileData ID.
These errors may be relevant, but I cannot establish that they caused the freeze. At least one affected WoW process continued running after the AssertSafe report until the later system freeze.
16 Likes
Same Issues as listed above -
Mac Mini Apple M4
16GB memory
macOS Tahoe 26.6.2
5 Likes
Same issue here. iMac M3
Noticed when logging into the new zone for the Skyborne that most of the terrain textures were bottle green and the pond black so somethings up.
4 Likes
Same issue on M1 Pro 32GB memory Tahoe 26.0.1 (25A362)
1 Like
Same issue M1 MacBook Pro 32 Gb on MacOS 27 - crashes when trying to zone in * 2 (to the gnome starting area).
1 Like
Same issue here M1 MacBook Pro 16GB
2 Likes
Same, macbook pro m1 pro 32gb, load the word, but crash (not ok with windowed)
1 Like
Fixed by entering windowed mode
Same problem on an M3 Ultra Mac Studio with 96 GB RAM.
Took a look at the crash logs and it appears that WindowServer is hanging during the failure. The WindowServer main thread and HIDEvents queue become unresponsive, and after ~40 seconds macOS’s watchdog terminates it.
In my case this happens when entering the world, I get a black screen, spinning beachball, then the entire macOS UI becomes unresponsive (even Cmd-Tab stops working).
7 Likes
Same here. Mac OS 27. 3 times, crashes my computer whenever try to get past loading screen after logging in.
2 Likes
Same for me, MacOS 27, M3 Max, 128 GB RAM
1 Like
Unfortunately, this has not made a difference.
Same as others. MacOS crash on loading screen.
MBP 16 M3 Pro, MacOS Tahoe 26.6.2
1 Like
Command-m if you want to try windowed mode as per Sorial, but not working for me - the os doesn’t crash any more but getting a spinning beach ball on the loading screen.
Same here, windowed mode doesn’t work either. =(
1 Like
Cannot play on Mac, pretty lame beta launch
3 Likes
Mac mini M4 Pro, macOS 27
System
- Mac mini (Mac16,11), Apple M4 Pro, 12 cores, 24 GB
- macOS 27.0 (build 26A428), arm64
- Display: 3440x1440 @ 144 Hz, single monitor
- Client: World of Warcraft Beta ARM64 1.60.1.69893, Metal, shader family mtl_1_1
- Graphics detected defaults: 6 (CPU 7 / GPU 6 / MEM 7), running maximized (GxMaximize 1)
- No add-ons, fresh beta install, French (frFR) client
Over roughly three hours on 17 September 2026 I hit three distinct problems. All log lines below are copied verbatim from the client’s own Errors/ and Logs/ folders.
Title: [Mac / Apple Silicon] WindowServer watchdog timeout (bug_type 409) entering the world — Mac mini M4 Pro, macOS 27 — plus BGDL/CAS and surname asserts
Adding another data point to the existing macOS reports, this time from an M4 Pro Mac mini. Same signature as the M1 Pro and M3 Ultra reports above: this is not a normal WoW application crash, it is the whole graphical session going down.
System
- Mac mini (Mac16,11), Apple M4 Pro, 12 cores, 24 GB
- macOS 27.0 (build 26A428), arm64
- Display: 3440x1440 @ 144 Hz, single monitor
- Client: World of Warcraft Beta ARM64 1.60.1.69893, Metal, shader family mtl_1_1
- Detected graphics defaults: 6 (CPU 7 / GPU 6 / MEM 7)
- No add-ons, fresh beta install, French (frFR) client
1. WindowServer watchdog timeouts (4 occurrences in 30 minutes)
macOS generated four WindowServer watchdog reports on 17 September 2026, at 23:04:04, 23:05:04, 23:20:19 and 23:33:39, each bug_type 409:
checkin with service: WindowServer (0 induced crashes) returned not alive with context:
40 seconds since last successful checkin
The World of Warcraft Beta process appears in the stackshot of those reports. The client’s own Errors/ folder logs a matching hang at each of those times, but never an application-level crash:
Exception: SIGTERM [HANG]: Terminated
In other words the client did not crash on its own — WindowServer stopped checking in for 40 seconds and macOS tore the session down around it. This matches the reports above from M1 Pro and M3 Ultra machines, where the display goes black, the UI stops responding, Cmd-Tab no longer works and the Mac has to be restarted. One of those users confirmed the machine itself is still alive at that point (SSH keeps working), and that killing the WoW process remotely does not bring the desktop back.
Windowed mode is not a reliable workaround. It was suggested earlier in this thread, but another user has since reproduced the freeze in both fullscreen and windowed mode, so please do not treat it as a fix.
2. Repeated BGDL / CAS lookup failure (12 occurrences)
Three times per session, every session:
Error: ASSERTSAFES(locality != CAS_LOCALITY_ERROR, ...)
Description: Unable to determine locality for BGDL. FileData ID 8470130 with CAS error not found CKey[96E3737F73428445F73E8EF79B94E7FC]
File: .../Engine/Source/FileServices/AsyncFileThread.cpp
Line: 568
Always the same FileDataID (8470130) and the same CKey. Logged at 21:12, 21:19, 21:55, 23:06, 23:35 and 23:41.
Related, just before entering the world:
LoadingScreenGetLoadingScreenFileID file didn't exist in CAS loadingScreensID: 4 textureFileID: 0
The client appears to be missing background-downloaded data it expects to already have. I mention it here because the freezes happen at exactly that moment — entering the world — although I cannot tell whether the two are related.
I also see two occurrences of:
Error: ASSERTSAFES(internalGraphicsSetting, ...)
Description: GraphicsSettingCallback Error loading RAIDbloomUserMult
3. “AddAccountCharacter - no surname provided” assert
On one of the attempts that did reach the world, right after the map finished loading:
Crash Summary: ASSERTALWAYSSAFE("AddAccountCharacter - no surname provided", ...) at .../WoW/Source/Ui/AutoComplete.cpp(330)
Since surnames are mandatory in Forever, the autocomplete code seems to be handed an account character entry without one. This one is separate from the graphics problem and looks straightforward to reproduce.
Happy to provide on request: the four .ips WindowServer reports, the full client error reports, and Logs/gx.log.
7 Likes
Hello, same. M3Pro 18gb macOS 15.8
1 Like
I’ve now managed to reproduce this in both fullscreen and windowed mode, so unfortunately windowed mode isn’t a workaround for me. When I try to enter the world, the client gets far enough that I’ve actually heard the in-game voiceover, then the display goes black and the entire UI becomes unresponsive. Cmd-Tab, etc. stops working and the machine effectively needs a restart.
In both cases macOS has generated a WindowServer watchdog report (bug_type 409), rather than this being a normal WoW application crash. On the latest one, WindowServer stopped responding to the watchdog for 40 seconds before macOS killed it:
monitoring timed out for service
checkin with service: WindowServer ... returned not alive
40 seconds since last successful checkin
Thermal pressure was nominal, so there’s nothing obvious there. WoW was also still present in the stackshot when WindowServer failed (PID 1585, around 6.5GB resident memory), with a number of WoW threads blocked on spinlocks/synchronisation primitives.
There’s also activity around the usual IOGPU/DCP graphics infrastructure, including IOGPU Submission, although I don’t think there’s enough in my logs to say definitively that the GPU driver itself is the problem.
I also tried SSHing into the Mac from another machine while it was in the broken state. Interestingly, SSH continued working perfectly, so the machine itself hadn’t actually crashed it was the graphical session that was completely wedged. I killed the WoW process remotely, but that didn’t recover WindowServer or bring the desktop back. Once it gets into this state, killing WoW doesn’t appear to be enough to unwind whatever has happened and the Mac still needs restarted.
This looks pretty similar to the M1 Pro report above from Maanny, particularly as those logs show both WoW and WindowServer ending up in the Metal → IOGPU/AGX graphics path before WindowServer stops responding. So we’ve now got very similar behaviour across a range of Mac hardware, and in my case it happens in both fullscreen and windowed mode.
5 Likes
Same here:
M5 Pro
48 GB RAM
Version 26.6.2
2 Likes