What is the issue you’re having?
RedM reproducibly crashes when reconnecting to the same local server without fully closing and restarting the RedM process.
The initial connection succeeds and the client enters the session normally. All relevant client-side tests complete successfully. After disconnecting and reconnecting using the same RedM process, the client reaches SESSION_STATE_ENTER, receives connectOK, and starts the game reload path. Approximately 1.2 to 1.5 seconds later, the main game thread crashes.
Two independently preserved attempts produced the same result:
Crash key: king-mountain-alaska
Crash hash: redm.exe+8006460
Exception: 0xC0000005 access violation
Operation: WRITE
Invalid target address: 0x0000000000000001
Fault module: RedM_b1491_GTAProcess.exe
Fault module offset: 0x8006460
Crash thread: MainThrd
Both logs also contain two occurrences of:
SendNetPacket … called from multiple threads!
The first occurrence appears during disconnect/shutdown, while the second occurs near the final crash.
The server successfully creates the reconnect session before the client crash. After the crash, the server closes the session and returns to ready=true, active=0 and pending=0. No server-side session or reservation leak was observed.
Using a completely fresh RedM process for every connection completed three consecutive cycles without this crash. The issue occurs when the same RedM process is reused after disconnecting.
What have you tried already to fix the issue?
I tested the issue using multiple controlled connection cycles.
The same-process reconnect crash was reproduced in two preserved attempts. Both attempts produced the same crash key, crash hash, access violation type, invalid write target, fault module, and module offset.
I then tested a workaround where RedM is fully closed after every disconnect and a completely fresh RedM process is started before reconnecting. Three consecutive fresh-process cycles completed successfully without this crash.
I also verified the server state after each client crash. The reconnect session was closed correctly and the server returned to ready=true, active=0 and pending=0, with no session or reservation leak.
The two preserved minidumps and logs were compared. Both crashes occurred during the same reconnect/game-reload lifecycle and used the same set and versions of 286 loaded modules. No server resource or configuration change resolved the same-process reconnect crash.
The current workaround is to fully close RedM before reconnecting.
What server did you get this issue on?
Private local development server (localhost)
Windows version
Windows 10 19045.5247
System specifications
Operating system: Windows 10 64-bit, build 19045.5247
Primary GPU: NVIDIA GeForce RTX 3080
Secondary integrated GPU: AMD Radeon™ Graphics
RedM game process: RedM_b1491_GTAProcess.exe
Observed RedM module version: 1.0.0.33206
Vulkan API reported by crashometry: 1.4.341
Antivirus software
Microsoft Defender Antivirus (Windows Security)
CitizenFX crash zip file (‘Save information’ on a crash)
OneLife_RedM_R4_Cfx_Issue_20260722.zip (4.71 KB)
Additional comments
The attached ZIP is a sanitized evidence package containing the reproduction steps, technical crash signature, timing information, environment details, SHA-256 checksums, and privacy scan summary.
Raw crash dumps and raw CitizenFX logs are not attached publicly because they may contain private server, network, license, identifier, or local-path information.
The original raw evidence has been preserved with verified SHA-256 hashes and can be provided privately to authorized Cfx staff if required.
No new crash was reproduced while preparing this report. The current workaround is to fully close RedM and start a fresh process before every reconnect.
