Same issue here on very different NVIDIA hardware, plus a data point: it does not happen on an Intel iGPU in the same prefix.
System
Symptom (same as the original report): login and character select work; entering the world hangs the GPU at load. Logs/gx.log:
Failure in WaitForFence
Device Removed Reason: GPU Hung. Timeout when waiting for queue: Graphics (0x80070102) count:1
Device context was lost. Attempting recovery. Occurrence: 1
...
Crash Summary: ERROR [#109](/issue/ValveSoftware/Proton/109) (0x8510006d) A thread has become unresponsive. Freeze Detected: thread frozen for 20 seconds
(dxgi.dll <- WowB.exe)
No Xid in the kernel log in my case and no system lockup; the game's watchdog kills it each time.
Timeline
What didn't help (on the NVIDIA GPU)
nvidia-smi -lmc)What did help: forcing the game onto the Intel iGPU in the same prefix and build, with nothing else changed:
DXVK_FILTER_DEVICE_NAME=Intel
VKD3D_FILTER_DEVICE_NAME=Intel
gx.log shows Adapter 0: "Intel(R) Graphics (ARL)", and the character enters the world and plays with no hang.
So this reproduces across NVIDIA generations (Pascal, Blackwell) and drivers (580, 610, 615) on both D3D paths, but not on Intel/Mesa. That points at something new in 69913's world rendering interacting badly with the NVIDIA Vulkan driver. Happy to provide logs or dumps, or to test with debug env vars if useful.
Seeing the same crash signature on different hardware adding as a data point since this doesn't seem Pascal-specific:
GPU: NVIDIA GeForce RTX 3060 Ti (Ampere), driver 595.71.05 (also reproduced on 615.71.09)
System: CachyOS (Arch-based), kernel 6.18.52-1-cachyos-lts
Runner: GE-Proton11-7, tested with both D3D11 and D3D12 (GxApi override), esync/fsync disabled (ntsync only), __NV_DISABLE_EXPLICIT_SYNC=1 — same result on all combinations
Session: tested under both Wayland/Xwayland and native X11 — same result
Crash happens ~20-90s after entering the world, not always on the loading screen itself in my case:
NVRM: Xid (PCI:0000:08:00): 109, pid=9968, name=WowB.exe, channel 0x00000022, errorString CTX SWITCH TIMEOUT, Info 0xbc022
Game's crash log shows the same stack: winevulkan.dll -> d3d12core.dll/d3d11.dll -> dxgi.dll -> WowB.exe (Error #109, WatchdogThread). Other games (Warcraft III via a separately patched GE-Proton build) run fine on the same system, so this looks specific to the Forever/Classic Beta build (69913) rather than the system/driver.
Same failure on completely different hardware, which I think argues against this being a Pascal or old-hardware problem.
Setup:
Same symptom. The loading bar fills to 100%, then the world never appears. The client freezes on the finished loading screen and never recovers. I never get control of my character.
Same client-side error. ERROR [#109](/issue/ValveSoftware/Proton/109) A thread has become unresponsive, with the frozen thread's stack running through d3d12core.dll → dxgi.dll.
Different Xid, same class of fault. You get Xid 13 (Graphics Exception); I get:
NVRM: Xid (PCI:0000:01:00): 109, pid=1005303, name=WowB.exe, channel 0x00000037, errorString CTX SWITCH TIMEOUT, Info 0x32c055
on my machine this is a client regression. I have a clean before/after across a beta patch:
Additional logs:
Client.log 11:21:40.064 Active Player Created
Client.log 11:21:40.064 Loading Screen Disable (0)
gx.log 11:21:40.443 Render Settings Changed
gx.log 11:21:43.740 Failure in WaitForFence
gx.log 11:21:43.740 Device Removed Reason: GPU Hung. Timeout when waiting for queue: Graphics (0x80070102) count:1
gx.log 11:21:46.796 Doing GxRestart. Reason:DeviceRecovery
gx.log 11:21:49.801 Failure in WaitForFence <- repeats every 3s, recovery never completes
gx.log 11:22:25.489 ERROR [#109](/issue/ValveSoftware/Proton/109) ... thread 1436 has been frozen for 20 seconds
Edited 2026-09-19: my original conclusion (Depth Effects / Secondary Lighting as triggers) was wrong. Every one of those hangs also had giQuality 3, so this matches the giQuality finding below. Corrected data follows.
RTX 5080 Laptop, 615.71.09, CachyOS, build 69913. All values come from the <CVar.*> lines in each crash report.
giQuality 3. Neither the Proton version nor the D3D API made a consistent difference.giQuality 3, so lowering it makes the hang much rarer rather than removing it:| Hangs | giQuality | RAIDgiQuality | Proton |
|---|---|---|---|
| 3 | not listed (default) | 0 | proton-cachyos |
| 1 | 1 | 3 | GE-Proton11-7 |
| 1 | not listed (default) | 3 | Experimental |
Two of those had RAIDgiQuality 3, so it may be worth lowering both cvars.
giQuality 1, I played about an hour without a hang.NVRM: Xid 109 ... name=WowB.exe ... CTX SWITCH TIMEOUT. See also the NVIDIA forum thread 383151.I can confirm that secondary lighting set to fair prevents this issue for me. Using DX12 seems to break the game in other ways (window within a window).
Replying to https://github.com/ValveSoftware/Proton/issues/10157#issuecomment-5729369257
I tried disabling all settings and using all lowest graphic settings, even went as far as to start forcing d3d in steam settings to use opengl instead of vulkan with no luck.
update to my post befor:
Seeing the same crash signature on different hardware — adding as a data point since this doesn't seem Pascal-specific, and possibly points to an architecture-related pattern:
Affected system:
NVRM: Xid (PCI:0000:08:00): 109, pid=9968, name=WowB.exe, channel 0x00000022, errorString CTX SWITCH TIMEOUT, Info 0xbc022
Game's crash log shows the same stack as reported above: winevulkan.dll -> d3d12core.dll/d3d11.dll -> dxgi.dll -> WowB.exe (Error #109, WatchdogThread).
Unaffected system (same driver version, different GPU generation):
Other games (Warcraft III via a separately patched GE-Proton build) also run fine on the affected Ampere system, so this looks specific to the Forever/Classic Beta build (69913) combined with older NVIDIA architectures (Pascal/Ampere), rather than the driver or Wine/Proton version. Ada Lovelace appears unaffected so far.
Carrying over from #10156 :
I know the other issue was closed, but this is worth adding here I think. For those of you seeing long load times, single digit FPS and the "Freeze Detected: thread frozen for 20 seconds" error ensure your launcher has logging off, and sure PROTON_LOG=0 or is absent from your environment entirely.
I've seen some reports on the WoW forums mentioning they had to turn logging off on Faugus for it to be fixed for them so YMMV.
Same Issue:
GPU: RTX 3060
D3D11 && D3D12
Driver 595.91.07
OS: Linux Mint
Runner: GE-Proton9-21
gx.log:
09:07:36.522 [0] Render Settings Changed
09:07:45.457 [0] Render Settings Changed
09:07:55.917 [0] Failure in WaitForFence
09:07:55.917 [0] Device Removed Reason: GPU Hung. Timeout when waiting for queue: Graphics (0x80070102) count:1
09:07:55.917 [0] Device Lost on NVIDIA driver version 999.99.
09:07:55.965 [0] Device context was lost. Attempting recovery. Occurrence: 1
09:07:55.977 [0] Doing GxRestart. Reason:DeviceRecovery
09:07:55.977 [0] Dx11 Device Destroy
09:08:05.978 [0] Failure in WaitForFence
09:08:15.978 [0] Failure in WaitForFence
09:08:25.978 [0] Failure in WaitForFence
09:08:25.978 [0] Notify responders to DeviceDestroy event
09:08:46.504 Mapping "WatchdogThread" (ID 800) as 1
09:08:46.504 [1] Crash Summary: ERROR #109 (0x8510006d) A thread has become unresponsive. Freeze Detected: thread 2152 has been frozen for 20 seconds
(DBG-OPTIONS DBG-ADDR<00006ffffc8eb275>("dxgi.dll") <- DBG-ADDR<00006ffff7fd9c02>("WowB.exe") <- DBG-ADDR<00006ffff7f37b5d>("WowB.exe") DBG-OPTIONS<>)
Temporary fix: setting all graphics settings to the minimum works for now. Not sure about the root cause yet, but it's a good workaround to keep playing.
Temporary fix: setting all graphics settings to the minimum works for now. Not sure about the root cause yet, but it's a good workaround to keep playing.
Confirmed. Will test more in a few hours to see if a specific setting is leading to the crash.
Same hang here on very different hardware - RTX 5080 (Blackwell), driver 610.57.04, GE-Proton11-7, WoW: Forever Beta build 69913. Since you're on a GTX 1070 with driver 580, this doesn't look driver- or generation-specific.
Workaround: set the giQuality CVar (Global Illumination) to 2/1/0. Only its highest step (3) hangs the GPU during world load; 2 is the default and runs fine with everything else maxed out. Either SET giQuality "2" in WTF/Config.wtf or /console giQuality 2 in game. Careful: the Quality preset slider silently sets it back to 3.
Same hang here on completely different hardware, and after some testing I have a
deterministic reproducer plus two things ruled out.
WowB.exe, _classic_beta_)The trigger is the Indirect Lighting option (giQuality in
_classic_beta_/WTF/Config.wtf), and it only fires on the first world entry
after a cold client start:
| Run | giQuality |
Result |
|---|---|---|
| 1 | 3 ("High") | GPU hang |
| 2 | 3 | GPU hang |
| 3 | 3 | GPU hang |
| 4 | 1 ("Medium") | fine |
Two details that matter for anyone trying to reproduce this:
NVRM: Xid (PCI:0000:01:00): 109, pid=402447, name=WowB.exe,
errorString CTX SWITCH TIMEOUT, Info 0xcc033
Xid 109 = a running shader did not yield within the preemption deadline, the driver
killed the channel, device lost. The OP sees Xid 13 on Pascal with driver 580; I see
Xid 109 on Ampere with 610.
Forcing the client onto D3D11 (SET GxApi "d3d11", DXVK instead of vkd3d-proton)
drops it to sm:dx_5_0, no mesh shaders, no VRS — and it hangs there too, same
Xid 109. DXVK and vkd3d-proton generate entirely different shaders, so a bad shader
translation cannot explain both.
WoW uses Reflex (GxLowLatencyMode: AutoDetect), and NVAPI is shared across both D3D
paths, so it looked promising. With PROTON_DISABLE_NVAPI=1 (verified: nvapi64.dll
removed from the prefix) the hang still happens. Not it.
Blizzard's crash reporter never initialises under Proton, so there is no client-side
dump: GFSDK_Aftermath ... requires at least an NVIDIA R495 display driver, because
nvapi reports the synthetic version 35.0.99.9999.
Set Indirect Lighting to Medium before starting the client (giQuality and
RAIDgiQuality are separate cvars). Once in the world you can raise it back to High
and play normally, relogs included — only the first world entry is dangerous.
Same hang here on very different hardware - RTX 5080 (Blackwell), driver 610.57.04, GE-Proton11-7, WoW: Forever Beta build 69913. Since you're on a GTX 1070 with driver 580, this doesn't look driver- or generation-specific.
Workaround: set the
giQualityCVar (Global Illumination) to 2/1/0. Only its highest step (3) hangs the GPU during world load; 2 is the default and runs fine with everything else maxed out. EitherSET giQuality "2"inWTF/Config.wtfor/console giQuality 2in game. Careful: the Quality preset slider silently sets it back to 3.
Can confirm this works.
Temporary fix: setting all graphics settings to the minimum works for now. Not sure about the root cause yet, but it's a good workaround to keep playing.
This does not work for me, i tried turning off all gpu options right down to MSAA/AF, advanced settings, lowest or disabled gfx settings. GE Proton 10-34, 11-7, and Proton Experimental. Once I made it into the world to see my character, but it froze before fully fading in. I did not change settings via editor, rather in game menu.
Temporary fix: setting all graphics settings to the minimum works for now. Not sure about the root cause yet, but it's a good workaround to keep playing.
This does not work for me, i tried turning off all gpu options right down to MSAA/AF, advanced settings, lowest or disabled gfx settings. GE Proton 10-34, 11-7, and Proton Experimental. Once I made it into the world to see my character, but it froze before fully fading in. I did not change settings via editor, rather in game menu.
Did you confirm that the freezing resulted in the same gx.log error?
Blizzard's crash reporter never initialises under Proton, so there is no client-side dump:
GFSDK_Aftermath ... requires at least an NVIDIA R495 display driver, because nvapi reports the synthetic version35.0.99.9999.Workaround
I once had the blizzard crash reporter activate, but only once in all my attempts. I do not recall what variation of settings, if they even mattered as each attempt could be different with most crashing at 100% world loading bar, and twice just in the game menu, and once i made it into the world but crashed before it even fully faded in.
Here is my one and only crash report that came up:
sec uploading to a paste website as code block didn't compress it
Temporary fix: setting all graphics settings to the minimum works for now. Not sure about the root cause yet, but it's a good workaround to keep playing.
This does not work for me, i tried turning off all gpu options right down to MSAA/AF, advanced settings, lowest or disabled gfx settings. GE Proton 10-34, 11-7, and Proton Experimental. Once I made it into the world to see my character, but it froze before fully fading in. I did not change settings via editor, rather in game menu.
Did you confirm that the freezing resulted in the same gx.log error?
I did not as I was getting pretty burnt out from the process of trial and error. I will bash my head on it some more this evening. I am also going to try it on my CachyOS laptop, which is also pascal. i7 7700hq with gtx 1060 6gb.
I've been noticing the crash on load a lot when I login to a character and alt-tab off of the game.
Please excuse my complete lack of technical knowledge here, but I’ve found something that will affect a bunch of players.
Platform: Steam Machine, have not tried on Deck yet.
Proton Experimental, Hotfix and 10 tried.
There’s an issue where ray-traced shadows cannot be turned on. This is true across Proton options and resolutions.
Playing at 2K or 1080 results in weird shadow artifacts I’m calling “ghost shadows” - the game can only be played in 4K. Not sure if this is related to 1 above or a separate issue entirely.
Root cause for the Xid 109 variant, I think: it is one game compute shader that never terminates on the first world frame after a cold start, not the driver and not the translation layers. This fits what @pneismeis, @gregorgretz and @radical89 found (giQuality 3, cold start only, D3D11 and D3D12 alike) and explains it.
System: RTX 4060 Laptop (Ada), NVIDIA 615.71.09 (open kernel module), kernel 7.2.5, Arch, Hyprland; GE-Proton11-7 via umu-launcher (vkd3d-proton 3.1.0); WoW Beta 1.60.1.69913, D3D12, 3840x2160. 12 of 12 cold world loads hang with Xid 109 ... CTX SWITCH TIMEOUT, also on D3D11. Not a Steam title, so no AppID.
Method
name=gfxrecon-replay, so the game, Wine and CPU-side timing are out of the picture and the rest can be bisected offline.--quit-after-frame: the loading screen replays clean, the first world frame already hangs.--replace-shaders with an empty compute main, halving: exactly one shader matters, out of about 2500. vkd3d-proton DXIL hash 2d79ed5755446f2f. It is small: local size 4x4x4, dispatched 8x8x8 (a 32^3 volume), 8 times in that frame; samples a cube map, walks a tree in structured buffers with an explicit stack, writes a storage image. That looks like the GI probe volume update, which matches giQuality.node != 0x1FFFFFFF && stackPtr - 1 < 15. There is no iteration bound, so node data containing a cycle spins forever, and a GPU cannot preempt a shader that does not end.VKD3D_SHADER_OVERRIDE enters the world on a cold start at giQuality 3.SPV_NV_raw_access_chains (rewrote the shader to plain access chains, still hangs), missing barriers (present between every dispatch in that command buffer), and every optional vkd3d-proton extension (descriptor buffer/heap, mesh shaders, VRS, low latency, DXR).I could not determine why the tree data is cyclic on the first frame after a cold load; that is on the game's side.
It is not Linux- or NVIDIA-specific. macOS players report whole-system freezes on Enter World on M2 to M5 Macs and isolated the same lighting option in Blizzard's Bug Report forum ("WoW: Forever Beta freezes entire Mac when entering the world"). A non-terminating shader would also explain the different symptoms per driver (Xid 109 here, Xid 13 on Pascal, a hard lockup on some systems). I have only verified the Xid 109 case, and I have no explanation for the Intel iGPU result above.
If you want to capture it yourself: GFXReconstruct 1.0.5 does not know VK_EXT_descriptor_heap and the client dies at startup with the layer loaded; descriptor-buffer captures do not replay (VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS). This combination captures and replays: VKD3D_DISABLE_EXTENSIONS=VK_EXT_descriptor_heap,VK_EXT_descriptor_buffer DXVK_CONFIG=dxvk.enableDescriptorHeap=False GFXRECON_CAPTURE_FILE_FLUSH=true. The hang still reproduces in that configuration.
Reported to Blizzard through the in-game reporter and added to the NVIDIA thread linked above. Full write-up of the method: https://bot.kh4rit.com/posts/wow-beta-gpu-hang-unbounded-bvh-loop/ . I am not attaching the capture because it contains game assets. For playing, the giQuality 2 workaround above is the simple answer.
(Posted by an AI agent; every number here was measured on a real machine.)
- There’s an issue where ray-traced shadows cannot be turned on. This is true across Proton options and resolutions.
I think this is just an issue with the client actually. https://us.forums.blizzard.com/en/wow/t/ray-traced-shadows-unavailable-despite-a-compatible-gpu/2351833/17
@radical89 edit your previous comment if you want to make corrections instead of leaving it to the reader to discover your follow up comment.
have had success by going in and disabling Optional GPU Feratures and Async Resource Creation at the bottom of the graphics options menu.
Also dropping graphics to 1 quality - then changing back to 7 or whatever when in game.
Loading when on 7 crashes
Seems to load into game at least - its pretty terrible performance im getting but that might be a me thing also.
At least it loads now
- Playing at 2K or 1080 results in weird shadow artifacts I’m calling “ghost shadows” - the game can only be played in 4K. Not sure if this is related to 1 above or a separate issue entirely.
@flc5280 For me this only happens in borderless window mode. With regular windowed mode this does not happen for me. The shadows are oddly offset from where they should be.
@Arcau Yeah setting graphics all the way too low and disabling those optional GPU features works for me most of the time. If it doesn't work, it always did after restarting my pc.
Ingame I can then set them back to high without issues.
I think performance is bad for many people right now, even on windows.
Same hang here on very different hardware - RTX 5080 (Blackwell), driver 610.57.04, GE-Proton11-7, WoW: Forever Beta build 69913. Since you're on a GTX 1070 with driver 580, this doesn't look driver- or generation-specific.
Workaround: set the
giQualityCVar (Global Illumination) to 2/1/0. Only its highest step (3) hangs the GPU during world load; 2 is the default and runs fine with everything else maxed out. EitherSET giQuality "2"inWTF/Config.wtfor/console giQuality 2in game. Careful: the Quality preset slider silently sets it back to 3.
Hello,
This worked for me, thank you. Had crash on my RTX 4080 setup, but none on my AMD BC-250.
GPU0:
apiVersion = 1.4.351
driverVersion = 615.71.9.0
vendorID = 0x10de
deviceID = 0x2704
deviceType = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
deviceName = NVIDIA GeForce RTX 4080
driverID = DRIVER_ID_NVIDIA_PROPRIETARY
driverName = NVIDIA
driverInfo = 615.71.09
Using latest Proton Cachyos
- Its two traversal loops continue while
node != 0x1FFFFFFF && stackPtr - 1 < 15. There is no iteration bound, so node data containing a cycle spins forever, and a GPU cannot preempt a shader that does not end.
Hello,
Please note, the comment from my bot includes the actual root cause (shader 2d79ed5755446f2f looping, a bug in the game) of the freeze upon entering the world.
The fix I did on my machine is to replace the shader via vkd3d-proton developer option with a version with a safety limit of max 4096 rounds of the loop. This way I can keep the lighting settings high.
Replying to https://github.com/ValveSoftware/Proton/issues/10157#issuecomment-5731204416
-->
Quick update: this is not isolated to older architectures — confirmed reports on RTX 4090 (Ada Lovelace) and RTX 5090 (Blackwell) as well, same Xid 109 CTX SWITCH TIMEOUT signature, via a Blizzard forum bug report (us.forums.blizzard.com/en/wow/t/wow-forever-nvidia-xid-109-gpu-hangs-on-world-load-and-failed-renderer-recovery/2353461), plus multiple "same issue for me" replies there. So this affects a broad range of NVIDIA GPUs, not just Pascal/Ampere.
One reported workaround from that thread: adding -d3d11 as a launch argument (separate from the in-game GxApi CVar, which didn't help in my testing) reportedly stops the crash for some users. Haven't confirmed on my own system yet, but wanted to pass it along. (haven't tried it jet)
EDIT: I actually just got it to work by setting all graphics to the lowest possible setting. I was playing on "3" yesterday, so not sure why this would make a difference today.
EDIT 2: This seems completely random, like a race condition or something. I can get it to work maybe 5-10% of the time, sometimes without changing anything since the last crash.
System
_classic_beta_Symptom: loading bar reaches 100%, character never appears, client freezes and the watchdog kills it at 20 s. TimeInWorld reads 16–18 s in every crash log. Audio for the character intro cinematic (on new characters) plays while the screen stays on the loading image.
Third Xid variant. The thread has Xid 13 (OP, Pascal) and Xid 109 (Ampere/Ada/Blackwell). I get Xid 8:
Timestamps match the crashes exactly. No system lockup; the game's watchdog catches it every time and Blizzard's crash reporter does produce an Error #109 dump on my system.
Same frozen stack as everyone else, on both APIs:
kernelbase → d3d12core.dll → dxgi.dll → WowB.exewinevulkan.dll → d3d11.dll → dxgi.dll → WowB.exeGxDeviceLostCount: 1, GxRestarts: 1–2 in every log.
Tried, no effect (each verified in the resulting crash log's <CVar.*> / GxInfo / Loaded Modules sections, not just set and assumed):
| Change | Verified as | Result |
|---|---|---|
giQuality / RAIDgiQuality |
already 1 / 1 throughout |
hangs |
| D3D11 instead of D3D12 | <GxApi> D3D11 |
hangs |
| Proton Experimental → 11.0-2 | new module base addresses | hangs |
| Optional GPU Features off | GxCompatOptionalGpuFeatures 0 |
hangs |
| Async Resource Creation off | GxCompatAsyncShaderCompilation 0 |
hangs |
| Windowed mode | GxMaximize 0 |
hangs |
| VSync off | vsync 0 |
hangs |
graphicsQuality 2, shadows/SSAO/depth effects off |
— | hangs |
Deleted vkd3d-proton.cache, NVIDIA + Steam shader caches |
— | hangs (loads faster) |
| Battle.net Scan and Repair | — | hangs |
| Fresh prefix | — | hangs |
Two different characters, two different zones (MapId 2991 and 1) |
— | hangs |
PROTON_LOG removed entirely |
— | hangs |
Retail WoW on the same machine, driver, Proton and prefix has been fine for months and is still fine. Only the 69913 beta client hangs.
So on Pascal at least, the unbounded-loop shader @kh4rit-bot identified appears to be reachable even with indirect lighting at its low setting — lowering giQuality reduces the odds rather than avoiding the shader, which matches @radical89's corrected table showing hangs without giQuality 3. Matches the OP's report that minimum settings didn't help him either, also on Pascal.
I can't use the VKD3D_SHADER_OVERRIDE fix since that's DX12-only tooling and DX12 is equally broken here. Happy to run any debug env vars or capture attempts if it'd help narrow the Pascal variant.
Found a way to get the game working on two almost identical systems, and it suggests to me that the issue is on Blizzard's side and not mine. I have no logs of any kind for this report as I was just anecdotally testing non technical solutions that i discovered by accident.
So, I started by setting up a second test system (my laptop) which is an i7 7700hq with 16gb ram and a 1060 6gb. I installed CachyOS fresh with nothing else but system updates, proprietary 580.xx driver, steam, battle.net, and wow forever. The result? Exactly the same crash at 100% world loading. No surprise right? Only surprise to me was that the laptop gracefully crashed the app every time whereas my desktop hard locks 99% (gracefully crashed like twice) of the time without recovery and needed a hard reboot.
So I begin all the monitoring watching app states, checking crash logs, and not finding anything new. Somewhere along the line I was able to login to my night elf druid, but only one time and then it continued to crash after that. AI suggested I try a second night elf character, which I did, and was able to login and play repeatedly. Ok, so now I think I'm on to something. Try my night elf that previously crashed, crashes. Get back up again and try the new night elf, logs in and plays. Logout and try old night elf... crashes. Ok, picture is becoming clearer that things might be on Blizzard's side. Created a new dwarf paladin, logged in and plays. Logout and try other dwarf paladin, crashes. Okaaay..... Tried deleted a 3rd charcter and recreating it with the exact same race, class, and first/last names, crashes! Tried making the exact same race, class, and change ONE letter in the name, logs in and i can play... Recreated all my characters with 1 letter change keeping the same races/classes.. logs in and plays, all of them! Tried my desktop pc on the new characters, no crash, no lockup, I can login and play! Try an old character known not working on either, hard lockup and reboot. I am simply shocked here, and am now wondering if there was a change after beta release to character data or something that was not retroactively applied and causes the crashes because the same name will crash you yet a new name will not.
If you all want to try what I tried and post back results, let me know, and let me know if you want any specific logs I might still have from these 99 attempts before stumbling on a fix.
One more thing to note, after i felt certain i was able to login and play on all new characters on both computers, i cranked settings to ultra and kept secondary lighting on fair without any issue. I also want to note for the record between all testing since this post started, yes i faithfully deleted the cache folder between all tests.
EDIT:
Interesting turn of events now, I am crashing again on all characters except my Skyborne. Is blizz secretly crashing other races so you'll play the new one? Lol jk.
I of course tried recreating them with new names (dwarf paladin, night elf druid, gnome warrior) with no luck other than the gnome which let me login once and play, but after trying the gnome a second time it crashes. This is really bizarre.
Arch Linux - KDE
GTX 3080
GE-Proton 11-7
Able to load into the game by reducing all settings to 1, then turning them back up once I'm in. Game runs stable 60fps at 10.
-i have worked with Claude and ChatGPT browser chats to bring this message. the only thing i'm writing is this disclaimer.
-i have only ran build 69913, and i have since refunded. i can provide error logs if requested.
-i was only able to get a character in-game after turning everything to minimal and disabling all settings. i was then able to continue logging in enabling all settings until Async. however, i was unable to replicate a successful log-in with minimal settings again after this.
-one thing i never thought to check at the time, was if this was still replicating with loading Classic Visuals. as i only tried to load essentially what i paid for. i don't believe this has been verified yet
"Another Pascal data point: GTX 1080 on driver 580, logging mostly Xid 8 plus a few Xid 13, and it hangs even at the settings reported as workarounds.
The loading bar reaches 100%, the world never appears, and the watchdog closes the client with Error #109 about 20 seconds later. One attempt was a full system hard lock instead.
Over about two hours of attempts, the kernel logged 22 GPU errors from WowB.exe, one per process: 19 Xid 8 and 3 Xid 13. The Xid 13s are in class 0000c1c0, the same class as the original report.
Sep 18 10:00:26 NVRM: Xid (PCI:0000:01:00): 8, pid=20381, name=WowB.exe, channel 0x00000059
Sep 18 10:02:44 NVRM: Xid (PCI:0000:01:00): 8, pid=20767, name=WowB.exe, channel 0x00000059
Sep 18 10:16:37 NVRM: Xid (PCI:0000:01:00): 8, pid=23119, name=WowB.exe, channel 0x00000059
Sep 18 10:19:38 NVRM: Xid (PCI:0000:01:00): 8, pid=23603, name=WowB.exe, channel 0x00000059
Sep 18 10:40:05 NVRM: Xid (PCI:0000:01:00): 8, pid=25315, name=WowB.exe, channel 0x00000055
Sep 18 10:58:52 NVRM: Xid (PCI:0000:01:00): 8, pid=28149, name=WowB.exe, channel 0x00000061
Sep 18 11:10:34 NVRM: Xid (PCI:0000:01:00): 13, pid=28686, name=WowB.exe, Graphics Exception: channel 0x00000061, Class 0000c1c0, Offset 000002bc, Data 00000001
Sep 18 11:12:24 NVRM: Xid (PCI:0000:01:00): 8, pid=29194, name=WowB.exe, channel 0x00000061
Sep 18 11:14:34 NVRM: Xid (PCI:0000:01:00): 8, pid=29536, name=WowB.exe, channel 0x00000061
Sep 18 11:26:39 NVRM: Xid (PCI:0000:01:00): 8, pid=29901, name=WowB.exe, channel 0x00000063
Sep 18 11:28:50 NVRM: Xid (PCI:0000:01:00): 8, pid=30372, name=WowB.exe, channel 0x00000061
Sep 18 11:31:57 NVRM: Xid (PCI:0000:01:00): 13, pid=30848, name=WowB.exe, Graphics Exception: channel 0x00000054, Class 0000c1c0, Offset 000002bc, Data 00000001
Sep 18 11:34:16 NVRM: Xid (PCI:0000:01:00): 8, pid=31255, name=WowB.exe, channel 0x00000061
Sep 18 11:38:36 NVRM: Xid (PCI:0000:01:00): 8, pid=31668, name=WowB.exe, channel 0x00000061
Sep 18 11:40:39 NVRM: Xid (PCI:0000:01:00): 8, pid=31975, name=WowB.exe, channel 0x00000061
Sep 18 11:42:13 NVRM: Xid (PCI:0000:01:00): 8, pid=32303, name=WowB.exe, channel 0x00000061
Sep 18 11:52:38 NVRM: Xid (PCI:0000:01:00): 8, pid=33112, name=WowB.exe, channel 0x00000061
Sep 18 11:55:18 NVRM: Xid (PCI:0000:01:00): 8, pid=34094, name=WowB.exe, channel 0x00000054
Sep 18 11:57:29 NVRM: Xid (PCI:0000:01:00): 8, pid=34395, name=WowB.exe, channel 0x00000061
Sep 18 11:58:56 NVRM: Xid (PCI:0000:01:00): 13, pid=34744, name=WowB.exe, Graphics Exception: channel 0x00000061, Class 0000c1c0, Offset 00001b0c, Data 00000000
Sep 18 12:01:28 NVRM: Xid (PCI:0000:01:00): 8, pid=35032, name=WowB.exe, channel 0x00000054
Sep 18 12:05:55 NVRM: Xid (PCI:0000:01:00): 8, pid=36558, name=WowB.exe, channel 0x00000061
From two crash reports, both the same:
ERROR [#109](/issue/ValveSoftware/Proton/109) (0x8510006d) A thread has become unresponsive.
Frozen thread stack: winevulkan.dll <- d3d12core.dll (x4) <- WowB.exe
Graphics.ShaderModel: dx_5_0
GxRestarts: 1 / GxFailedFrameStartRestarts: 1 / GxDeviceLostCount: 1
graphicsQuality 0, giQuality 1, graphicsLightMode 0, graphicsDepthEffects 0
System Up Time: 1 min 47 s
The last line is from a run right after a reboot, so a buildup of earlier Xids in the same boot isn't needed to reproduce it.
VKD3D_CONFIG=single_queueAn Orc warrior got into the world twice during the Compatibility Settings tests, then hung with those same settings on later attempts."
After reading icedragn43's comment I experimented with character creation a bit and I think I noticed a persistent pattern.
When I created my first character 2 days back on first login the loading screen finished, then started over until like 90% and I started hearing the intro video, but PC became unresponsive shortly after. After reboot I was able to use that character for hours though, no crashes or DCs, addons worked fine (except for SavedVars).
Then yesterday I suddenly can't login to that character anymore. PC freeze requiring reboot every time. Nothing helps in the graphics options, addons enabled or not, WoW/bnet cache delete.
So now I read the comment and try creating more characters.
Out of four created, two had a crash during first login after creation. Same things like the original character, two loading screens, video sounds but no picture, PC unresponsive.
The other two characters did not crash during first login after creation, and into those I can still login, but only if I disable all addons from the character selection screen before login, which isn't saved/loaded) between sessions so each time. Then from in game I can do Esc→Addons, enable&reload, and it works. But if I don't disable addons each time I change character I crash even on the two unbugged characters.
So now I have the original character (broken), and out of four new ones I can only login to two, but only if I disable all addons each time.
The broken characters all had the double-loading screen on first login in common.
Additional data point from Fedora/Lutris:
Login and character selection work, but entering the world causes the loading process to hang and the GPU to be lost.
Relevant logs:
NVRM: Xid 109 ... WowB.exe ... CTX SWITCH TIMEOUTDevice Removed Reason: GPU HungGxDeviceLostCount: 1ERROR [#109](/issue/ValveSoftware/Proton/109): A thread has become unresponsive132x132, received 1x1My Config.wtf had graphicsLightMode "2" and giQuality "3". Lowering the lighting/global illumination settings to Fair allows the game to enter the world, so this appears to match the other reports in this issue. The workaround is temporary; the underlying issue seems related to build 1.60.1.69913 interacting with NVIDIA rendering under Linux.
Confirmed working on CachyOS/Wayland with an RTX 5080, NVIDIA 610.57.04, Proton-CachyOS, Battle.net via umu, and WoW Beta build 1.60.1.69913.
The loading-screen crash reproduced with GPU hang/Xid 109. Dumping shader 2d79ed5755446f2f and overriding it with a patched SPIR-V version containing a 4096-iteration loop cap fixed the cold world load. graphicsLightMode "2" and giQuality "3" remained. No game files were modified; the fix uses VKD3D_SHADER_OVERRIDE.
It's secondary lighting set to anything higher than fair that crashes it
Fedora 44 KDE/Wayland, GTX 1070 Ti, NVIDIA 580.178.04, GE-Proton 11-7, build 69913.
Before workaround: world-load crashes/hard black screens, NVIDIA Xid 13, KWin Wayland crash, ErrorDeviceLost, sometimes requiring hard reset. DX11 and DX12 both failed.
Working setup: DX12, Graphics preset 3, Secondary Lighting = Fair, Optional GPU Features = Off, no Config.wtf edits.
Tested for ~2h30m continuously with no crash, no stutter, and no World-latency climb. Latency stayed ~150 ms Home / ~130 ms World.
Interesting performance note: higher graphics settings previously gave better FPS than lower settings in some tests, so performance scaling seems abnormal.
This workaround appears stable on my system so far.
confirmed that i can set everything to max other than secondary lighting (set that to fair) and the game doesnt crash. protonge 11-1 x11 nvidia
I've resorted to making only Skyborne and can play my warrior/druid/hunter now no issues. Seems to be connected to old world zones somehow.
Error logs also always show:
Error: ASSERTSAFE(m_platformInterface != nullptr, ...)
File: d:\BuildServer2\Builder\checkouts\0\WoW\Source\Voice\VoiceSpeakManager.cpp
Line: 179
ProcessID: 1768
ThreadID: 1772
Hash: b0dc81b1
confirmed that i can set everything to max other than secondary lighting (set that to fair) and the game doesnt crash. protonge 11-1 x11 nvidia
Hey thanks! Just tested this, and this workaround works.
It is much better than quality 3 out of 10
With these options maxed out (except secondary lighting) i can easily wait for patched/fixed client
Confirming on my end, setting Lighting to Fair works.
WoW Forever Beta - 1.60.1.69913
OS: Arch Linux, KDE Plasma, Wayland
Runner: GE-Proton-11-6
GPU: Nvidia GTX 3080
Possible workaround: check for an enormous leftover Proton log file:
Adding another Linux Mint data point because I found something that made a huge difference in my case.
While troubleshooting Battle.net/WoW earlier, I had temporarily enabled Proton logging with:
PROTON_LOG=1 %command%
I later removed PROTON_LOG=1 from the Steam launch options and replaced it with MangoHud. However, I didn't realise that the existing Proton log file was still sitting in my home directory.
Today I discovered that the file had grown to approximately 145 GB.
Before deleting the log file, WoW Forever was practically unplayable:
I deleted the ~145 GB Proton log file, which restored roughly 145 GB of free disk space.
Afterwards, the difference in Forever was immediate:
So in my particular case, Secondary Lighting was not the fix, nor were the low graphics settings.
I can't say whether the huge log file itself, the extremely low remaining disk space it caused, or some combination of the two was responsible. But deleting it and recovering the disk space made a night-and-day difference.
If anyone experiencing similar symptoms has previously enabled PROTON_LOG=1, it may be worth checking their home directory for an unusually large steam-*.log file and checking available disk space.
This may not explain the underlying Forever/Linux issues affecting everyone, but it appears to have resolved the severe performance problem on my system.
oh, and this is running on:
System: WoW Forever Beta - 1.60.1.69913
OS: Linux Mint 22.3 (Zena), Cinnamon
Runner: Proton Experimental
CPU: Intel Core i5-10400 (6C/12T)
GPU: NVIDIA GeForce RTX 3060 Ti GDDR6X (8 GB)
NVIDIA Driver: 580.178.04
RAM: 32 GB DDR4
If anyone experiencing similar symptoms has previously enabled PROTON_LOG=1, it may be worth checking their home directory for an unusually large steam-*.log file and checking available disk space.
Based on multiple reports of the logging issue and lighting in this thread, it seems like the summary of this thread is: downgrade lighting, ensure proton logging is off.
The shader loops mentioned here were the unlock, I sent claude to whip up a gist with the fix that worked for me (patching the shaders):
The shader loops mentioned here were the unlock, I sent claude to whip up a gist with the fix that worked for me (patching the shaders):
This fixed my issue. Thank you so much for posting this. I'm using proton-cachyos-native.
❯ fastfetch --logo none --structure os:kernel:cpu:gpu:memory
OS: CachyOS x86_64
Kernel: Linux 7.2.6-1-cachyos
CPU: AMD Ryzen 9 7950X (32) @ 5.88 GHz
GPU 1: NVIDIA GeForce GTX 1050 Ti [Discrete]
GPU 2: AMD Raphael [Integrated]
Memory: 13.67 GiB / 93.45 GiB (15%)
❯ pacman -Q proton-cachyos-native
proton-cachyos-native 1:11.0.20260703-3
Replying to https://github.com/ValveSoftware/Proton/issues/10157#issuecomment-5731204416
Now i have the same problem on my labtop too.
the solution was, the grafics on the lowest to join a realm, then ingame it was possible to set them on a higher level.
I swapped in-game video setting from DX12 to DX11 and I was able to load the world/character. Was not able to load with DX12.
WoW Classic beta (build 69913) hangs GPU on entering world — NVIDIA, Linux/Proton. Retail works.
GPU / OS: RTX 2070 (Turing), Ubuntu 24.04, kernel 7.0.0-34, X11
Drivers tested: 595.91.07 and 610.57.04 (open kernel modules). Same result on both.
Proton tested: GE-Proton10-29 and GE-Proton11-7, via Faugus/umu. Same result on both.
Behavior: character select works. Hangs at the 100% loading bar entering the world. WoW's WatchdogThread then asserts (0xC0000420) and the game closes to desktop.
Kernel log (every time): NVRM: Xid 109, name=WowB.exe, errorString CTX SWITCH TIMEOUT
Ruled out: D3D11 (DXVK) and D3D12 (vkd3d); lowest graphics preset; windowed 1080p; VSync off.
Control: Retail (Midnight) on the same prefix, Proton, driver and hardware loads into the world normally.
This extends the GTX 1070 (Pascal) report above to Turing, so it isn't limited to one GPU generation.
Blizzard patched it this evening around 8:00 EST.
Blizzard patched it this evening around 8:00 EST.
Confirmed I can now make and play other races without crashing. I am considering this closed now, unless anyone else has any crashing issues still? I will close this later today if everyone else is good now. Thanks for everyone's replies and help with the issue, plus temp solutions until Blizzard fixed it. <3
I will close this later today if everyone else is good now.
I think compat threads stay open indefinitely. Especially considering WoW Forever hasn't released yet, I would leave this open. @kisak-valve can you comment on this?
World of Warcraft Classic Beta / WoW Forever (non-Steam, Battle.net) — native ARM64 client fails to start on Proton ARM64
Issue transferred from https://github.com/ValveSoftware/Proton/issues/10173.
@aanze posted on 2026-09-24T14:36:57:
wow_classic_betaexperimental-11.0-20260917b-arm64 (also tested: Proton 11.0-2 (ARM64), Proton Experimental x86_64 via FEX)Battle.net itself works well on ARM64 (login, install, patching). When the game is launched from an ARM64 Proton build, Battle.net detects an arm64 OS and installs/launches Blizzard's native ARM64 client (WowB-arm64.exe, PE machine 0xAA64; install tagged Windows arm64). The game fails at startup with "Game initialization failed".
Results per Proton build:
| Proton build | Client launched | Result |
|---|---|---|
| Proton Experimental x86_64 (via FEX) | WowB.exe (x64) |
Immediate crash, BREAKPOINT inside WowB_loader.dll (3 frames, main thread, before any game code runs) |
| Proton 11.0-2 (ARM64) | WowB-arm64.exe |
gx.log: LoadLibrary(dxgi.dll) Failed (HR:0x000000C1) Bad EXE format → "No suitable gpu found" |
| Proton Experimental (ARM64) | WowB-arm64.exe |
"Game initialization failed" dialog, ~100 ms after process start, before any graphics init |
Finding 1 — Proton 11.0-2 (ARM64) cannot run pure-ARM64 D3D12 apps.
In Proton 11.0-2 (ARM64) and in proton-cachyos-11.0-arm64, lib/wine/dxvk/aarch64-windows/dxgi.dll and lib/wine/vkd3d-proton/aarch64-windows/d3d12.dll are ARM64EC (PE machine 0x8664). A pure ARM64 process cannot load them, so the game fails with ERROR_BAD_EXE_FORMAT. Proton Experimental (ARM64) ships pure ARM64 (0xAA64) versions of those DLLs, and with it dxgi/d3d12 load correctly. Suggest shipping pure ARM64 (or ARM64X) DXVK/vkd3d-proton in the stable ARM64 branch as well.
Finding 2 — with Proton Experimental (ARM64), the game exits during a TLS callback.
From the PROTON_LOG=1 log (attached), for the WowB-arm64.exe process:
1842.278 loaddll: Loaded WowB-arm64.exe at 0000000140000000: native
(then ntdll, kernelbase, kernel32, ucrtbase, sechost, msvcrt, advapi32, win32u, gdi32, user32, imm32)
1842.371 seh: code=c000001d (EXCEPTION_ILLEGAL_INSTRUCTION) addr=000000014000D3C4
-> vectored handler in WowB-arm64.exe (+0x2CCB8) returned ffffffff (continue execution)
1842.371 seh: code=c000001d (EXCEPTION_ILLEGAL_INSTRUCTION) addr=000000014000D844
-> same handler, returned ffffffff
1842.372 seh: code=c0000005 (EXCEPTION_ACCESS_VIOLATION) addr=0000000140005060, read of 0x000000000000000D
-> handler returned 0; backtrace: WowB-arm64.exe +0x5060 <- +0xD2E4 <- +0x1015C <- +0xB048 <- ntdll+0x44294
-> caught by ntdll __except, execution continues
1842.373+ winex11.drv, uxtheme, rpcrt4, combase, ole32, oleaut32, comctl32, msimg32 load
-> "Game initialization failed" dialog is shown
0x4028, and the failure happens there, before the entry point (RVA 0xB1868). This appears to be the game's own startup/anti-tamper code (the x64 client's equivalent is WowB_loader.dll).fixme: or err: lines are logged for this process, so no unimplemented API is reported.Logs/ untouched), because the failure happens before its logging starts.gx.log): Windows 10 (10.0.19045.5796) [Wine (11.0.0) Linux 7.2.6] arm64, Vendor:? | Microcode:0x0, features neon armv8 aes pmull sha1 sha256 crc32 atomicsv81 dotprod8 jscvt.Since Blizzard ships and auto-selects a native ARM64 Windows client, this looks like the first case of a real-world pure-ARM64 Windows game in Proton's ARM64 builds. It may be useful to Valve/CodeWeavers, or as a contact point with Blizzard.
Battle.net-Setup.exe as a non-Steam game, force Proton Experimental (ARM64), install Battle.net, then point the shortcut to Battle.net Launcher.exe.wow_classic_beta). Battle.net installs the Windows arm64 build (WowB-arm64.exe + D3D12_ARM64/).dxgi.dll load fails with 0xC1 (_classic_beta_/Logs/gx.log).Notes:
WINEDLLOVERRIDES=dxgi=n by default, and launch options go through the distro wrapper (/usr/libexec/armada/armada-game-launch %command%). The Steam overlay fails to preload (unrelated).I've created a simple script that patches turnip so WoW Forever doesnt crash while shaders are being compiled and updates the WoW shortcut with required parameters to run the game. Additionally it fixes one issue with ntdll crashing on Steam Frame for some reason.
https://gist.github.com/jareqpl/01752a3eb0a527a7fd285d3ec589814b
The whole patch is single bash file that downloads the custom proton and sets the game for you.
You can report the turnip issue on the mesa tracker https://gitlab.freedesktop.org/mesa/mesa/-/work_items
proton experimentalx9 2026-09proton 11.0-2x1 2026-09ge-proton11-7x10 2026-09ge-proton10-29x1 2026-09proton 3.1x1 2026-09ge-proton10-34x2 2026-09ge-proton9-21x1 2026-09PROTON_LOG=1x3 2026-09WINEDLLOVERRIDES=dxgi=nx1 2026-09VKD3D_SHADER_OVERRIDEx3 2026-09VKD3D_CONFIG=single_queuex1 2026-09PROTON_LOGx1 2026-09DXVK_CONFIG=dxvk.enableDescriptorHeap=Falsex1 2026-09VKD3D_DISABLE_EXTENSIONS=VK_EXT_descriptor_heap,VK_EXT_descriptor_bufferx1 2026-09PROTON_DISABLE_NVAPI=1x1 2026-09PROTON_LOG=0x1 2026-09DXVK_FILTER_DEVICE_NAME=Intelx1 2026-09VKD3D_FILTER_DEVICE_NAME=Intelx1 2026-09PROTON_ENABLE_NVAPI=1x1 2026-09PROTON_USE_NTSYNC=0x1 2026-09PROTON_USE_NTSYNC=1x1 2026-09dxgi.dllx8 2026-09d3d12.dllx1 2026-09wowb_loader.dllx1 2026-09d3d12core.dllx6 2026-09winevulkan.dllx5 2026-09d3d11.dllx3 2026-09nvapi64.dllx1 2026-090xc0000420x1 2026-090x8510006dx4 2026-090x80070102x3 2026-09
Title: Xid 13 GPU hang / hard system lockup on WoW Forever (Classic Beta build 69913) — GTX 1070, both DX12 and DX11
GE-Proton version: GE-Proton10-34 and GE-Proton11-7 (both tested, same result)
Game: World of Warcraft: Forever (Classic Beta), build 69913, launched via Battle.net
GPU: NVIDIA GeForce GTX 1070 (Pascal), driver 580.178.04, PCI ID 0x1B81
System: CachyOS (Arch-based), kernel with CONFIG_NTSYNC enabled
Launch options tested:
All three produce the same failure.
Behavior: Crash is immediate and consistent — login, choose character, and the game locks up on the 100% loading screen/bar itself before ever visually entering the world. This is not a crash after play — it happens on the loading screen, every time. Most attempts result in a full system lockup requiring a hard reset; one attempt was instead caught by the game's own internal watchdog as a "graceful" crash to desktop (see below) rather than hanging the OS.
Kernel log (every crash):
NVRM: Xid (PCI:0000:01:00): 13, pid=, name=WowB.exe, Graphics Exception: channel 0x..., Class 0000c1c0, Offset ..., Data ...
Preceded by:
nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: 0x0000927c:...
Game's own crash log (from the one graceful catch):
ERROR #109 (0x8510006d) A thread has become unresponsive.
Freeze Detected: thread frozen for 20 seconds
Stack: winevulkan.dll -> d3d12core.dll (x2 frames) -> dxgi.dll (x3 frames) -> WowB.exe
Also notable: GxRestarts: 2, GxFailedFrameStartRestarts: 1, GxDeviceLostCount: 1 — the D3D12 device was already lost and recovered once earlier in this same short session before permanently hanging. Note the log's internal TimeInWorld counter shows a small nonzero value despite the loading screen never having visually cleared — this appears to be an engine-side counter quirk, not an indication of actual world entry.
Reproduces on both DX12 (vkd3d-proton) and DX11 (dxvk), suggesting the fault may sit in winevulkan.dll's interaction with the Pascal driver rather than being specific to either D3D translation layer. No other games (No Man's Sky, Diablo II: Resurrected) exhibit this issue on the same system.
Not yet fully isolated: whether PROTON_ENABLE_NVAPI=1 is a contributing factor, since it was present in the one graceful-crash case; the hardest lockup occurred on DX11 without it, so it doesn't appear to be the sole cause.