[Bug] GetPedHeadBlendData permanently freezes the client when called shortly after a fresh SetPlayerModel/SetPedHeadBlendData on FiveM Enhanced

[LandminenTester]

Summary

Opening the custom character-creation NUI causes a complete client freeze that leads to a full crash roughly 15-20 seconds later, with no script/Lua error and no crash report ID. Extensive server- and client-side instrumentation (added print() before/after every native and event/callback involved in the flow) traced this down to a single native: GetPedHeadBlendData never returns when called on the local player ped shortly after that ped's model was switched via SetPlayerModel and its head blend data was written via SetPedHeadBlendData. Execution reaches the line calling GetPedHeadBlendData (confirmed via a print() immediately before it) and never proceeds past it — no exception, no timeout, nothing. This reproduces from multiple independent call sites within the same flow (a RegisterNUICallback handler, and a plain RegisterNetEvent/thread context), and does not reproduce on the FiveM Legacy client with identical server, resources, and repro steps.

Issue type

Client

Repro rate

Always

Server build version

FXServer-early-access b97 win32

OS

Win 11 / Newest

CPU

AMD Ryzen 9 7950X3D

GPU

RTX 2070 Super

RAM

32GB DDR5

Storage type

SSD NVMe

Connection type

Ethernet

ISP and bandwidth

250 Mbps

DxDiag

No response

Network graph

No response

Platform

Windows

OS version / distribution

Localhost

CPU

Localhost

RAM

Localhost

Using txAdmin?

Yes

Hosting provider

Self-hosted

Machine type

None

/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. Connect, trigger the private script's character-creation flow, which:
   a. Switches the local player's ped model to a freemode ped (SetPlayerModel after RequestModel/HasModelLoaded).
   b. Writes head blend data to the new ped via SetPedHeadBlendData(ped, ...).
   c. Shortly afterwards (same tick or a few frames later — reproduces both from inside a RegisterNUICallback handler and from a plain event handler) reads it back via GetPedHeadBlendData(ped).
2. The client freezes completely at step 1c. No further script output occurs after the print() immediately preceding the GetPedHeadBlendData call.
3. ~15-20 seconds after the freeze begins, the client crashes and drops back to the launcher.

Minimal, script-independent repro (does not require our private resource):

RegisterCommand('repro_headblend_freeze', function()
    -- Preparation: first set a NON-freemode ped model, to replicate the real starting
    -- state (e.g. a multichar preview ped) before the creator takes over.
    local nonFreemodeHash = GetHashKey('a_m_y_business_01')
    RequestModel(nonFreemodeHash)
    local t1 = 0
    while not HasModelLoaded(nonFreemodeHash) and t1 < 5000 do Wait(10) t1 = t1 + 10 end
    SetPlayerModel(PlayerId(), nonFreemodeHash)
    SetModelAsNoLongerNeeded(nonFreemodeHash)

    print(('Preparation done: current model=%d (not freemode), waiting a moment...'):format(GetEntityModel(PlayerPedId())))
    Wait(2000) -- give it time so the non-freemode state is definitely "settled"

    -- Actual repro: switch to freemode + write head blend data + read it back
    local freemodeHash = GetHashKey('mp_m_freemode_01')
    RequestModel(freemodeHash)
    local t2 = 0
    while not HasModelLoaded(freemodeHash) and t2 < 5000 do Wait(10) t2 = t2 + 10 end
    SetPlayerModel(PlayerId(), freemodeHash)
    SetModelAsNoLongerNeeded(freemodeHash)

    local ped = PlayerPedId()
    print(('Freemode switch done: current model=%d, ped=%d'):format(GetEntityModel(ped), ped))

    SetPedHeadBlendData(ped, 0, 0, 0, 0, 0, 0, 0.5, 0.5, 0.0, false)
    print('SetPedHeadBlendData done, now calling GetPedHeadBlendData...')

    local ok = GetPedHeadBlendData(ped) -- client freezes here; this print is the LAST output
    print('GetPedHeadBlendData returned, ok=' .. tostring(ok)) -- never reached
end)

We also confirmed a delay does not prevent it — inserting Wait(100) between the SetPedHeadBlendData write and the GetPedHeadBlendData read still freezes reliably, so this isn't a same-tick race that can be waited out.

Expected Behavior

GetPedHeadBlendData(ped) returns the head blend values that were just written, and the character-creation NUI opens normally.

Actual Behavior

The client freezes completely and becomes fully unresponsive at the GetPedHeadBlendData call. No exception, no error, no crash report ID, no further console output of any kind (F8 console, server console, or NUI console all go silent at the exact same point). ~15-20 seconds later the process crashes and returns to the launcher — this looks like a client-side watchdog/timeout finally killing the hung process rather than a normal crash.

Evidence

After the freeze I'm back at the launcher, and shortly after that the whole client crashes. The resource in question (vinewood_creator_v2) is a private/selfmade character creator that triggers the NUI call, but the root cause is isolated to the GetPedHeadBlendData native itself and reproduces with the minimal snippet above, independent of that script. All logs from start to crash are attached.

fivem-for-gtav-enhanced.log-2026-07-25_20-30-12.log
cef-2026-07-25_20-30-12.log
fivem-launcher-2026-07-25_20-29-14.log
2a02ce95-baed-478b-86d3-6acc83f79a5a.dmp

Additional Context

Our original report assumed this was caused by opening the NUI (SetNuiFocus/SendNUIMessage) in general, since that's what visibly preceded the freeze. After adding instrumentation around every native/event/callback in the flow, we found opening the NUI itself is not the trigger — it's specifically the first GetPedHeadBlendData call that happens to follow shortly after, triggered by the NUI's first callback into the script. We reproduced the same freeze from several independent call sites in our script that all ultimately call GetPedHeadBlendData on the freshly model-switched ped, with no NUI involved in at least one of those call sites. The minimal repro above has no NUI dependency at all and should reproduce the same freeze. We can still provide access to the private script privately if that helps, but the minimal snippet should be sufficient to reproduce and isolate the native itself. Does not reproduce on FiveM Legacy with identical steps.

[LandminenTester]

I updated the whole report after finding the issue in my code so that the report template now is fully representing the real issue

[Benazito]

I have a same problem #208

[Gogsi]

Closing as duplicate of #208. I'll repost the repro there