[Bug] Client instantly crashes when restart/ensure any resource

[ayerosu]

Summary

Client instantly crashes when we restart or ensure any resource after 153 update.

Note: No crashes occurred when restarting the mini resources like blip-manager

Issue type

Client

Repro rate

Always

Server build version

B153

OS

No response

CPU

No response

GPU

No response

RAM

No response

Storage type

None

Connection type

None

ISP and bandwidth

No response

DxDiag

No response

Network graph

No response

Platform

Linux

OS version / distribution

Debian 11

CPU

No response

RAM

No response

Using txAdmin?

Yes

Hosting provider

Self-hosted

Machine type

Dedicated

/perf endpoint output

No response

DDoS protection

No response

ulimit -n value (Linux only)

No response

Docker Compose file (Docker only)

No response

Steps to Reproduce

1. Restart any resource eg. ensure example_hudscript

Expected Behavior

Resource should be restart normally without any client crashes.

Actual Behavior

Client crashes instantly.

Evidence

The game has crashed: Oh no, we crashed!
Report Code: 533968db-6520-4dc7-bb30-56498ff9efd6

Additional Context

No response

[SlugTeamSix]

Reproduced on Windows b153 after ensuring a resource as well.

7633e354-0e99-4877-9b02-8f4d15f7ae6e

[ESK0]

Same issue.. we need fix asap

[shaiadams10]

Same issue here on a Windows server, FXServer b153 (Enhanced early access). Some data that may help narrow it down:

Environment

• Server: FXServer b153 (Windows 11), txAdmin
• Client: FiveM for GTAV Enhanced early-access (in-game label b145, launcher build 151, client updated 2026-09-23), GTA V Enhanced 1.0.1158.16

Repro

1. Join the server.
2. stop, restart or ensure an already-started script resource (txAdmin, server console, or ExecuteCommand from another resource all behave the same).
3. Every connected client crashes, in the same second as the command. Two players on different PCs crashed together.

A plain stop is enough; the start half of a restart is not needed.

Regression window
The same ensure of the same resources, with unchanged code and a player connected, did not crash on b139 with the previous client: at least 8 times on Sep 22 and twice on Sep 23 (01:16, 01:27). Since the Sep 23 client update and the move to b153, every stop of those resources crashes (14 crashes so far).

What crashes / what doesn't

• Crashes: our Lua resources (chat replacement, NUI HUD, framework bridge, map/IPL manager, scene editor). Between them they use exports, RegisterCommand/RegisterKeyMapping, NUI, state bag handlers and onClientResourceStop/onResourceStop handlers.
• No crash: restarting stock baseevents (one test), which matches the "small resources are fine" note above.
• The map/IPL manager registers no commands and still crashed, so command teardown alone doesn't explain it, although [Bug] UnregisterCommand in C# crashes the game #537 (UnregisterCommand crash, same update) may be related.

Crash signature (identical in every dump since the update)

• EXCEPTION_ACCESS_VIOLATION writing address 0 at ntdll!RtlAcquireSRWLockExclusive+0x35 (lock bts [rcx], rcx = 0), i.e. a lock taken through a null pointer.
• On the game update thread. Return addresses in fivem-client.dll: +0x19830db, +0x20c15bb, +0x209bb82, +0x199c72b, +0x197f4e8, +0x169c0f5, +0x18a6be0, +0x18a71d0, then GTA5_Enhanced.exe+0x13d293c.
• The frame at +0x169c0f5 holds the profiler scope string lua tick, so the fault happens inside a client Lua runtime tick right after the resource stops.

Crash IDs
ac3511e6-578e-4050-b310-bb80509aea9f
1c853aa8-d76c-416c-9359-e1d4bffd9517
0ee18f3d-9304-4638-9366-b20ab50410f3
f03c062e-ee1b-4b1c-b865-e4324c19ceb1
279f145e-84e5-4ad5-8f16-517f267483f3
f9c82368-574f-458b-aa1c-c29b9866b8d8
49861dbd-1581-4663-89a8-6c36097df90a
20572df8-4ec8-435d-87bb-89391bed3d1b
0ff7e40d-337f-404c-88af-7bf2d3b03991
087209ad-ed27-4e9e-9a82-ec39e72a4050

Happy to send dumps privately or test a minimal repro resource if that helps.

[Gogsi]

Hello,
A fix for this issue has been implemented in the latest version of FiveM for GTAV Enhanced. Please try again and let us know if the issue persists. Thanks for your help!

[ayerosu]

Yep its fixed, thanks.