Update summary:
#1 – Scan & Repair did not fix it.
#2 – Not addon-related. Reproduced with all addons disabled and after clearing cache.
#3 – After being removed from the group and waiting ~60 seconds, I was able to log back into the character normally.
#4 – Joined a completely new group / new Deadmines instance and got the same ACCESS_VIOLATION at the exact same physical location.
#5 - Unique to Deadmines to that exact spot.
#6 - No kick timer to reset the instance, so I’m stuck in the dungeon with perma Access_Violation error loop. Unable to get out.
Summary
My Human Warrior is currently stuck crashing immediately when loading into Deadmines (MapId 36) on the WoW Forever beta.
The crash is fully reproducible and has occurred multiple times in a row with the exact same native crash signature. The client consistently reaches the world for approximately 1 second, then crashes with Error #132.
The crash occurs at:
0x00007ff672264740
and attempts to read:
0x0000000000000030
The same instruction address, same invalid memory address, and same initial stack addresses were reproduced across multiple launches. 2026-10-02_03.18.39_Crash_2392
Client / build information
The affected client is:
World of Warcraft: Beta Build
Version: 1.60.1.70170
Branch: 1.60.1
Project: Camelot
Executable: WowB.exe
Platform: Windows 11 x64
Character: Human Warrior
Map: Deadmines, MapId 36
The executable was built on Oct 1, 2026 at 11:39 AM. 2026-10-02_03.18.39_Crash_2392
Exact crash
The client reports:
Exception: ACCESS_VIOLATION
The instruction at "0x00007ff672264740"
referenced memory at "0x0000000000000030".
The memory could not be "read".
ERROR #132
The first addresses in the crash chain are consistently:
WowB.exe + 0x00007ff672264740
WowB.exe + 0x00007ff672264d5f
WowB.exe + 0x00007ff6722739eb
WowB.exe + 0x00007ff6740726c8
WowB.exe + 0x00007ff674072b6d
WowB.exe + 0x00007ff673d9798b
WowB.exe + 0x00007ff67043d8d8
This exact signature has remained unchanged through repeated attempts. 2026-10-02_03.18.39_Crash_2392
Reproduction steps
- Launch WoW Forever beta normally through Battle.net.
- Select the affected Human Warrior.
- Enter the world while the character is located inside Deadmines.
- Loading completes or nearly completes.
- Client enters the world.
- Approximately 1 second later, WoW crashes with Error #132 / ACCESS_VIOLATION.
The crash is reproducible on every attempted login to this character while it is in Deadmines.
The crash logs consistently show:
CharLogins: 1
Time in World: 00:00:01
Total Time in World: 00:00:01
MapId: 36
2026-10-02_03.18.39_Crash_2392 2026-10-02_03.18.39_Crash_2392
Troubleshooting already performed
I tested several possible client-side causes and the crash continued with the same exact instruction address and same attempted read address each time.
- Initially reproduced with my normal addon setup enabled.
- Disabled several major addons including DynamicCam, ForeverThreat, ThreatPlates, RareScanner, and others; crash remained identical.
- Then disabled all addons completely. The crash log confirms:
Addons.HasAny.Loaded = No
and
LuaErrors = 0.
The crash still occurred identically. 2026-10-02_03.18.39_Crash_2392 - Deleted the beta Cache folder and relaunched. The crash remained identical.
- Tested under DirectX 12; crash occurred.
- Switched the graphics API to DirectX 11 from in-game graphics settings and reproduced the same crash again.
- DX11 is confirmed in the crash log:
CVar.GxApi = d3d11
GxApi = D3D11
Graphics.ShaderModel = dx_5_0. 2026-10-02_03.18.39_Crash_2392 2026-10-02_03.18.39_Crash_2392 - No GPU device-loss event was recorded:
GxDeviceLostCount = 0. 2026-10-02_03.18.39_Crash_2392 - Streaming diagnostics show no streaming errors:
Streaming Errors Count: 0. 2026-10-02_03.18.39_Crash_2392
Important consistency across crashes
Across repeated crash logs, the following remained constant:
Exception address:
0x00007ff672264740
Referenced address:
0x0000000000000030
Error:
ERROR #132 / ACCESS_VIOLATION
Build:
1.60.1.70170
Map:
36 / Deadmines
Time in world before crash:
~1 second
This remained the same with addons enabled, some addons disabled, all addons disabled, Cache cleared, DX12, and DX11.
Because the failure address and near-null read are identical every time, this appears to be a deterministic client-side code path rather than a random crash.
Graphics / hardware environment
GPU:
NVIDIA GeForce RTX 4080
VRAM: 16050 MB
Driver version: 32.0.0016.1656
Driver date: 2026-08-20
The crash log does not report a device reset or GPU loss. 2026-10-02_03.18.39_Crash_2392
On the final reproduction, DirectX 11 was being used and the crash behavior did not change.
Graphics settings / CVars
The character was running high graphics settings. Some notable CVars present in the crash log include:
graphicsQuality = 9
graphicsViewDistance = 9
graphicsEnvironmentDetail = 9
graphicsShadowQuality = 5
graphicsParticleDensity = 5
farclip = 10000
horizonStart = 4000
horizonClip = 10000
groundEffectDensity = 256
groundEffectDist = 300
doodadLodScale = 150
lodObjectFadeScale = 150
volumeFogLevel = 4
SSAO = 4
reflectionMode = 2
weatherDensity = 3
2026-10-02_03.18.39_Crash_2392 2026-10-02_03.18.39_Crash_2392 2026-10-02_03.18.39_Crash_2392
However, the same crash continued after changing the graphics API from DX12 to DX11, and there are no device-lost or rendering reset errors in the log.
Addon state on clean reproduction
On the clean reproduction attempt, no addons were loaded at all.
The log shows all installed addons as unloaded and:
Addons.HasAny.Loading: No
Addons.HasAny.Loaded: No
LuaErrors: 0
2026-10-02_03.18.39_Crash_2392
This makes an addon Lua error very unlikely to be the direct cause.
Expected result
The character should load normally into Deadmines and remain playable.
Actual result
The character loads into Deadmines, remains in-world for approximately 1 second, then WoW terminates with:
ERROR #132
ACCESS_VIOLATION
WowB.exe
Instruction: 0x00007ff672264740
Referenced memory: 0x0000000000000030
Why this looks reproducible
The crash is not moving around between different DLLs or memory addresses.
Every reproduction reaches the same WowB.exe instruction, performs the same read from address 0x30, and crashes immediately after the character enters MapId 36.
That behavior persists after removing addons, clearing cache, and switching render APIs.
This suggests the affected character or the current Deadmines instance state may be causing the client to hit the same invalid/null object reference during world initialization.
Additional information
The affected character is:
Race: Human
Class: Warrior
Spec reported by client: Warrior
Realm: Classic Beta PvE 2
2026-10-02_03.18.39_Crash_2392
The issue began after the 1.60.1.70170 build and occurred while the character was already inside Deadmines.
I can provide multiple crash logs from repeated reproductions if needed.
Update1:
After Scan and Repair, with all addons disabled, cache cleared, and DX11 enabled, the crash still reproduces identically. The client enters Deadmines for ~1 second, then Error #132 occurs from the same code path and reads address 0x30. This appears deterministic and tied to the character/world state rather than local files or addons.
Update2:
I created a brand-new level 1 character on the same beta client and was able to log into the world normally and remain online for about a minute with no crash. I then logged out, selected the affected Warrior, and the client again crashed approximately 1 second after entering the world in Deadmines.
The crash log for that session shows CharLogins: 2, Total Time in World: 00:01:03, and then the affected Warrior crashes on MapId 36 with the same ACCESS_VIOLATION, same read from 0x30, and same ...4740 code path. This suggests the client/install is generally functional and the issue is specifically tied to the affected character’s current Deadmines/world state rather than the whole beta client. 2026-10-02_03.28.23_Crash_39788
Update 3:
Resolution / additional finding:
The affected Warrior became playable again after being removed from the dungeon group, which caused the Deadmines instance association/ID to reset. Before being kicked, the character crashed approximately 1 second after every login with the same Error #132 / ACCESS_VIOLATION. After being removed from the party and no longer tied to that instance, the character loaded normally.
This strongly suggests the crash was tied to a specific Deadmines instance state/instance ID rather than the character, addons, graphics API, or local installation.
Update 4:
Important new finding:
I joined a completely different Deadmines group and entered a new instance. The game crashed again at the exact same physical location inside Deadmines. This suggests the issue is tied to a specific area, mob, object, or event in the dungeon rather than the original instance ID.
The crash occurred after 2nd boss in the same section of the dungeon as the previous crash. The Blizzard crash reporter appeared immediately at that location.
Report ID for this occurrence:
746B6AA0-E11F-4A7E-9820-4ABA5CEB64DA
Update #5
I did not encounter this crash in the Halls of Thane dungeon; so far it appears specific to this exact Deadmines location.
Update #6
After re-entering the affected Deadmines area, the character is now stuck in the dungeon without the normal “you are not in this group” removal timer. Every login crashes again at the same location. The normal Forever beta unstuck service is unavailable, so I currently have no client-side way to move the character out.