CHANGELOG
I’m editing this post rather than reposting, so this is what changed and when. If you’ve read it before, skip to the first date you haven’t seen. Everything below the changelog is the current state of things.
5 October — build 1.60.1.70235: fault 1 still present, and a model I’m putting forward as a guess
- Fault 1 is still here. Yellow banding on Stormwind stonework at Secondary Lighting Fair, still present at High — in a different place. The setting didn’t change it; the rebuild re-rolled it. A setting toggle is a cheaper re-roll than
gxRestartand worth knowing about, because “I changed the setting and it moved” is exactly what someone reads as “the setting affects it.” - Observed: changing Secondary Lighting from Fair to High left the corruption present and moved it somewhere else. With Secondary Lighting Disabled on .69893 and .69913 I measured true zeros. Shadow Quality Low shows less corruption than Ultra High, and the shadows are still green at Low.
- Guess, not a finding — the additive model. If the corruption is a baseline underneath and lighting and shadows lay color on top of it, then settings would change what gets added without changing what’s underneath. If that’s right, two things that have looked contradictory in this thread are both true: no setting fixes it, and settings visibly change what you see. It would also mean someone who drops Secondary Lighting and sees less hasn’t fixed anything. I can’t verify any of that from outside the client.
- Shadow Quality is not a reversal. Low shows less because less is being drawn, not because the setting controls the fault. The shadows are still green at Low. The tested-and-eliminated list below stands as written.
- Menethil Harbor accumulation, with the clock in frame. Fixed camera, 11.3 / 57.3,
gxRestartclears it and it rebuilds to full inside a minute with nothing moving but time. It is not a repro location — a fresh session at the same coordinates was clean. - Fault 9:
gxRestartresets the accumulated coverage. First mitigation that fault has ever had. It re-rolls rather than fixes, but the coverage starts over. - Two structural hypotheses eliminated on the boundaries. Not a uniform world grid — the regions are different sizes. Not distance-based — building-sized regions sit next to regions smaller than a character’s head, at the same distance.
- Fault 23 narrowed, and it’s now the easiest thing in this thread to reproduce. The condition isn’t “under a roof” — it’s any outdoor area visible on screen. Turn until none is in frame and the rain stops. Reproduced in two different buildings. No session state, no hardware dependency, instant on and off.
- Fault 21 I can’t verify here. I see no visible difference between Secondary Lighting Fair and High on my machine, so I have nothing to compare. Someone who can see that difference needs to run it.
4 October — four new faults, two cleared, and fault 9 renamed
- Faults 17 and 20 do not reproduce on 70205, and this time the rain was real. Four cells run in actual precipitation, no crash on any. The objection that killed the 70058 result — that the rain had been reduced to almost nothing — does not apply here; the rain on this build is heavy enough to put impact ripples on water.
- Fault 9 renamed to “shadow map calculation and application.” The old name described one presentation out of four. New finding: it accumulates. Four frames over two minutes standing completely still, camera untouched, coverage growing until most of the ground is dark — with the lighting constant across the sequence as the control.
- New fault 23: rain renders indoors, through a roof. Rain audio is correctly muffled at the same time and place, so the client knows you’re under cover. Progression rather than regression — the audio is new and it’s right.
- New fault 24: Stormwind canal water has no ambient wave animation. The harbor is fine. Both liquid settings do nothing at any step. Rain impact ripples on the same water render correctly, so the surface isn’t broken — only the wave animation is missing.
- New fault 25: periodic 15-20 second freeze, roughly hourly, usually in combat. One reporter. Not fault 13 — that had a trigger and is fixed.
- New fault 26: sun-colored orbs off reflective surfaces and in gaps. Observed: they shift position when the foliage in front of them sways. That would account for the “flashing” two other people reported, though I haven’t confirmed it’s the same thing they’re seeing.
- Two corrections to my own posts, both below: the Orgrimmar bridge citation, and the M1 finding.
3 October — build 1.60.1.70205: fault 1 much reduced, two new faults, and a split between Max and base silicon
- Fault 1 is much reduced and not gone. Ten renderer rebuilds and three cold starts across Duskwood, Redridge, Stormwind and Ironforge, no corruption on any of them, nothing above 78C. That’s the first clean sweep in eight builds. Five other people are still reporting it on this build, including the first M1 report this thread has ever had.
- I’m correcting something I published. My sweep of this thread’s first 360 posts found six M1 owners and none of them reporting fault 1. There is now an M1 Max report. That was an absence of reports, not an absence of the fault.
- New fault 21: Secondary Lighting renders at High regardless of what the setting says. Found by Voidbeam, confirmed in code by Rommax — raid and non-raid lighting settings are swapped. This one has a workaround and it is costing a lot of people a lot of frames. It is also not Mac-specific; two Windows reporters have it, one with a measured GPU-usage change on an RTX 3080.
- New fault 22: performance regression on base Apple Silicon. Max and Pro parts improved on this build. Base parts — M4 Air, base M5, base M6 mini — got substantially worse. Not reproducible on my hardware; I’m one of the machines that got better.
- Secondary Lighting can now be run at High by several reporters without the frame-rate collapse that made Fair the standing advice. Most playable configuration updated.
- Faults 17 and 20 still untested on this build — I haven’t found rain. Assume both apply.
- A caveat on my own method: one reporter says running the Metal HUD makes the graphics faults disappear entirely. I have been recommending the HUD in this thread for weeks. See trap 7.
2 October — fault 1 has a boundary, and the boundary holds still
- The corruption has edges, and the edges are anchored in the world. Three states in one frame — black, magenta, and normal — meeting on a single character model.
- It is channel death in order. Green dies first, giving magenta. Push further and red and blue follow, giving black. Magenta measures green at a fixed 0.077–0.080 of red across three independent captures.
- It is two discrete states, not a gradient. Histogram of 1.6M pixels shows two populations with a 3% gap between them. Whatever decides which side you’re on is making a yes-or-no decision.
- One edge cut terrain, my character model and my equipped weapon identically — three different draw calls, one boundary. It is attached to the space, not to any object.
- I walked into it. In a follow camera your screen position and camera distance both stay constant while you run, so something that changed as I walked is tied to world position.
- It does not survive a renderer rebuild.
gxRestartor a relog and it is somewhere else, or gone. So the fault is decided once per session and stays decided — which reframes six builds of “intermittent, no trigger” as one non-deterministic thing being rolled at renderer init.
1 October — build 1.60.1.70170: color corruption unchanged, and red-dominant this time
- Fault 1 still present, red-dominant in Elwynn — green and blue both dying. Most extreme channel loss measured: open ground R 41.51 / G 1.93 / B 7.35, green at 5% of red. Across the whole world render only 0.4% of pixels have green exceeding red. UI correct in the same frame.
- Fault 9 still present — shadow bands still move with the camera, up to 1.51× brightness across a band edge.
- Fixed: fault 13, the mining node freeze. Eight depletions, five of them in combat, no freeze. Combat was the condition every previous reproduction had.
- Still present: fault 14, fault 19. Fault 15 still not reproducible here.
- Faults 17 and 20 untested — no rain found.
30 September — build 1.60.1.70124: no marked change for macOS
- No change: faults 1, 9, 12, 14. Holding fixed: 16, 18. Fault 13 reproduced again in combat.
- Fault 17 came back, and I think 70058 masked it rather than fixed it. The rain on 70058 had been reduced to almost nothing; on 70124 it rendered properly and the crash returned with it. So the variable may be how much precipitation is being drawn. Fault 20 reproduced too, which removed the evidence that had separated 17 from 20.
29 September — build 1.60.1.70058: two faults fixed, fault 1 worse, one new fault
- Fault 16 fixed, with numbers. Stutter events 8.9% → 3.6%, GPU 19.74 → 17.36 ms on the protocol that previously showed +33.8% GPU and 6.4× stutters — and it now recovers on its own across a 36-minute round trip with no
gxRestart. Memory came apart from performance and is its own open question. - Fixed: fault 18 (ghost shadows), across all three configurations that isolated it.
- Fault 1 is channel attenuation and that is all it is — separate from the exact-zero black rendering fixed on 70009.
- New fault 19 (Render Scale costing frames, not reproducible here). New fault 20. Retracted fault 7 entirely — god rays scaling up with quality is a quality ladder working correctly.
25 September — “ghost shadows” identified, fault 7 retraction, two new faults
- New fault 18: Fullscreen (Windowed) below native breaks shadow and light rendering. (Fixed on 70058.) New fault 17:
gxRestartcrashes during precipitation. - The exact-zero test I gave everyone is retired — it now returns false negatives. Replacement in trap 6.
- Negatives: View Distance 1 is not slower (that was drift); windowed mode does not avoid the corruption; fog does not clear it.
24 September — build 1.60.1.70009: four faults fixed
- Fixed: faults 5, 10 and 11 — foliage, water and character silhouettes, all measured at 0.000% exact-zero pixels where they previously ran 39–99%. They went together, which confirmed a shared cause.
- Fixed: fault 7 (partly retracted 25 Sept). New: fault 16 (largely fixed 29 Sept). New: faults 14 and 15.
22–23 September — restructured, earlier builds
- Faults 3 and 4 fixed on 69977. Fault 4 was the kernel panic; all four Compatibility Settings now run enabled.
- New: faults 9, 10, 11, 12, 13. Faults 2 and 6 retired, merged into fault 1 — the corruption is present in the intro cinematic, on a brand-new character, in a never-loaded zone, with all four Compatibility Settings enabled. Numbers are retired rather than renumbered so earlier replies still resolve.
How this post is organized: changelog → full fault list → faults grouped by class → the testing behind each → hypothesis at the end.
Up front: I’m not a graphics engineer. I’m a network engineer by trade and I build games as a hobby, mostly in Unreal. I used Claude to help read the kernel panic logs and organize this write-up.
So: everything marked as an observation, a measurement or a test result is something I did and saw directly. Where I’ve guessed at a mechanism I’ve said so explicitly. Treat the guesses as guesses — the testing stands on its own either way.
Current issues
Everything still live as of build 1.60.1.70235.
| # | Trigger | Symptom | Status on 70235 | Workaround |
|---|---|---|---|---|
| 1 | None known | One color channel scaled down while the others hold | Still present.Reported by many others | No |
| 8 | Shadow Quality Fair or higher | Shadows offset and oversized — Pallysan’s finding | Not re-testable on my hardware | Unknown |
| 9 | Camera distance, camera angle, time standing still, low sun angle | Shadow map not fully calculated or applied. Hard boundary at a fixed camera distance; blocky wedge and triangle regions matching no caster; at Fair, static geometry stops casting while characters still cast. Coverage grows over ~2 min while stationary | Still present, better characterized | gxRestartresets the accumulated coverage |
| 12 | Character culled at distance | Their pet stays rendered | Still present | No |
| 14 | Clicking away during startup | Login panel never renders | Still present — also reported on multi-monitor setups | Yes — restart the client |
| 15 | Crossing zone borders | Client hangs indefinitely | Not reproducible on my hardware | Yes — gxRestart, macro it first |
| 19 | Render Scale below 100% | Frame rate falls instead of rising | Not reproducible on my configuration | No |
| 21 | Every login | Secondary Lighting renders at High no matter what the UI says. Costs frames on anything that can’t afford High | Others’ finding — I cannot verify it on my machine, see below | Yes — see below |
| 22 | Build 70205 on base silicon | Frame rate roughly halved on M4 Air, base M5, base M6 mini. Max and Pro parts improved | Still reported | No |
| 23 | Indoors with any outdoor area visible on screen, while it rains | Rain renders inside. Turn until nothing outdoors is in frame and it stops. Rain audio is correct throughout. Reproduced in two buildings | Easiest fault here to reproduce | No |
| 24 | The Stormwind canals | Canal water renders with no ambient wave animation; reflections track the camera rather than the light. Rain ripples on the same water are correct. Harbor unaffected | Still present | No |
| 25 | None identified — roughly hourly, usually in combat | Client freezes 15-20 seconds, then recovers | Single report, not reproduced | No |
| 26 | Sunlight through or off something, outdoors | Bright sun-colored orbs off reflective surfaces and in gaps. They move when the foliage in front of them sways, and flash as gaps open and close | Still present | Reported — Image-Based AA |
On the Workaround column: “Yes” means there’s something you can actually do about it today. It does not mean the fault is acceptable — several of these cost you a setting you’re entitled to use.
Faults 8, 15, 19, 21, 22 and 25 are other people’s, included because the tests are sound and the results are specific. Everything else was verified on my machine.
Fixed, resolved and retired
Kept so earlier replies in this thread still resolve, and so anyone on an older build knows what they’re looking at.
| # | Trigger | Symptom | Closed |
|---|---|---|---|
| 2 | — | Retired — merged into fault 1 | 23 Sept |
| 3 | FIXED 69977 | ||
| 4 | FIXED 69977 | ||
| 5 | FIXED 70009 | ||
| 6 | — | Retired — merged into fault 1 | 23 Sept |
| 7 | — | RETRACTED — god rays scaling up with quality is correct behavior, not a fault | 29 Sept |
| 10 | FIXED 70009 | ||
| 11 | FIXED 70009 | ||
| 13 | FIXED 70170 | ||
| 16 | FIXED 70058 | ||
| 17 | /console gxRestart during precipitation |
RESOLVED 70205 — tested in real rain | |
| 18 | FIXED 70058 | ||
| 20 | RESOLVED 70205 — tested in real rain |
Numbers are never reused. They’re what people have been replying by, so a retired or fixed number stays retired.
The faults, grouped
Numbers are stable identifiers — they’re what people have been replying by, so I haven’t renumbered. The grouping is itself information: these are not twenty-two unrelated bugs.
Class A — color channel corruption
| # | Trigger | Symptom | Workaround |
|---|---|---|---|
| 1 | None known | One color channel scaled down while the others hold. Present from the first rendered frame, in the intro cinematic, on new characters, in never-loaded zones, with any settings | No |
2 and 6 retired — merged into 1.
Class B — geometry rendering at exactly (0,0,0) — all fixed
| # | Trigger | Symptom |
|---|---|---|
| 5 | Shadow Quality above Low | Foliage renders as flat black silhouettes |
| 10 | Water contact, or changing Shadow Quality | Water renders solid black |
| 11 | Camera distance; characters streaming in | Character models render as pure black silhouettes |
All three went together on 70009, which confirmed they shared a cause.
Class C — shadows
| # | Trigger | Symptom | Workaround |
|---|---|---|---|
| 18 | Fullscreen (Windowed) + below native | The “ghost shadows” — FIXED 70058 | — |
| 7 | — | God rays — RETRACTED, not a fault | — |
| 9 | Camera distance, camera angle, time, low sun | Shadow map not fully calculated or applied — boundary at a fixed camera distance, blocky regions matching no caster, static geometry not casting at Fair. Accumulates while stationary | No |
| 8 | Shadow Quality Fair or higher | Shadows offset and oversized — Pallysan’s finding | Unknown |
Class D — lighting and performance
| # | Trigger | Symptom | Workaround |
|---|---|---|---|
| 21 | Every login | Secondary Lighting renders at High regardless of the setting | Yes |
| 22 | Build 70205, base silicon | Frame rate roughly halved | No |
| 26 | Sunlight through or off something | Sun-colored orbs tracking occlusion rather than world position | Reported — Image-Based AA |
| 16 | Accumulates during play | GPU time +33.8%, stutters 6.4× in ~2 min — FIXED 70058 | — |
| 19 | Render Scale below 100% | Frame rate falls instead of rising | No |
Class E — everything else
| # | Trigger | Symptom | Workaround |
|---|---|---|---|
| 12 | Character culled at distance | Their pet stays rendered — floating minion, no owner | No |
| 13 | Final hit depleting a mining node | 10–15 second freeze — FIXED 70170 | — |
| 14 | Clicking away during startup | Login panel never renders | Yes — restart |
| 15 | Crossing certain zone borders | Client hangs indefinitely | Yes — gxRestart |
| 17 | gxRestart during precipitation |
— | |
| 20 | — | ||
| 23 | Indoors with any outdoor area on screen while it rains | Rain renders inside; turn away from the opening and it stops | No |
| 24 | The Stormwind canals | Canal water has no ambient wave animation | No |
| 25 | None identified, roughly hourly | 15-20 second freeze, recovers on its own | No |
Fixed in earlier builds: 3 (horizontal banding, Optional GPU Features) and 4 (kernel panic, Secondary Lighting above Fair), both on 69977.
From the player’s side these all look like one bug. That may be part of why the workaround threads here contradict each other — people fix one and still have the others.
Most playable configuration
This is a mitigation, not a fix. It’s the settings that trip the fewest faults. Updated for 70205.
Shadow Quality ......... Good or above ← god rays are a Good+ feature, by design
Secondary Lighting ..... High ← now viable on 70205 for most reporters
All four Compatibility Settings . ON
Render Scale ........... 100% ← see fault 19
Everything else ........ 10 / maximum
Do this on every login, before you judge your frame rate — fault 21.
Secondary Lighting: set it to High, Apply, then set it back to where you want it
On every login the UI shows your setting while the renderer runs High. That toggle re-syncs them. The longer-term workaround per Rommax: enable raid settings and set them to match your non-raid settings.
If you lost frames on 70205, do that toggle before reporting anything. It is the single biggest frame-rate item on this build and it will be sitting underneath whatever else you’re measuring.
Changed on 70205: Secondary Lighting at High is now reported workable by several people on Max and Pro parts, where Fair was the standing advice since the fault 4 kernel panic. If you’re on base silicon, see fault 22 before raising anything.
Changed on 70058: the Display Mode restriction is gone — fault 18 is fixed. On older builds that restriction still applies — use Windowed when running below native.
The rain warning is lifted from 70205 onward. /console gxRestart and Optional GPU Features both tested clean in real precipitation, all transitions. On 70124 and earlier it still applies — don’t run either while it’s raining or snowing.
Nothing here touches the color corruption. I got this wrong initially and want it stated plainly: I ran ten minutes clean outdoors on an earlier config and called it fixed, then it tinted in Stormwind within 10–30 seconds. It’s present in the intro cinematic before you’ve entered the world. No setting has ever stopped it.
/console gxRestart clears it sometimes. It is not reliable, and what it actually does is re-roll — see the boundary section below. Use it as a mitigation, never to rule things out.
Seven things that make testing this misleading
These wasted hours of my time and I think they explain most of the contradictory reports on this forum.
1. Any renderer reset buys a clean window — and a setting toggle is one. Toggling a setting, sliding quality down and up, loading a zone, or gxRestart all flush the accumulated corruption and give you correct rendering for a while. That reads as a fix and then stops working. I nearly posted a “fix” that was just this.
On 70235 it didn’t even buy a clean window — it relocated. Changing Secondary Lighting from Fair to High left the corruption present and put it somewhere else. If you change a setting and the corruption moves, that is the rebuild re-rolling it, not the setting affecting it. A setting toggle is in fact a cheaper way to force a re-roll than gxRestart — two clicks, no reload.
Useful baseline: from a stationary camera outdoors, corruption returns to full in about a minute — in Stormwind, 10–30 seconds. If you post a fix here, say how long you ran it and where.
2. Some settings need a full client restart and some don’t, and they sit next to each other. Optional GPU Features needs a restart in both directions. Advanced Work Submit applies live. Toggle both in one session and you get one live change and one stale value. Restart between every change.
Worse: changing Optional GPU Features and then rebuilding the renderer crashes the client, and before the rebuild rain renders as broad diagonal bands.
3. A zone’s palette can hide the fault, or mimic it. Tirisfal’s green-gray hid a green cast and I posted that a fresh character there was clean — it wasn’t. Durotar’s orange hides red-dominant corruption so thoroughly the zone looks correct while measuring badly wrong. Don’t judge on terrain. Judge on something whose color isn’t in question, and prefer a paired control: same spot, same camera, one variable, two screenshots.
4. A reboot is not a bigger gxRestart. A character parked in the Deeprun Tram wedged my machine. Kernel panic, reboot, fresh client — the same character still wouldn’t load. A different character loaded fine. One gxRestart on that character, and the stuck one then loaded normally.
The fault survived a kernel panic, a power cycle and a fresh client launch — but not a renderer restart inside the running client. Don’t treat “I rebooted and it’s still broken” as ruling out renderer state.
Firmware confirms both hard power-offs:
2026-09-22 10:49:28 Boot faults: rst btn_rst,btn_seq_reset target_off_restart
2026-09-22 10:52:20 Boot faults: rst btn_rst,btn_seq_reset target_off_restart
To reproduce: ride the Deeprun Tram and run /console gxRestart while it’s moving. On my machine that’s a hard power-off, then a second one when you try to log that character back in. Don’t do it with unsaved work open.
5. What makes a gxRestart clear it permanently hasn’t been worked out. Sometimes it clears for the session, sometimes for under a minute, sometimes nothing. I’ve tested screen content at the moment of restart, asset count in view, location, altitude, and timing relative to login. None is the variable.
Confirm you can still reproduce the bug without your fix, in the same session. Otherwise you may have caught a full clear, or a clean session, and credited whatever you were doing at the time. I think that’s most of why the fixes in this thread don’t replicate for each other.
6. The exact-zero test I gave everyone is retired, and it now returns false negatives. Nothing since 70009 measures exact zero, so running it on foliage that is unambiguously black reports “merely dark” and you conclude it’s fixed. I nearly withdrew the fault 5 fix over this.
What works instead — local contrast. Measure how dark a tuft is relative to its own immediate surroundings, which doesn’t care how dark or how cast the scene is:
tuft brightness relative to its own ground
known-good frames 0.481 0.500 0.525
Shadow Quality Good 0.448
Shadow Quality Ultra High 0.448
old build, real fault 5 0.184 0.297 0.358 0.460
General point this cost me a day to learn: any metric that filters on the thing you’re measuring will find what you’re looking for. I once reported a channel as “pinned” using absolute standard deviation, when a channel sitting at mean 14 simply cannot spread as widely as one at mean 93. Normalize before you compare channels.
7. NEW — the Metal HUD may be hiding the thing you’re trying to capture. One reporter on an M5 Max Studio says that running the HUD makes the graphics faults disappear entirely, and that anyone trying to reproduce anomalies should turn it off.
I have been recommending the HUD in this thread for weeks, including for the frame-rate methodology below. If that reproduces, some of my own captures were taken with the fault suppressed, and so were other people’s. I haven’t verified it and I’m not treating it as established — but it needs a second pair of eyes before anyone runs another capture session, and if it holds it’s also a lever on the bug rather than just a nuisance.
Fault 1 — color channel corruption (absorbing retired faults 2 and 6)
Much reduced on 1.60.1.70205 and not gone.
My own result on this build: three hours across Duskwood and Redridge, ten renderer rebuilds, three cold starts, no corruption, nothing above 78C. That is the first clean sweep in eight builds and I am not calling it fixed on one session — particularly given what the boundary finding below says about re-rolling.
Still being reported on 70205, with hardware:
M1 Max, 32 GB, macOS 26.6.2 green shadows and hue, Stormwind
M5 Max Studio 40c, 64 GB, 27.0.1 green shadows plus light green geometric shapes,
Durotar, ~8am realm time, present from the start
M5 Max Studio 40c, 64 GB, 27.0.1 Barrens green, far lighter than previous builds
M5 Pro Mac Mini, 27.0.0 yellow tint appearing and disappearing at a fixed
point on the Orgrimmar bridge
M4 Air induced green and texture corruption by toggling
the compatibility boxes; could not repeat it
A correction to something I published. I posted a sweep of this thread’s first 360 posts showing six M1 owners and not one of them reporting fault 1, and I drew a hardware inference from it. There is now an M1 Max report. That was an absence of reports, not an absence of the fault, and the inference was weaker than I presented it.
What I measured about the lighting settings
Observations, 5 October and earlier. No interpretation in this block.
Secondary Lighting Fair -> High corruption still present, in a different
place. Not cleared, relocated
Secondary Lighting Disabled true zeros measured, .69893 and .69913.
That option was removed in a later build
Shadow Quality Low less corruption visible than Ultra High.
The shadows are still green at Low
any setting change forces a renderer rebuild, same as
gxRestart, and the corruption lands
somewhere new
One thing that follows directly from the first row: if you change a setting and the corruption moves, that’s the rebuild, not the setting. A setting toggle is a cheaper way to force a re-roll than gxRestart — two clicks, no reload.
A model for that, offered as a guess
Everything in this section is interpretation. I have no access to the source and no way to test any of it from outside the client.
the corruption a baseline, underneath
lighting / shadows add color on top of it
If that’s the shape of it, settings would change what gets added without changing what’s underneath.
If it’s right, two things that have looked contradictory in this thread since week one would both be true at the same time: no setting fixes it, because the baseline doesn’t move — and settings visibly change what you see, because they change what’s laid over it.
It would also fit the true-zero measurement. Remove the layer that adds color and the baseline would read as nothing rather than as a tint.
And on Shadow Quality: less shadow and lighting work drawn would mean less surface carrying added color, which is what Low versus Ultra High looks like. The shadows staying green at Low is the part that makes me think the setting isn’t controlling the fault itself.
What this would mean for the fixes posted in this thread, if it holds. Someone drops Secondary Lighting, sees dramatically less, and reports a fix. Under this model they’d be seeing less of the same fault rather than less fault — which would look identical from where they’re sitting, and would stop working the moment they turned the setting back up. That’s a prediction, not an accusation. If someone’s lighting fix has held across sessions and rebuilds, that’s evidence against this model and I’d want to hear it.
I don’t think lighting is the cause, and I want to be careful about how little that’s worth. Necessary to see it isn’t the same as causing it. The fault is in the intro cinematic before the character loads, on brand-new characters, in zones never loaded.
One caveat against myself: the two things that never get corruption — the UI and the skybox — are the two things not lit by scene lighting. They’ve held as invariants across every build and every capture I’ve taken, and that cuts toward lighting being involved rather than away from it.
So: I’m not convinced lighting itself is the cause. That’s a feeling, not a finding.
Menethil Harbor, 5 October — the accumulation curve with a clock in frame
Fixed camera, fixed position, Menethil Harbor 11.3 / 57.3, in-game clock running 5:45 to 5:46. Nothing moved but time.
gxRestart clears it. It rebuilds to full inside a minute from a stationary camera, which matches the one-minute baseline I published weeks ago, now on 70235.
The stone wall in frame shows vertical banding — several distinct color states on one continuous flat surface with hard edges between them.
The wall isn’t the victim, it’s the only legible surface. The banding is scene-wide. On foliage and terrain the underlying color variation hides the edges; a flat uniform man-made wall is the one thing in frame that can’t hide it. Same principle as the sky and UI invariants — judge on the surface whose correct color isn’t in question.
It is not a repro location. A fresh client load, new session, same coordinates, was completely clean. The location isn’t the variable. The session roll is.
Boundary structure — two hypotheses eliminated
uniform world grid NO — the regions are different sizes
distance-based cascades NO — building-sized regions sit directly next to
regions smaller than a character's head, at the
same distance
Both ruled out by direct observation. What’s left is the description, and I’m not going to guess past it:
Hard-edged regions on open ground, adjacent to each other, ranging from building-sized down to smaller than a character’s head, with no relationship to distance from the camera or the player.
The boundary — 2 October, build 70170
The most structural thing found on this fault so far.
Three states in one frame, on one character model — part black, part magenta, part normal, with edges between them. Not blended.
They are one thing at three strengths. Green dies first, which gives magenta. Push harder and red and blue follow, which gives black.
state channels alive green as a fraction of red
normal R, G, B 0.18 – 0.21
magenta R and B, green gone 0.077 – 0.080
black all three gone —
The magenta coefficient is fixed. Three independent captures, different zones, different sessions: 0.079, 0.077, 0.080. And in one of them blue is identical between the magenta and normal regions — only green moves. So magenta isn’t a tint over the image, it’s green scaled by roughly one twelfth while the other two channels are left alone.
It is two discrete states, not a gradient. Histogram of green survival across 1.6 million pixels in one frame:
green/red 0.05 – 0.15 336,317 px corrupted
green/red 0.15 – 0.20 11,722 px <- gap
green/red 0.20 – 0.75 ~1,100,000 px not corrupted
Three percent of pixels sit between the two peaks. Anything scaling smoothly — distance, brightness, angle — would fill that gap. Whatever decides which side you’re on is making a yes-or-no decision.
One edge caught three different kinds of asset at once: the terrain under me, my character model, and my equipped weapon. Three separate draw calls, one boundary, same place. It isn’t attached to a model, a material or a texture.
And I walked into it. No camera movement, no setting change — I ran forward and it closed over me. In a follow camera your character’s screen position and distance from the camera both stay constant while you run, so neither a screen-space nor a camera-distance explanation can swallow you by walking. Something that changed as I walked is tied to where I am in the world.
It stays put within a session and does not survive a rebuild. I crossed the edge repeatedly and it behaved the same each time. gxRestart or a relog and it’s somewhere else, or gone.
within one session anchored to a position, you can walk in and out of it
across a rebuild re-rolled
Reading, not a finding. If it’s decided once, tied to position, and stays decided until the renderer rebuilds, that would account for several things I’d logged separately and never connected — gxRestart clearing it only sometimes, it returning within minutes, two people on identical hardware and macOS getting opposite results, loading in clean and corrupted a minute apart, and session length correlating loosely but never reliably.
Location: Redridge Mountains, 65.5, 81.3, with the edge a few steps southeast. I read the position once rather than at each crossing, so treat it as where this happened rather than a surveyed boundary.
Other people have now posted the same behavior. The strongest is Kàös’s, at the XR inn exit at sunset: standing on a straight boundary line with his character “half missing, and half visible (like I was cut in half)”, with mobs inside the dark region rendering black until clicked. That is the three-state boundary reproduced on different hardware, by someone else.
Ringthane has described a “clear border” twice — in Elwynn, into Westfall, and separately in Dun Morogh, where he reports green and yellow hues with visible lines where each starts and stops.
Correction: I previously cited an Orgrimmar bridge report here as corroboration on this build. Ishura has clarified that he saw it once, on an earlier build, and wasn’t reporting it as ongoing. My error, and it’s removed.
If you see the corruption, this takes five minutes: turn on a coordinate display, find an edge, walk out and back a few times and note whether it flips at the same coordinates, then gxRestart and go back. Edge gone or moved confirms it’s decided per session. Edge still there means it’s the map and I’ve got this wrong — and that would be a bigger finding than mine.
The strongest measurements
1. A within-frame control — the cleanest I’ve managed. One wall, one material, across a hard boundary, in a single frame:
above the line R 75.39 G 71.35 B 72.09 neutral grey, correct
below the line R 56.24 G 23.21 B 52.20 magenta
scale ×0.746 ×0.325 ×0.724
Red and blue fall together by about a quarter — ordinary light falloff down a wall. Green falls to a third.
2. The sky rules out a whole class of explanations. Same patch of sky, corrupted frame versus clean frame:
R G B
corrupted 128.90 218.15 244.14
clean 128.29 217.94 244.27
Identical to three figures, while stone in the same frame has green at a third. That is not your display profile, not gamma, not exposure, and not any filter over the whole image. If anyone has told you to check your color settings, this is why that isn’t it.
(Caveat added 2 Oct: that comparison is daytime-to-daytime. A sunset capture will read red-shifted sky legitimately — don’t measure this invariant across different times of day.)
3. It’s applied per-pixel, not per-object. A statue in one frame: torso and greaves R/G 1.11, correct; boots R/G 2.05, corrupted. One model, one material, one distance, cut in half.
4. The most extreme channel loss measured — 1 October, build 70170, Elwynn red-dominant:
R G B G/R
open ground 41.51 1.93 7.35 0.05
mid-ground 44.24 6.63 10.98 0.15
health bar (UI) 40.37 41.94 8.07 1.04 ← correct
Green at 5% of red on open ground, with the interface a few hundred pixels away rendering it perfectly. Across the entire world render, only 0.4% of pixels have green exceeding red.
5. It hits stone hard on the builds where it reads magenta.
R G B R/G
stone facade, clean 63.56 64.87 39.65 0.98
stone facade, cast 81.34 21.63 52.63 3.76
And grass was untouched in the same frame where stone and tree canopy were destroyed — grass R/G 1.21 against 1.15 clean.
This is not the black-rendering fault, and I’m separating them for good
I spent time trying to tie fault 1 to the exact-zero black foliage, water and character silhouettes. That was wrong and I’m dropping it. Those were a different fault with a different cause, fixed on 70009. Fault 1 is channel attenuation. If you see solid black foliage or black water on a current build, that is not this fault and it’s worth its own report.
The 25 September measurements, still current
Same grass tufts, both states, one frame. A hillside with a corruption boundary across it — identical tufts on both sides, same camera, same second:
corrupted side clean side ratio
R 20.4 56.5 0.36
G 25.3 37.6 0.67
B 20.0 20.4 0.98
tuft/ground ratio 0.583 0.552
The tuft/ground ratio is unchanged across the boundary — the plants aren’t being singled out, the whole region is shifted.
Severity scales inversely with light level. Stone flagstones with a shadow edge crossing them, one surface, one material: lit reads 120.6 / 63.2 / 62.8, shadow reads 71.3 / 23.0 / 46.4 — factors of 0.591, 0.365, 0.739. Uniform lighting gives all three channels the same factor. Green falls off twice as fast as blue.
It modulates with geometry, in real time. A grass tuft swaying goes green-yellow one way and brown the other — same pixels, same material, same light, same camera. R swings 20.2%, G 13.9%, B 27.8%, R/G ratio 18.4%, dominant period ~3.5 s. That came from video, so h264 chroma subsampling makes the absolute numbers relative only; what survives is the shape — periodic, channel-selective, confined to part of the plant.
This is the easiest reproduction in the thread. Stand still and look at a plant. Ten seconds.
Both failure modes are real and shouldn’t be collapsed. On stone, all three channels carry texture in proportion to their own level — alive, scaled down. On the swaying plant, blue carries a quarter the relative texture and has 13 distinct values against red’s 140 — dead, with a light contribution on top.
relative detail (high-frequency detail / own mean)
R G B
plant crop 1 0.121 0.123 0.032
stone floor 0.032 0.029 0.031 <- all three alive
Behavior, and what’s been eliminated
It spreads by area, not only by getting deeper. Channel ratios inside an affected patch stay roughly constant while the patch grows.
It accumulates within a session. Correct on load, worse over the following seconds, from a stationary camera with nothing moving in frame. Standing on corrupted ground and running gxRestart renders it correctly immediately, then degrades back in about a minute — and keeps going past the original state. Nothing clamps it.
The location isn’t bad. Reliably-corrupted ground renders perfectly the instant the device restarts, same spot, same settings. That rules out map data.
Tested and eliminated, each with controls: weather, fog, time of day, windowed mode, resolution, Optional GPU Features, View Distance, Triple Buffering, Advanced Work Submit, and every Shadow Quality and Secondary Lighting step.
Session duration is the only thing that correlates, and even that isn’t dependable. I’ve loaded in clean and corrupted within a minute, and played hours with nothing. On one occasion it was present from the first frame after a relaunch that followed three completely clean hours. (The boundary finding above probably explains this: if the state is rolled at renderer init, session duration is a proxy and not a cause.)
Tested and eliminated, each with controls: weather, fog, time of day, windowed mode, resolution, Optional GPU Features, View Distance, Triple Buffering, Advanced Work Submit, and every Shadow Quality and Secondary Lighting step. None of them stopped it.
Visibility varies by surface, which is its own trap. The tint is far easier to see on snow, fog and neutral stone than on grass. “I don’t see it” and “it isn’t there” are not the same claim.
Fault 21 — Secondary Lighting renders at High regardless of the setting
New on 1.60.1.70205. Not my finding — Voidbeam posted it, Rommax confirmed it in code: the raid and non-raid Secondary Lighting settings are swapped.
on every login settings show your value, renderer runs High
High -> Apply -> Fair setting and frame rate both come back
next login it's back
Reported recoveries:
M4 Pro MBP, 50% render 70-80 fps -> 130 fps
M4 Air 10-core, 24 GB, 27.0.1 restored to prior-build levels
Windows confirmed fixed
Windows 10, RTX 3080 GPU usage 70-80% -> 20-30%
This is the first fault in this thread that isn’t ours alone. Two Windows reporters have identical behavior, one with a measured GPU-usage change on an RTX 3080.
Workaround: enable raid settings and set them to match your non-raid settings. Or toggle High, Apply, then back after every login.
If you are posting frame-rate numbers on 70205, do this first and say that you did. Otherwise fault 21 is contaminating fault 22 and nobody can separate them.
I cannot verify this one on my own machine, and that’s worth stating. I see no visible difference between Secondary Lighting Fair and High at all — so setting Base and Raid to different values and swapping between them gives me nothing to compare. That’s not a negative on the fault, it’s a negative on my ability to observe it. If you can see the difference between Fair and High, you can test this and I can’t.
Fault 22 — performance regression on base Apple Silicon
New on 1.60.1.70205. Not reproducible on my hardware — I’m on an M4 Max and I’m one of the machines that got better. Everything here is other people’s numbers.
hardware macOS report
M4 Air 10-core, 24 GB 27.0.1 60+ fps before Oct 1, now 23-30 standing
still in Elwynn on lowest settings, GPU at
100%. 50 cold, 25-30 within a minute as it
throttles. Same client fine on their PC
M5 MBP 14" base, 16 GB 26.6.2 45 fps with stuttering, 80-100C, fans at
100% in a sparse Goldshire
M6 Mac Mini base — halved
M4 Air base — halved, unplayable
M4 Air — "fried performance"
M4 — choppy, intermittent freezes
M5 Pro — cut in half
M4 Air, 24 GB 26.7 input delay above graphics 2
Against that, the Max parts on the same build:
M4 Max Studio, 128 GB 26.7 100+ fps at 1080p, max 78C
M5 Max MBP 40c, 64 GB 27.2 80-90 fps, no microstutter
M5 Max MBP — 50-60 stable, high settings
M5 Max Studio 40c, 64 GB 27.0.1 Secondary Lighting High now viable
M5 Max MBP 16" 40c — stuttering completely gone
M1 Pro MBP, 32 GB 27.0.1 much better, stable 30-40
The split is clean: Max and Pro parts improved on this build, base parts got worse. Rommax has acknowledged it.
How much of this is fault 21 is an open question I can’t close. Several reporters recovered their frames with the Secondary Lighting toggle; at least one reported no change after it. Until people report with the toggle applied, 21 and 22 can’t be separated.
No workaround. If you report here: chip, GPU core count, unified memory, macOS version. “M5” alone doesn’t separate a base part from a Max, and that distinction is the entire signal.
Fault 9 — shadow map calculation and application
Renamed 4 October. It was “shadow boundary at a fixed camera distance,” which described one presentation out of four and made everything else look like it belonged somewhere else.
Confirmed present on every build since I first filed it.
original report ~1.40x brightness across the boundary
70058 1.68x and 1.77x
70170 1.51x
Three presentations, one fault:
1. A hard boundary at a fixed distance from the camera. Ground that should be shaded renders lit. It’s tied to the camera, not the player — stand completely still and scroll the wheel, and the boundary moves.
2. Blocky wedge and triangle regions across terrain, matching no caster. Reported independently by Kàös, Ishura and Creeper, and confirmed here.
3. At Shadow Quality Fair, static geometry stops casting while characters keep casting. A character on a bridge casts a shadow on the ground beneath it; above Fair the bridge correctly blocks the light, at Fair it doesn’t, but the character’s shadow still projects. Reproduced at native resolution, so this was never fault 18.
I tried to split presentation 2 into its own fault and had to reverse it. Two camera positions showed the shapes holding still while the boundary moved, which looked like a clean separation. Then I found a camera angle that does move them. One counterexample was enough — the split rested entirely on that distinction, so they’re back under one number, and the number got a name that covers all of it.
New: it accumulates while you stand still
Four frames over about two minutes. Player stationary, camera untouched. Coverage grows frame to frame until most of the visible ground is dark.
The control is inside the sequence: the lighting on the crates and on my character is constant across all four frames. The sun isn’t advancing. What changes is how much ground the shadow pass covers, not how anything is lit.
What’s been observed to perturb it
camera distance the boundary moves with zoom
camera angle the shapes change at certain angles
time standing still coverage grows over ~2 minutes
low sun angle reported at sunrise, sunset and moonrise
rain and heavy fog reported to clear it, then it returns when the rain stops
5 October: gxRestart resets the accumulated coverage
/console gxRestart coverage resets
then it starts over, rebuilding as geometric shapes
That’s the first mitigation this fault has ever had. It re-rolls rather than fixes — the coverage rebuilds from scratch — but if the ground around you has gone dark over a long session, a renderer rebuild gives it back.
The tests I’d most like run
Does it saturate? Stand for ten minutes rather than two. Does it stop, or does it keep going until everything is dark?
At Fair, does any static geometry cast a shadow — walls, trees, buildings, terrain? If nothing static casts and everything dynamic does, that’s specific enough to go looking for.
Not fault 8, and that argument is Pallysan’s rather than mine: fault 8 is a buffer and resolution problem, fully screen-space, and the shadows in it are the correct shape and simply displaced. Shapes that break according to the angle of the light are a world-space problem at a different point in the pipeline.
Fault 8 — offset and oversized shadows (Shadow Quality Fair or higher)
Not my finding and not reproducible on my hardware — Pallysan’s, measured on an M2 MacBook, 13" 16:10, native 2560×1600.
At Shadow Quality Fair or higher, shadows appear offset down and to the right, with the error growing with distance from the top-left corner:
2560×1600 ~3/4" right, 1/2" down (at screen center)
2048×1280 ~2.5" right, 1.5" down
1920×1200 ~3" right, 2" down — shadow visibly double character size
Render Scale has no effect. That’s the signature of a shadow buffer held at a fixed size while the viewport changes. Solving their figures backwards gives ~2900, ~2980, ~2965 — consistent, which is what a genuinely fixed buffer looks like. 2880 fits all three readings, and 2880×1800 is the backing store macOS uses for a 2560×1600 Retina panel. So the buffer looks like it’s sized to the display’s backing store rather than the game’s render target, which also explains the Render Scale result.
Their measurements, my arithmetic. The inch figures are ruler-against-a-screen estimates — the consistency across three resolutions is the solid part.
I cannot reproduce this. Moved a confirmed caster across the full width of my screen and panned 90° around it, no change in offset. A negative on my hardware, not a mark against the test — and it points at the fault depending on display backing geometry rather than the GPU.
Separate from fault 9, and that’s Pallysan’s own argument — see the fault 9 section.
Fault 12 — pets aren’t culled with their owners
Still present. When a character is culled at distance their pet stays rendered, leaving a floating minion with no owner. Minor, but it means two culling paths disagree.
Fault 14 — login panel never renders if you click away during startup
Still present on 70205, and now also reported specifically on multi-monitor setups, where you have to have the mouse over the correct window or quit and relaunch.
Launch the client, then click to another window before it finishes coming up. The login screen arrives — 3D scene rendering, fire animating, Quit button in the corner — with no login panel at all.
The client isn’t hung. Escape opens the Game Menu, the menu items work, and closing back out returns to the same empty screen. Activity Monitor shows it at 14.3% CPU across 50 threads with the scene still animating. It’s fully alive, it just has no way in.
Five things that don’t fix it: clicking back onto the window; waiting minutes; unchecking Max Background FPS; opening and closing menu panels; changing a graphics setting and accepting it, which forces a settings apply and rebuild.
Only a full client restart works, and then only if you leave the window alone until it’s finished loading. It’s intermittent — twice in four launches. Nothing written to _classic_beta_/Errors/.
Guess, not fact: since a full settings apply doesn’t bring the panel back, I don’t think it’s sitting there un-drawn — I think its creation step gets skipped during startup and nothing later re-runs it.
Fault 15 — hang when crossing certain zone borders (not reproducible on my hardware)
Reported to me with video evidence by other players. I could not reproduce any of it, so this is their finding.
The client hangs indefinitely when crossing certain zone boundaries. /console gxRestart clears it. Locations named so far: the road between Mulgore and the Barrens; the road between Tirisfal Glades and the Undercity courtyard; and “a minefield” of border crossings in the larger zones generally.
All three reports are from M1 and M2 machines. That’s suggestive, but three reports without full specs isn’t a hardware pattern, and “M1/M2 versus M4” hides at least three variables — generation, tier and memory.
How they’re recovering, which matters. I asked how anyone runs gxRestart during a hang given you can’t see the screen. They type it blind and it works. So input is still being processed while rendering is stalled — same signature as the Deeprun Tram wedge, where audio kept playing with nothing on screen.
Better than typing blind: put /console gxRestart in a macro, drag it to an action bar and keybind it before you travel.
Fault 17 — /console gxRestart crashes the client during precipitation
Status across builds, and it isn’t a clean story:
70009 crashes on the first attempt, every time
70058 did not crash — rain was almost absent, I called this MASKED
70124 crashes on the first attempt
70170 untested — no rain found
70205 DOES NOT REPRODUCE — tested in real rain
4 October: it does not reproduce on 70205, and the rain was real
Four cells run in actual precipitation:
action result
/console gxRestart during precipitation no crash
Optional GPU Features ON -> OFF during precipitation no crash
/console gxRestart with Optional GPU Features OFF no crash
Optional GPU Features OFF -> ON during precipitation no crash
The objection that killed the 70058 result does not apply here. I discounted that one because the rain had been reduced to almost nothing, so whatever the rebuild chokes on never got reached. The rain on 70205 is heavy enough to put impact ripples on water surfaces — I have captures of it doing exactly that.
Both faults fired on the first attempt on 70009 and on 70124. A fault that reliable doesn’t miss four cells by chance.
I’d still like others to confirm before calling it closed. This one’s history has reversed twice already.
The Particle Density test is now untestable rather than answered. With no crash at normal density there’s nothing left to prevent. If 17 returns, that test returns with it.
What was different about 70058. The rain was drastically reduced — nearly imperceptible. On 70124 it looks much better, and that’s when the crash came back. So I don’t think this was fixed and then broken again. I think it was masked. There was so little precipitation being drawn that whatever the rebuild chokes on never got reached.
70009 normal rain crashes
70058 rain almost absent does not crash
70124 rain restored crashes
Reading, not a finding: if that’s right then the variable isn’t whether precipitation is active, it’s how much of it is being drawn. That would make this a threshold rather than a state, and would explain why fog has always been clean — fog isn’t a particle count.
The test I’d most like someone to run: Particle Density at its lowest setting, then /console gxRestart in heavy rain. If it survives, that’s a workaround this fault has never had. If it crashes anyway, particle count isn’t the variable and I’m wrong about 70058.
Until then, assume it applies. Don’t run gxRestart while it’s raining or snowing — walk somewhere clear first.
The original report and the full 70009 matrix are archived and available on request. Crash IDs from that era:
003A6AA4-E802-43F8-84AD-FCD88E794CE5
6D3091E8-E7DA-4EEC-9E9B-6A8E8B56C6E2
Fault 20 — turning Optional GPU Features off crashes the client while it’s raining
New 29 September. Found while testing fault 17. Full matrix:
location / weather client launched with action result
Elwynn, raining Features ON /console gxRestart fine
Elwynn, raining Features ON turn setting OFF CRASH
Elwynn, raining Features OFF /console gxRestart fine
Elwynn, raining Features OFF turn setting ON fine
Stormwind, clear Features ON turn setting OFF fine
Stormwind, clear Features OFF turn setting ON fine
Goldshire Inn, clear Features ON turn setting OFF fine
Goldshire Inn, clear Features OFF turn setting ON fine
Report ID 4D06D357-286B-4117-9C5B-8389CB61BE2B. The crash reporter still has no submit button, so this has not reached Blizzard by any route other than this post.
Precipitation is the condition, and location is ruled out directly. The Goldshire row is the control: same zone as the crash, clear weather, both directions fine.
Whether this is separate from 17 is open again. On 70058 I argued they were different, because a plain gxRestart in the same rain stayed clean while this toggle crashed. On 70124 both fail, so that evidence was build-specific and no longer holds. They may be one fault — a renderer rebuild during precipitation — with the toggle being one of several ways to force a rebuild. I’m leaving them numbered separately because the 70058 behavior was real and I’d rather keep the distinction visible than quietly merge it.
Does not reproduce on 70205 — tested in real rain, all eight transitions clean. See fault 17 above.
Fault 19 — Render Scale below 100% costs performance instead of gaining it
New 29 September. I cannot reproduce this on my machine and I’m reporting it anyway, because the numbers are specific and Render Scale is what everyone reaches for first when they want frames.
chip macOS render scale output standing still moving
me M4 Max 26.7 100% 2560x1440 73–77 fps 55–75 fps
other tester M5 Max 27 33% below 1080p 120 fps locked low 30s
He is rendering far fewer pixels than I am, on newer hardware, and the two rows invert depending on whether anyone is moving. Same tester with everything Ultra except Secondary Lighting at Fair: 60 fps locked standing still, 20–30 moving.
There is no workaround. The only mitigation is running at 100%, which is the same as not having the setting.
What I suspect, and it’s a guess: macOS or Metal version dependent rather than hardware dependent. Newer silicon on a newer OS running worse is the wrong direction for a hardware explanation.
If you’ve seen this, please post: chip, macOS version, Render Scale, output resolution, frame rate standing still, frame rate moving. The last two matter most — a machine that holds high standing still and collapses when you move is telling you something different from one that’s slow everywhere.
(Note for 70205: check fault 21 first. Some of what has been read as Render Scale behavior may be the Secondary Lighting mismatch.)
Fault 23 — rain renders indoors whenever an outdoor area is on screen
New 4 October, narrowed 5 October. Reproduced in two different buildings.
any outdoor area visible on screen rain draws indoors
nothing outdoors in frame it stops
It isn’t about where you’re standing or which way you’re facing. I can face further into an interior and still get it, as long as a doorway or tunnel mouth is in the shot. Turn until no outdoor area is on screen and it stops.
To reproduce: be indoors while it’s raining outside. Put any outdoor area on screen — doorway, tunnel mouth, window. Then turn until none is visible.
The rain audio is correct, and that’s new on 70205 — you hear it muffled from inside, the way you should. That half is a progression, not a regression. On earlier builds there was no indoor rain audio at all; my fault 17 matrix from 70009 recorded the Goldshire Inn as “raining outside, no rain rendering indoors,” with no indoor sound either.
audio knows you're under cover correct
visual doesn't wrong
This is the most reproducible fault I’ve reported. No session state, no re-roll, no accumulation, no particular hardware, no waiting. It toggles on and off on demand, instantly, in any building, for anybody. Every other fault in this thread is intermittent to some degree — this one isn’t, and you can see it inside thirty seconds.
It’s cosmetically minor next to fault 1. I’m flagging it anyway because it’s the one thing here that doesn’t need anyone to get lucky.
Resemblance, not a claim: this is the third thing I’ve seen where solid world geometry fails to block something — rain through a tunnel, god rays through a hill, and fault 9’s static geometry not casting at Fair. Three different systems, same shape of failure. Noting it only; they stay separately numbered.
Fault 24 — Stormwind canal water has no ambient wave animation
New 4 October. First reported by Avenom on an M1 Max, confirmed here.
The canal surface renders as a flat blur. No rolling surface detail, and reflections that appear to track the camera angle rather than the light source.
The harbor is fine in the same session — waves and specular highlights render correctly there, a short distance away.
Neither liquid setting touches it:
PBR Liquid Detail low / high / ultra no difference
Legacy Liquid Detail low / fair / good / high no difference
Rain settles what’s actually broken
The same canal water shows rain impact ripples, correctly.
same spot, same session, clear weather no surface animation
same spot, same session, raining ripples render correctly
So the surface is not broken. It accepts a time-varying normal and shades from it properly. What’s missing is specifically the ambient wave animation, and only that.
That’s a control inside one surface, which beats comparing the canal against the harbor because it removes location as a variable.
Caveat worth keeping: rain ripples are probably a separate layer from the base wave scroll, so what’s proven is the shared machinery — normal application and lighting. Whether the base wave layer’s inputs are unbound, zeroed or frozen isn’t visible from outside and I’m not claiming it.
Build window: 70124 or 70170. Those were close together and I can’t pin which. If anyone has canal screenshots from either, that would narrow it.
Fault 25 — periodic 15-20 second freeze (uncorroborated)
New 4 October. Creeper’s, on an M5 Max 40-core / 64 GB / macOS 27.0.1: roughly once an hour, usually during combat, the client freezes for 15-20 seconds and then recovers on its own.
Explicitly not fault 13. The mining node freeze had a specific trigger you could fire on demand — the final hit depleting a node — and it’s fixed: eight depletions on 70170, five of them in combat, no freeze. This has the same duration and self-recovery but no trigger at all, and the trigger is what defined 13.
One report, and I can’t reproduce it. If you’ve had this, say so — and more importantly, say what you were doing in the ten seconds before it happened. Fault 13 took weeks to pin to node depletion and this has the same shape of being hard to catch in the act.
Fault 26 — sun-colored orbs off surfaces and through gaps
New 4 October. Ringthane reported “flashing ball lightning” at max view distance in Elwynn and Westfall. Creeper reported “random flashes of light every few seconds.” Jezzor identified multisample AA as the cause and image-based AA as the fix.
I nearly closed this as “that’s just the sun.” The color matches exactly and my first captures look like the sun through trees.
What changed my mind:
where off reflective surfaces, and in gaps where light peers through
something
color same colorization as the sun
anchoring NOT world position — when the bushes in front of them sway, the
orbs move with them
An orb that repositions because a bush moved is not an object in the world. It’s gated on what’s occluding the light.
That would account for the flashing, which was the part that didn’t fit “it’s the sun.” Foliage sways, a gap opens, the orb pops to full brightness; the gap closes and it’s gone. Every few seconds, exactly as both reporters described. A correctly placed sun doesn’t flash.
my AA at the time Multisample, color 4x / depth 4x
So I’m on multisample and I see them, which is consistent with Jezzor’s finding rather than against it.
I have not confirmed the workaround myself. Right now it’s one person’s report that a second person agreed with. Try Image-Based Techniques if this is bothering you, but I’m not putting it in the configuration block above until I’ve tested it.
This one wants a video. The flashing and the foliage-linked movement are both temporal and a still frame shows neither.
Fixed and retired faults — condensed
Full original text archived and available on request.
| # | Trigger | Symptom | Fixed in |
|---|---|---|---|
| 3 | Optional GPU Features ON | Hard horizontal color bands across trunks and walls | 69977 |
| 4 | Secondary Lighting above Fair | GPU hang → kernel panic → reboot | 69977 |
| 5 | Shadow Quality above Low | Foliage renders as flat black silhouettes | 70009 |
| 10 | Water contact, or changing Shadow Quality | Water solid black (97–99% of surface at exactly 0,0,0) | 70009 |
| 11 | Camera distance; characters streaming in | Character models pure black silhouettes (30.8% of frame at exactly 0,0,0) | 70009 |
| 13 | Final hit depleting a mining node | Client freezes 10–15 seconds, then recovers | 70170 |
| 16 | Accumulates during play | Nothing released until the renderer is rebuilt | 70058 |
| 18 | Fullscreen (Windowed) below native | “Ghost shadows” — lit surfaces stop catching light | 70058 |
Notes worth keeping:
Faults 5, 10 and 11 went together on one build, which confirmed they shared a cause. This was never the same thing as fault 1 — that’s channel attenuation, these were geometry rendering at exactly zero.
Fault 6 retired into fault 1: the 2D loading screen immediately before the intro cinematic is completely clean — 158,953 lit pixels, zero exact-zero channels — and the corruption starts the instant the world renderer takes over.
Fault 13’s close: eight depletions on 70170, five in combat, no freeze. See fault 25 for a freeze that looks similar and is not this.
Fault 16’s methodology still matters, because it’s how you get a frame-rate number that means anything:
stutter events GPU time
70009, Mirror Lake 8.2% → 51.5% 14.35 → 19.20 ms
70058, Northshire 8.9% → 3.6% 19.74 → 17.36 ms
If you change a setting and read the framerate a minute later, you may be measuring how long you’ve been logged in. I did exactly this and produced a false result. For a number that means something: fixed spot with no other players, gxRestart before every reading, read at the same number of seconds after the restart each time, and alternate between settings rather than sweeping. Metal HUD if you can — /bin/launchctl setenv MTL_HUD_ENABLED 1, then restart launcher and client — because GPU milliseconds keeps working above a framerate cap and FPS doesn’t. (But see trap 7, and one reporter says the HUD stopped working on 70205.)
Memory came apart from performance on 70058. Allocation climbed 4.28 → 4.50 GB across a session and released once, while frame times were the best they’d been. Noting it as an open observation, nothing more.
Fault 18’s original isolation, kept because it still applies to older builds:
Fullscreen (Windowed) 2560x1440 (native) lit awning, brightness 81.6 correct
Fullscreen (Windowed) 2048x1152 (below) same awning, 50.6 broken
Windowed below native same awning, 79.9 correct
Fault 7 — retracted, and worth stating why. The original fault was real: god rays drew at Low only, and Fair, High and Ultra all killed them. What it does now — volumetric fog at every setting, god rays from Good upward — is a quality ladder behaving normally. An expensive effect reserved for higher presets is an optimization, not a bug. The inversion is the fix.
If you are still seeing god rays die as you raise Shadow Quality, that’s the original fault and it’s worth posting with your chip and macOS version — two people reported it on earlier builds and it would mean the fix didn’t land everywhere.
Worth knowing if you’re testing anything: Shadow Quality changes more than shadows. If you A/B with it you’re also toggling volumetric lighting.
Negatives — things I tested that turned out not to be faults
Reporting these because a clean negative is worth as much as a finding, and because several are mine.
View Distance 1 is not slower than higher settings. With gxRestart before every reading and an alternating order, VD 1 reads 13.43 and 14.00 ms and VD 10 reads 14.08 — inside the VD 1 spread. My first attempt showed VD 1 as 10% slower and that was drift, not the setting.
Windowed mode does not avoid the color corruption. Canopy at R/G 2.15 in a window where healthy Elwynn sits around 0.80, with the sky in the same frame rendering correctly.
Fog does not clear the color corruption. I thought I had this and I don’t. Every “clean” observation was within about five minutes of a gxRestart.
Night does not prevent it either. Measured on a cast hillside after dark: green scaled to 52% while red and blue held above 80%. If it were simply darkness all three channels would fall together.
Distance does not drive it, despite one capture that looks like it does. A sunset screenshot of mine shows green survival ramping from 0.10 at my feet to 0.58 on the far treeline. That is what ordinary distance fog does at sunset on a healthy client. The real finding in that shot is green at 8% of red on the ground in front of me; the gradient behind it isn’t evidence of anything. Flagging it so nobody quotes it back as a depth effect.
Resolution does change performance. Someone reported framerate not moving with resolution. Mine moves: 33.74 → 41.43 FPS going from 2560×1440 to 1920×1080.
Rain falls vertically on my machine. Someone reported horizontal rain streaks and I couldn’t reproduce it — but I was testing with Optional GPU Features on. With that setting changed I get broad diagonal bands immediately. So that report was real and the setting is the isolating variable. I closed it too early on a single negative test.
Reported on 70205, not numbered yet
Listing these without numbers because I either can’t separate them from a setting working as designed, or only one person has seen them.
Compute Effects High -> Ultra halves frame rate two reporters, 120->60 and 90->55.
But a quality step costing frames
isn't automatically a bug — I
retracted fault 7 for exactly this
Metal HUD no longer working one reporter
Secondary Lighting bleeding through hills one reporter
Flicker in a ~20 yard circle around the player one reporter, Barrens daytime
Game Menu > Support loops on a Battle.net 403 not graphics, out of scope here
Hypothesis — a guess, not a finding
Everything above this line is measured. This is me reasoning backwards from the shape of it, and I can’t verify any of it.
Several measurements point the same way: severity scales inversely with light level, severity modulates with surface orientation in real time as a plant sways, the corruption boundaries are locked to world geometry rather than the screen, and a single model can be cut in half by one.
On a lit surface the angle to the light is the light level, so the first two may be the same observation from two directions. Something in the lighting path degrading as a geometric term gets small would produce an affected region bounded by a line of constant angle across the geometry — which is what a hard boundary through one object looks like.
What the boundary work adds: the state appears to be decided once per session, anchored to world position, re-rolled on a renderer rebuild, and it’s a yes-or-no decision rather than a continuous one.
That’s one idea covering the light dependence, the sway modulation, the boundary behavior and the area spread. I’m not claiming it.
Client error logs (_classic_beta_/Errors/)
Main thread, every session:
Error: ASSERTSAFES(internalGraphicsSetting, ...)
Description: GraphicsSettingCallback Error loading RAIDbloomUserMult
File: .../WoW/Source/WorldClient2/WorldParam.cpp Line: 1330
A graphics setting failing to load through its callback during startup, with a file and line number. Worth a fresh look given fault 21 — that’s a RAID-prefixed graphics setting failing in a callback, and fault 21 turned out to be raid and non-raid lighting settings being swapped. I can’t connect them and I’m not claiming they’re related, but they’re at least in the same neighborhood.
Also nine times across nine sessions, always 15–18s after launch:
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
Identical FileData ID and CKey every time. The client runs on without the asset.
The crash reporter has no submit button
When the client crashed, the Blizzard error reporter appeared with only Close — no submit option. None of this reached you automatically. If that’s general to the Mac beta build, your crash telemetry for this platform may be far thinner than the volume of reports on this forum suggests.
Severity ladder
1 Color corruption on lit surfaces — no macOS log of any kind
2 Corruption spreads to near geometry — no log
3 Black screen, nothing renders — still no log
4 WindowServer stalls, watchdog restarts it, session survives
5 WindowServer stalls uninterruptibly — kernel panic, machine reboots
Stages 1–3 leave no trace in macOS diagnostics at all, which I suspect is why “green tint”, “black screen” and “my Mac rebooted” read as three unrelated problems here.
Related threads
This isn’t one machine. Hardware across these spans M1 Pro, M1 Max, M2 Max, M3 Ultra, M4 Air, M4 Pro, M4 Max, M5 Pro, M5 Max and M6.
- The companion thread — same panic, different hardware, names the CVars: [Mac] Secondary Lighting above Fair hangs the GPU on Enter World and reboots the Mac (M5 Pro, macOS 26.5.2)
- Color corruption — reports green where mine is magenta (“like a shader was refusing to add red”): MacOS client rendering issues and/or locking up
- Secondary Lighting workaround, partial for many: Mac Crashing Solution! Turn “SECONDARY LIGHTING” to “FAIR”
- Whole machine freezing on entering the world, on much smaller hardware: WoW: Forever Beta freezes entire Mac when entering the world — MacBook Air M4, macOS 26.6.2
- The 70205 frame-rate regression, with gx.log detail: [Mac] FPS regression since Oct 1: M4 GPU family:Unknown, client falls back to mtl_1_1 shaders
- And the official Known Issues list for this beta: WoW Forever Beta Known Issues - September 18
Roughly 25 acknowledged issues on that last one — barber chairs, LUA errors, minimap placement, talent interactions. Not one entry about macOS, graphics corruption, lighting, shadows, black screens, crashes or system freezes. Given the threads above involve Macs kernel panicking, and given the crash reporter on this build has no submit button, I suspect these reports simply aren’t reaching anyone.
System
Mac Studio (2025), M4 Max, 16-core CPU / 40-core GPU, 128 GB unified memory
macOS 26.5 (25F71) at the time of the panics, 26.7 (25G229) now — reproduces on both
2 external displays, 2560x1440, render scale 100%
Graphics API: Metal
Forever beta .69893, .69913, .69977, .70009, .70058, .70124, .70170, .70205, .70235 — fault 1 has reproduced on every one of them. The single clean session I had on .70205 did not hold.
Full kernel panic logs, WindowServer watchdog stackshots and client error dumps available to anyone at Blizzard who wants them.
