Why does FS2004 crash when approaching an add-on airport?

FS2004 (FS9) usually crashes when approaching an add-on airport because a scenery, model, texture or AI file is loaded as the aircraft enters that area. Disable the airport to confirm it, then test duplicate AFCADs, dependencies and AI traffic before isolating the package’s BGL files in small groups.

Common causes of FS2004 airport approach crashes

A crash at roughly the same distance from one airport usually identifies content being loaded in that scenery cell, rather than a general FS2004 stability problem.

• Faulty or incompatible BGL: a malformed placement, airport, terrain or object-library file can close FS2004 when it is loaded. Content compiled for FSX or another simulator may also be incompatible with FS9.
• Bad model or texture: the airport may work until a particular terminal, vehicle, light or seasonal texture comes into range. A missing texture normally produces a visual fault, but a corrupt model or mismatched library can cause a crash.
• Duplicate airport definitions: two airport-facility BGLs, commonly called AFCADs, may define the same runways, parking, approaches or navaids. Duplicates more often cause visual and AI problems than crashes, but they still need to be eliminated during diagnosis.
• AI traffic: a faulty AI aircraft model, repaint or traffic package may be loaded only when a scheduled flight appears near the destination.
• Nearby regional scenery: mesh, landclass, flatten, exclude or object-placement files outside the airport’s own folder may cover the same area.
• Memory pressure: FS2004 is a 32-bit application. A detailed airport combined with a complex aircraft, dense AI, extensive clouds and overlapping scenery can exhaust its available address space.

What does the crash pattern reveal?

The direction, time and aircraft associated with the crash help identify which type of file is responsible.

The faulting-module entry in Windows can provide a clue, but it is not a diagnosis by itself. A gauge-related module may point towards the aircraft, while a generic FS2004 or Windows module does not identify the bad scenery file.

How do I find the faulty FS2004 scenery file?

The safest method is to change one variable at a time, prove which scenery area causes the crash, and then divide that package into smaller test groups.

1. Back up the installation. Copy the airport’s complete folder outside every active FS2004 scenery path. Keep a record of any files its installer placed in shared scenery or texture folders.
2. Record a repeatable test. Note the approach direction, approximate crash position, aircraft, weather, season, simulated time and AI settings. Start a fresh flight rather than relying solely on a saved flight that may contain stale references.
3. Disable only the airport. Untick its entry in the Scenery Library, restart FS2004 and repeat the same approach under the same conditions. If the stock airport now works, the package or one of its interactions is responsible. If several locations began crashing after one installation, follow our systematic process for isolating a newly installed scenery package.
4. Check the package structure and simulator edition. A registered scenery area normally contains a Scenery folder for its BGLs and, where required, a sibling Texture folder. Confirm that the download is specifically intended for FS2004 and has not been mixed with an FSX or Prepar3D edition.
5. Verify required libraries. Install only the object libraries and other dependencies named by the package documentation. Missing libraries usually produce absent objects rather than a crash, but incomplete paths and mismatched components still need correcting; our guide to repairing missing scenery files, dependencies and library paths covers those cases. Avoid copying unrelated BGLs and textures into global folders because that makes later removal much harder.
6. Remove competing airport definitions. Search active add-on scenery folders for BGLs associated with the airport’s ICAO code, while remembering that filenames are not standardised. Move suspected duplicate AFCADs to a holding folder outside FS2004, restart and retest. Keep the airport definition supplied or recommended for the installed scenery.
7. Divide the airport BGLs into groups. Move half of the package’s .bgl files from its active Scenery folder to a temporary folder, restart FS2004 and repeat the approach. Continue testing the failing half until one file or a small group remains. BGLs can depend on one another, so the last file is a suspect rather than automatic proof; restore the other files one at a time to confirm the result.
8. Test nearby scenery separately. Disable local mesh, city scenery, landclass and other regional packages one at a time. This is particularly useful when the crash occurs from only one direction or continues after the airport’s own entry is disabled.

Do not begin by randomly removing textures. Their names may not correspond clearly to the calling model, and missing textures can create a second fault that obscures the original one. For a night-only or seasonal crash, a clean reinstall of the package is safer than deleting texture files individually.

Does changing scenery priority fix the crash?

Scenery priority can resolve overlapping placement and airport definitions, but it cannot repair a malformed BGL or make incompatible FSX content work in FS2004.

Place the specific airport above broader city or regional scenery when the packages are designed to coexist. Moving the airport higher is also a useful diagnostic test, but do not leave duplicate AFCADs active on the assumption that the lower-priority copy is harmless. Required object libraries must remain active wherever their instructions specify.

What if FS2004 crashes only with AI traffic enabled?

If setting both airline and general-aviation traffic to zero prevents the crash, investigate scheduled traffic and AI aircraft before altering the airport scenery.

Repeat the approach at the same simulated time, first with no AI and then with one traffic category enabled. Restore traffic packages in groups until the failure returns. A damaged AI model or repaint may not be requested until its scheduled aircraft enters the airport area, which explains crashes that occur only at particular times.

Keep day/night testing separate from AI testing. To check scenery textures, leave AI at zero and compare daylight with darkness. Changing the time while AI remains enabled also changes the traffic schedule, so it does not distinguish an airport texture from an arriving AI aircraft.

Could FS2004 be running out of memory near the airport?

Memory pressure is likely when reducing several high-demand features prevents the crash, particularly if the failure point varies between tests.

• Restart FS2004 before each comparison.
• Use a default aircraft and fair weather.
• Reduce airline and general-aviation traffic.
• Lower autogen, cloud load and scenery detail.
• Use lower-resolution textures supplied by the airport developer.
• Disable overlapping scenery that is not needed for the flight.

Be careful when interpreting the Scenery Complexity slider. If lowering only that setting fixes a crash at exactly the same position, it may have suppressed one defective object rather than solved a memory shortage. Memory becomes the stronger explanation when several general reductions help, or when lowering demand merely moves the crash closer to the airport.

Should I reinstall FS2004?

Reinstalling the whole simulator is unnecessary when the stock airport works after the add-on and its associated files are disabled.

First reinstall only the airport from a clean FS2004-compatible copy, following its documented folder structure and dependencies. Remember that some installers place files in shared or global folders, so unticking the airport’s Scenery Library entry may not remove every component.

Consider repairing FS2004 only if a fresh flight at the stock airport still crashes after the airport package, shared additions, nearby regional scenery and AI traffic have been removed. If the failure remains tied to a geographic point rather than this airport alone, use our wider checklist for tracing repeatable in-flight crashes by location.