TL;DR
- Affected: Windows,
3.0.0.24268, Graphics Quality Definitive Edition or Reforged, on a map whose archive overrides a stock UI\MiniMap\*.dds. Seen in W3Champions ladder games
- Symptom:
ACCESS_VIOLATION reading 0x2B8 at Warcraft III.exe+0x1640A8 during the loading bar, on both Async File Load threads at once. About 2 in 3 attempts kill the client.
- Mechanism: the game closes the map archive while still asynchronously reading files out of it; the reader's handle revalidation returns NULL with
ERROR_INVALID_HANDLE, and the read path dereferences that NULL instead of returning.
- Players: set Graphics Quality to Classic — 0 faults in 4 Classic loads, 11 in 11 DE / Reforged loads.
- Map makers: do not override the game's minimap icon textures (the confirmed case; the defect applies to any file read from the map archive while the loader is still working on it) until this is fixed; the game ships all of them itself.
- W3Champions has removed the four overrides from its maps; re-packed maps without them load normally in Definitive Edition on both maps tested.
Symptom
The client dies during the loading bar, with the same signature every time:
ACCESS_VIOLATION (Failed to read address 0x00000000000002B8
at instruction 0x00007FF6EEB340A8)
DBG-MODULE<00007FF6EE9D0000 0e155000 "Warcraft III.exe" ...> build 24268
Both Async File Load workers fault in the same instant, so each crash writes two folders under Documents\Warcraft III\Errors, 0.48-0.60 s apart, with byte-identical stacks.
Over 15 player loads of one map in a day: Classic (PREF_GENERAL_HD = 0) 0/4 faulted, HD (1 or 2) 11/11 faulted; of those 11, 7 killed the process and 4 survived and played — about 1 in 3 survived. The next day, 7 further LAN loads in Definitive Edition, all fatal.
Reproduction
- Windows, Warcraft III 3.0.0.24268.
- Graphics Quality Definitive Edition or Reforged.
- A custom map whose archive contains
UI\MiniMap\MiniMapIconCreepLoc2.dds and UI\MiniMap\MiniMapIconCreepLoc.dds, overriding the stock files — any current W3Champions ladder map. Two different maps faulted at the same offset 0xB0F4 and size 0x5F0, so it does not vary with the map.
- Load the map.
- The fault lands 0.119-0.210 s after the third
Opening map of the load, 7/7 measured. Look in Documents\Warcraft III\Errors.
Controls that did not reproduce: Classic graphics (0/4 against 11/11); the same map in a Battle.net custom game in Definitive Edition (no Errors folder at all — one observation, and this machine writes one even when the fault is survived); the same map re-packed without the four UI\MiniMap\ overrides.
Analysis
Fault site — the buffered sector read's lazy-init path (Storm SFileReadFileEx2), byte-identical in every dump:
+0x16407B mov rcx, qword ptr [rcx+0x130] ; rcx = the ARCHIVEREC the FILEREC points at
+0x164082 call Warcraft III.exe+0x1628A0 ; GetArchivePtr -> NULL
+0x164087 mov rbx, rax ; RBX = 0
+0x16408F test rax, rax
+0x164092 je +0x1640A2 ; TAKEN - but only skips the lock at +0x1E9CA80
+0x1640A2 mov r15d, 0x10
+0x1640A8 mov r13, qword ptr [rbx+0x2b8] ; <<< FAULT, RBX still NULL
Crash context in every dump: RAX=0 RBX=0 RCX=6 RDX=0 RBP=0x1000 RSI=0 R8=0x10 R11=0 R14=0 R15=0x10.
+0x1628A0 is Storm's GetArchivePtr: validate the handle is still registered, then refcount. It walks the global TSList<ARCHIVEREC> under a lock, with two NULL returns — arg-was-NULL at +0x1628B2, and list-not-found at +0x162927:
+0x162927 lea rcx, [rip+...] ; ®istry lock
+0x16292E call +0x1E9CAC0 ; lock LEAVE
+0x162934 mov ecx, 6 ; Storm error 6
+0x162939 call +0x15A460 ; SErrSetLastError(6) = ERROR_INVALID_HANDLE
+0x16293E xor ebx, ebx
+0x162940 mov eax, ebx ; NULL return: list-not-found
List-not-found is the path taken: RCX = 6 is that mov ecx, 6, untouched between the call and the fault. So the pointer was non-NULL but no longer registered.
In all three dumps that captured [FILEREC+0x130], both TSLink pointers (+0x00, +0x08) are zero — UnlinkNode's signature — while the refcount at +0x20 is still 2, the sector buffer at +0x2B8 is intact and +0x24 still holds the map's .w3x path: unregistered, not freed. The reader is [FILEREC+0x1C] = "UI\MiniMap\MinimapIconCreepLoc2.dds", [+0x138] = 0xB0F4, [+0x144] = 0x5F0 (1520 bytes), [+0x228] = 0 (buffer NULL, hence the lazy init), RBP/R14 = 0x1000 / 0 — the file's first read. Its sibling is MinimapIconCreepLoc.dds; both workers point at the same ARCHIVEREC, so they fault together and always produce a folder pair.
Three-part defect:
[FILEREC+0x130] is a raw, uncounted back-pointer — SFileOpenFileEx stores the archive there with no AddArchiveRef.SFileCloseArchive unlinks unconditionally — UnlinkNode is decoupled from the refcount and never walks the FILEREC list or the async read queue: no drain, no cancel.- The null check at
+0x16408F is a missing early return — the je at +0x164092 skips only the lock, so a NULL becomes [NULL+0x2B8] instead of a read error.
Any one of the three fixes it: a counted archive reference in FILEREC; drain or cancel pending async reads in SFileCloseArchive; or an early return at +0x16408F.
Symbolisation. No ASLR on the image: base 0x00007FF6EE9D0000, size 0x0E155000, so every address above is an RVA. fileversion 3.0.0.24268, guid=9B3EECC77B674CD09B65CD55F2992D4F, age=1.
Inference. The same .w3x is opened several times per load, each a distinct ARCHIVEREC, no reopen-dedup; a lobby adds five more preview opens within ~150 ms. [inference] those extra overlapping opens and closes shift an SFileCloseArchive into the window where the loading open's minimap reads are still draining. The archive layer has no LAN branch, so this is timing, not a separate code path.
For map makers
The four files are MiniMapIconCreepLoc2.dds, MiniMapIconCreepLoc.dds, MiniMap-Gold.dds and MiniMap-NeutralBuilding.dds, under UI\MiniMap\. If your map ships its own copies, the minimap icon read comes from your map's archive — the short-lived record the loader opens and closes several times per load — instead of the game's long-lived data, and that is what puts it in the race.
Build 24268 ships all four itself, in one layer: war3.w3mod/ui/minimap/minimapiconcreeploc2.dds, 1520 bytes — the same size as the override, which is why size alone never identified the source. No ui/minimap/ exists in _hd.w3mod, _de.w3mod, the _teen layers or the 13 locale layers: SD, Reforged and DE all draw from that one set. So dropping the override costs only the custom art; the markers still render, in Blizzard's version. W3Champions had shipped these unchanged since 2022-10-18 — harmless until 3.0.
The defect is not specific to those four files. Any file the engine reads asynchronously out of the map archive at the moment it closes that archive faults the same way. The minimap icon set is simply the read that is in flight during the loading bar's minimap phase, when the engine has reopened the map archive for the third time. Files the engine reads at other times did not trigger it — the W3Champions maps still carry their command-button icons and script-driven custom icons, and load fine without the four overrides — and we did not test overrides of other assets the engine loads during the loading screen. So until Blizzard fixes the archive layer, the safe rule is: do not override any stock asset the engine loads during map loading, the minimap icons being the confirmed case.
Second bug, minor
In the LAN lobby the game opens a mangled map path exactly four times, 6-10 s before the load, unescaping \NN as a hex byte: Maps/W3Champions\44_... opens as Maps/W3ChampionsD_w3c_... (\44 -> 'D' = 0x44), and Maps/W3Champions\29_... as Maps/W3Champions)_w3c_... (\29 -> ')' = 0x29). Those paths cannot exist, so each is a failed archive open.
It is generic 3.0 behaviour, not a naming issue: the stock map maps\(2)bootybay.w3m was opened a fourth time as maps(2)bootybay.w3m, backslash swallowed. Nor is it reachable from the joining client — forward slashes changed nothing, the game re-normalises to its backslash form (16 opens of Maps/W3Champions\44_..., 0 forward-slash) and still emitted all four mangled opens.
Attachments
On request: Crash.txt, War3.dmp and War3Log.txt from Documents\Warcraft III\Errors\2026-09-14 23.10.03 07f6048c and ...\2026-09-14 19.11.55 48d4616c, plus the full written analysis.
Scope: since 3.0, macOS players finish HD matches on these same maps at their usual rate. The above is the Windows client.
