Lemon-Jig-Oxygen / Double-Fifteen-Lima / Nineteen-Pizza-Cola Crash Investigation

FiveM Discussion Bug Reports
, , ,
1

Overview

This crash category receives little structured attention despite being one of the most common FiveM crash types.

Crash identifiers:

These represent the same underlying crash across different game builds. This is confirmed for at least three builds, and likely overlaps with additional crash codes pointing to the same internal failure.

This issue has existed for years.

Case Studies

User 1

  • Crash occurred on both local and production servers.

  • I connected to his server and experienced the same crash.

  • This eliminates server misconfiguration and isolated client corruption.

Isolation process:

  1. User crashes.

  2. We isolate the specific .ymap (MLO spawning ymap).

  3. We remove the associated .ytyp.

  4. Crash stops immediately.

Further testing:

  • I sent unencrypted versions of the interior files.

  • User replaced encrypted versions with unencrypted ones.

  • Client displayed bottom-left spinner: Downloading assets.

  • No crash occurred.

Important clarification:

The crash was not fixed by re-downloading encrypted assets.

It was fixed because:

  • The client successfully streamed and cached the unencrypted assets.

  • Once the .ymap successfully loaded and cached its dependencies,

  • Reintroducing encrypted assets did not reproduce the crash.

This suggests:

  • The .ymap initially failed to load.

  • After successful streaming of unencrypted versions, the required data became cached.

  • Once cached, the encrypted versions no longer triggered the crash because the streaming path was no longer failing at first load.

User 2

  • Crash traced to customname_occlusion.ymap.

  • File was not encrypted.

  • Verified byte-for-byte identical to raw version.

  • Removing the file stopped the crash in that location.

This confirms encryption is not a required condition for this crash category.

User 3

  • Crash caused by a custom .ymap.

  • Removing sf_prop_sf_apple_01b from the ymap resolved the crash.

Clarification:

The prop itself did not inherently cause the crash.

The .ymap failed to load successfully.

Removing the prop altered the ymap structure enough that it no longer triggered the failure path.

Pattern Analysis

Common factors across cases:

  • Crash is triggered during .ymap streaming.

  • Removing .ytyp or altering .ymap contents prevents the crash.

  • Occurs with both encrypted and non-encrypted .ymap files.

  • Once a .ymap successfully streams and caches its dependencies, the crash may stop occurring.

Key observation:

This is not random prop corruption.

This is not simple file damage.

This is not strictly encryption-related.

The consistent factor is:

Failure during initial .ymap load / streaming validation.

Encryption may influence how streaming is handled internally, but it is not the root condition, as shown by the occlusion ymap case.

Technical Direction

Based on debugging traces in RAGE:

image
image1294Ă—482 68.4 KB

image
image1124Ă—491 67.4 KB

image

The crash occurs inside map streaming/validation code paths during .ymap load.

This strongly suggests:

  • Streaming state failure

  • Dependency resolution failure

  • Archetype validation failure

  • Cache state inconsistency during first load

Not:

  • Incorrect bounding boxes alone

  • Server misconfiguration

  • Client instability

  • Specific GTA props by themselves

Working Hypothesis

This crash category represents:

Inability of the engine to correctly stream or validate a .ymap during initial load under certain conditions.

Once a valid streaming state is achieved and assets are cached, the crash may not reoccur — even if encrypted versions are restored.

This indicates a failure during first-load streaming resolution rather than permanent file invalidity.

Request for Structured Reports

If you experienced:

  • lemon-jig-oxygen

  • double-fifteen-lima

  • nineteen-pizza-cola

Please document:

  • Which .ymap caused it

  • Whether encryption was involved

  • Whether removing .ytyp changed behavior

  • Whether replacing with unencrypted versions allowed successful caching

  • Whether the crash occurred on first load only

The more structured data collected, the easier it becomes to isolate the exact streaming failure condition.

The objective is stable .ymap streaming and elimination of unpredictable crashes that are not caused by file corruption or user error.

2

Have you tried looking into potential race conditions with the load order?
It sounds like the .ymap might be trying to pull dependencies before the .ytyp archetypes are fully registered in memory

3

The issue is that those crash codes appear to mean absolutely different things.

I think FiveM just threw all those crashaes under the same crash code and that’s it.
That’s why every time it’s a different type of crash but with same crash code.

4

I can admit that this is a crash that I have in my server as well we are on game build 2699 and artifacts version 17000 and consistently have this crash for players in my game (dump provided)
CfxCrashDump_2026_01_30_05_33_57.zip (2.1 MB)

5

Additional data point for this crash category, with a possible contributing factor not yet mentioned in this thread.

Crash hashes observed: lemon-jig-oxygen (build 3258), double-fifteen-lima (build 3407)
Location: Vinewood Hills, coordinates x: -128.15, y: 1050.83, z: 229.07
Stack trace (consistent across both builds):
GTA5.exe/fivem.exe+[offset]
GTA5.exe/fivem.exe+[offset]
adhesive.dll+[offset]
gta-streaming-five.dll+[offset]
GTA5.exe/fivem.exe+[offset]
GTA5.exe/fivem.exe+[offset]
gta-core-five.dll+[offset]

Testing performed:

  • Disabled all custom [maps] resources → crash persisted

  • Disabled all non-map MLO/streaming resources → crash persisted

  • Tested with different clothing add-on packs (old and new) → crash persisted with both

  • Ruled out vehicle deletion / network entity handling

  • Ruled out OneSync mode (tested On, not Big)

  • Ruled out population/vegetation density (tested at minimum client settings)

  • Ruled out increase_pool_size “TxdStore” (tested with/without)

  • Reproduced on a second, independent server (different resources, different hosting) with the same location

  • Reproduced by a different player, different hardware (different GPU), different Rockstar ID, on that second server

  • Reproduced across two game builds (3258 and 3407)

Possible contributing factor identified:
The affected character’s saved spawn/logout position (stored in the framework’s database) was within ~30m of the crash coordinates. The crash occurred consistently ~15-20 seconds after connection completion in multiple crash dumps, suggesting the client was forced to stream all assets in that area simultaneously at spawn, under maximum load, rather than gradually while approaching on foot. This may explain why the crash was reproducible “in that zone” specifically — spawning there forces an immediate, high-stress streaming event at that location. Not yet confirmed whether this is the root trigger or simply increases reproduction likelihood; testing with a fresh character spawning elsewhere and then walking into the same coordinates is in progress.

Multiple crash dumps (.dmp + CitizenFX logs) available upon request.

Additional data point for this crash category.

Crash hashes observed: lemon-jig-oxygen (build 3258), double-fifteen-lima (build 3407)
Location: Vinewood Hills, coordinates x: -128.15, y: 1050.83, z: 229.07
Stack trace (consistent across both builds):
GTA5.exe/fivem.exe+[offset]
GTA5.exe/fivem.exe+[offset]
adhesive.dll+[offset]
gta-streaming-five.dll+[offset]
GTA5.exe/fivem.exe+[offset]
GTA5.exe/fivem.exe+[offset]
gta-core-five.dll+[offset]

Testing performed to isolate cause (exhaustive elimination):

  • Disabled all custom [maps] resources → crash persisted
  • Disabled all non-map MLO/streaming resources → crash persisted
  • Tested
6

it was happening in different areas for you guys?

I think the issue here is that this crash is basically “generic”, meaning fivem calls soo many different things with the same crash code that it’s impossible to debug