What is the issue you’re having?
We are currently testing the RedM experimental branch:
UpdateChannel=specific/feature/redm-physical-player-extension
Since moving to this branch, two different players on our server have reported the same crash:
“Game Heap Corruption Detected”
The crash signature is the same on both affected clients:
- gta-core-rdr3.dll+0x5E59A
- intentional write to 0xDEED
- “Game Heap Corruption Detected”
We analyzed a full memory dump from one affected player in WinDbg. The final crash appears to be an intentional fatal/assert path inside CFX after allocator corruption was detected, rather than the original write itself.
The relevant strings in the binary point to:
components/gta-core-rdr3/src/SimpleAllocator.cpp
The embedded allocator error strings are:
- Game Heap Corruption Detected
- Corrupt guard
- Corrupt next guard
- Corrupt next->prev
From the full dump, we identified a corrupted allocator node in the CFX/RAGE game allocator region. The previous node appears structurally valid, but the next node has a corrupted first DWORD/guard.
Healthy node:
000002fe1b6e6290 1b6e6290 00003da0 00ae7910 02adbeef
Corrupted next node:
000002fe1b6ea040 1b9ad0bc 00136cd0 00003db0 0aadbeef
Expected first DWORD at 1b6ea040:
1b6ea040
Actual first DWORD:
1b9ad0bc
So only the first 4 bytes of the next allocator node header/guard appear corrupted, while size, prev offset and allocator flags still look valid.
This suggests a localized 32-bit overwrite in the CFX/RAGE game allocator.
This does not appear to affect all players. We have around 250 players at peak times and currently only 2 have reported this exact issue. However, both affected players produce the same crash signature, and the issue only started being reported after switching to the physical-player-extension experimental branch.
One affected player initially noticed the issue after visiting a tailor and attempting to use a fixBodyParts command, but we do not currently have a deterministic reproduction case.
What have you tried already to fix the issue?
We already performed the following investigation steps:
- Collected the normal CitizenFX crash dump ZIPs from two different affected players.
- Confirmed that both clients crash with the same signature:
- gta-core-rdr3.dll+0x5E59A
- Game Heap Corruption Detected
- Enabled:
EnableFullMemoryDump=1
in CitizenFX.ini for one affected player. - Collected and analyzed a full memory dump in WinDbg.
- Ran:
- !analyze -v
- .ecxr
- !heap -triage
- !heap -s
- allocator/node memory inspection commands
- Confirmed that normal Windows heap triage did not report standard NT heap corruption.
- Confirmed that the crash is triggered by an intentional write to 0xDEED after allocator validation fails.
- Identified the allocator region and the corrupted next-node guard in memory.
- Compared this with a second player who has the same overall crash signature on different hardware.
We have not yet found a deterministic reproduction. We can provide:
- crash ZIPs
- logs
- WinDbg findings
- full memory dump from one affected client
What server did you get this issue on?
Wild Hearts
Error screenshot(s)
Windows version
Windows 10/11 x64 (affected dump shows 10.0.26100.1)
System specifications
Affected client #1:
- GPU: AMD Radeon RX 6700 XT
- API: Vulkan
- OS: Windows 11 24H2 / 10.0.26100.1
- RedM process: RedM_b1491_GTAProcess.exe
- Image/Process version: 1.0.0.36757 / 2.0.0.36757
Affected client #2:
- GPU: NVIDIA GeForce GTX 1070
- NVIDIA driver: 582.78
- API: Vulkan
Server context:
- OneSync enabled
- OneSync Big enabled
- Experimental branch:
specific/feature/redm-physical-player-extension - Branch/build seen in crash telemetry:
feature/redm-physical-player-extension v1.0.0.20260928
Antivirus software
Unknown / not confirmed by affected player yet
CitizenFX crash zip file (‘Save information’ on a crash)
CfxCrashDump_2026_09_30_22_47_53.zip (2.3 MB)CfxCrashDump_2026_09_30_16_03_19 (1).zip (2.25 MB)
Log files
WinDbg_Analysis_78cc_2026-10-01_21-00-51-741.txt (105 KB)
Additional comments
Additional note:
We have a full memory dump (~16 GB uncompressed) from one affected player and can provide it directly to a CFX developer on request. Because of the file size, we are not attaching it publicly unless specifically requested.