[Bug] Client crash: Error: Script error in Native GetClosestObjectOfType: exception at game RVA 0x1493AE

[TheDutchDev]

Summary

Update: see first reply for more info

Causes a game crash when done in an interval on JS clientside.

Error: Script error in Native GetClosestObjectOfType: exception at game RVA 0x1493AE

It does not happen every time. For us, it happened on prop_atm_02 , spawned by the GTA world (not custom script object). But seems to happen randomly or so.

I can provide more details if necessary.

Issue type

Client

Repro rate

Always

Server build version

b104 (hotfix 7)

OS

Windows 11

CPU

Intel Core i7-12700K

GPU

NVidia RTX 5070TI

RAM

96GB DDR4

Storage type

SSD NVMe

Connection type

Ethernet

ISP and bandwidth

1GB up/down Glass Fiber

DxDiag

No response

Network graph

No response

Platform

None

OS version / distribution

No response

CPU

No response

RAM

No response

Using txAdmin?

None

Hosting provider

None

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. Call the native in a loop. Perhaps specifically for that object as well, although I do think it can also be caused on other objects
   2.Wait for crash

Expected Behavior

Should not crash

Actual Behavior

Crashes client

Evidence

No response

Additional Context

We are using this in combination with draw outline native to highlight interactables in the world

[TheDutchDev]

To be honest, this is most likely related to these:

#133
#197

Maybe this one too: #309

Seems like anything with objects on client-side is unstable for some reason. Sometimes it crashes on GetClosestObjectOfType. Sometimes on FindNextObject, sometimes on RemoveObject (#309), GetGamePool('CObject') etc.

The likelyhood of crashing increases greatly when driving around the city at high speeds while calling these natives in an interval (eg 100ms, or 500ms, or faster)

I had Claude dig through this extensively, reading client crash dumps and whatnot. I'm not claiming this as a single-source-of-truth, since we all know AI can output the weirdest shit. However, regardless of that, the output may be valid, so here is a bunch of it:

Call order is strict — object → GetEntityModel → findNext → FindNextObject → next object. FindNextObject is the last native invoked, on iteration 595 after 594 successful ones in the same pass. Same WER signature: 0x80000003 @ +0x1493AE.

Exception code: 0x80000003   Fault offset: 0x00000000001493ae
GTA5_Enhanced.exe 1.0.1158.13


GTA5_Enhanced!Ordinal0+0x1493ae      int 3          ← the assert
GTA5_Enhanced!Ordinal0+0x14922a                     ← game caller
fivem_client + 0x02031078
fivem_client + 0x021043fa
fivem_client + 0x021256d9
fivem_client + 0x021250e3
fivem_client + 0x02825ada
0x00007ffe989d7219                                  ← V8 JIT


Four things worth having:

The faulting thread is named "update" — the main script thread. Confirms this is the script-invocation path, not a background streaming thread doing its own thing.

The assert is reached through Cfx's code, not the game's. Five fivem-client.dll frames sit between the JS and the game function that asserts. Those RVAs are directly symbolizable by Cfx — they're their own binary. (The CrashForExceptionInNonABICompliantCodeRange+... labels cdb prints are just the nearest export, not the real functions; I converted them to module-relative RVAs above.)

The bottom frame is V8 JIT — !address puts 0x7ffe989d7219 in an unbacked 622 MB region. That's the resource's compiled JS calling the native.

Build stamps for the report: fivem-client.dll 6A6B7536 (2026-07-30 18:00:54), GTA5_Enhanced.exe 1.0.1158.13.

So ya, take it with a grain of salt. But regardless of this, considering multiple people have reported crashes in regards to client objects/pools over the past week, I do think these issues are worth investigating. Basically what it comes down to right now is that no-one can reliably use CObject pool scanning and/or use client-side object natives at all (reliably).

[wolfram-cfx]

We also assume its related to the same issue as #133.

[TheDutchDev]

Yes, I mentioned that in my reply here as well. I tried the FindObject workaround posted there, which crashed less often but still crashed. When switching back to the GetGamePool variant, it crashed a lot more often.

When that ticket is patched, I'll re-test this to make sure it's fixed :)

[stelianclaudiu92-commits]

Great comment. UP!

[Gogsi]

A fix for this bug has been implemented and is available in the August 4 patch. Please try again and let us know if the issue persists. Thanks for your help!