Guide

Map crashes on the loading screen

A crash during the loading bar happens before most of the map's code runs, which narrows the list of suspects. Work through them in this order.

What you see

  • The game closes a few seconds into the loading screen, often with no error dialog.
  • Or a crash dialog appears, such as FATAL ERROR with ACCESS_VIOLATION.
  • The same map may load on an older patch, or for a friend on another build.
This application has encountered a critical error:
FATAL ERROR!
Program: ...\war3.exe
Exception: 0xC0000005 (ACCESS_VIOLATION)

Why it happens

War3Log.txt does not record the crash itself, so timing is your best clue. A crash on the loading bar points at data the game reads while loading (object data tables, imported files, the map info) and at code that runs during map initialisation.

SLK tables on 3.0. Maps that carry unit or ability data as SLK tables, common for maps made with KKWE, YDWE or w3x2lni, can close on the loading screen on 3.0.x. Map makers report two triggers: a leftover file column in UnitUI.slk or ItemData.slk, and any column in AbilityData.slk the game does not know, such as DataA7. A stray */ in an imported FDF file now aborts loading too. These are map-maker reports, not confirmed by Blizzard.

Model names with an extra dot. On 3.0.0 an import named like my_model_1.0.mdx failed to load or crashed. The 3.0.1 notes say this is fixed.

Handles created too early. Creating units, quests, multiboards or regions inside a JASS globals block crashes on load. Registering mouse events during initialisation can crash right after the loading screen, but only some of the time.

Very long object-data strings. A tooltip of about 1024 bytes stored directly in object data crashed the loading screen in a 2018 test on a 1.28-era client; today's limit is unverified. Non-English text reaches it at half the characters, because the limit counts bytes.

How to fix it

  1. Note the exact moment: during the bar, at the end of it, or when the first unit appears.
  2. Back up the map, extract it with an MPQ tool and look for Units\*.slk tables. Remove the file column from UnitUI.slk and ItemData.slk, and delete any AbilityData.slk column the stock table does not have. Converting the map back to normal object data is the durable fix.
  3. Fix unmatched */ comment closers in imported FDF files.
  4. Rename imports that have a second dot (model_1_0.mdx) and update every object field and script path that points at them.
  5. Move handle creation out of globals into code that runs after the game starts, for example from a 0 second timer. Register mouse events then too.
  6. Keep object-data strings well under 1024 bytes. Opening and re-saving the map in the editor moves long tooltips into war3map.wts.
  7. If none of this applies, bisect: disable triggers in groups until the crash stops.

How WC3 Map Doctor detects it

Rules that look for this
  • Errors
    A handle-creating native runs in the globals block, which crashes the game on load or on save.
    CRASH-globals-handle-create
  • Warnings
    A mouse event is registered during map initialisation, which can crash Reforged 2.0.3 and later (some live maps do it and run).
    CRASH-mouse-event-init
  • Severe
    An imported model or texture has a second dot in its file name, which fails to load or crashes on 3.0.
    BRK-dotted-import-path
  • Warnings
    An import overrides a game data table or script at its stock path (Units, Splats, UI, Doodads or Scripts), which 3.0 reads differently.
    PERF-A05
  • Errors
    The map info format version is newer than the target build can read (v39 needs 3.0.0, v33 2.0.3, v31 1.32, v28 1.31).
    W3I-version-vs-patch

Operations that fix it on a copy

  • compat.import-names Give imported files names Warcraft III 3.0 can load
  • compat.fdf-comments Remove stray comment closers from imported .fdf files

An SLK repair operation is being built and is not offered yet.

Sources

Written in our own words from our lab notes; these are the pages behind them.