[Bug] Multiple natives failing on .NET after B103 update

[unknown-urge]

Summary

Native.GetGroundZFor_3dCoord and its alternate-hash overload Native.GetGroundZFor_3dCoord_2 throws an unrecoverable native access violation (surfaced as System.Runtime.InteropServices.SEHException) when invoked from a client script's async continuation. The exception is not catchable by an ordinary try/catch around the call site; it propagates past all managed exception handling straight to the process's top-level unhandled-exception logger.

This reproduces with both documented hash variants shipped for CitizenFX.FiveM.Client 0.0.2-alpha (0xB1EAADCB692D69CE for the plain name and 0xA93AC190 for the _2 overload), which rules out a simple incorrect native hash. It also reproduces after replacing Task.Delay with CitizenFX.Base.TickScheduler.ScheduleDelay so the continuation is confirmed to resume on the main script thread, ruling out thread affinity as the sole cause.

Issue type

Client

Repro rate

Always

Client build version

b103

OS

Windows

Steps to Reproduce

1. Register the following event handler in a client-side C# resource (using CitizenFX.FiveM.Client 0.0.2-alpha):

[OnNetEvent("test:groundZCrash")]
public static async Task OnTestGroundZCrash()
{
    Native.RequestCollisionAtCoord(0f, 0f, 100f);
    Native.NewLoadSceneStartSphere(0f, 0f, 100f, 50f, 0);

    // Uses CitizenFX.Base.TickScheduler.ScheduleDelay (not Task.Delay)
    // so this continuation is confirmed to resume on the main script thread.
    while (!Native.IsNewLoadSceneLoaded())
    {
        await CitizenFX.Base.TickScheduler.ScheduleDelay(50);
    }

    // Crashes here — SEHException, not catchable via try/catch.
    var found = Native.GetGroundZFor_3dCoord(
        0f, 0f, 105f,
        out var groundZ,
        false,
        false);

    // Also crashes identically with the alternate hash:
    // var found = Native.GetGroundZFor_3dCoord_2(
    //     0f, 0f, 105f,
    //     out var groundZ,
    //     false,
    //     false);
}

2. Start the resource on the client.
3. Trigger the event once from the server (API.EmitClient(...)) or via any local test command.
4. Observe the crash immediately when GetGroundZFor_3dCoord (or _2) is invoked.

No loop, repeated triggering, or additional load is required — a single invocation is sufficient to reproduce.

Expected Behavior

The native should return true/false and populate groundZ with the resolved ground height, matching its documented signature and the behavior of other natives using equivalent out-parameter bindings (for example, GetGroupSize, which successfully marshals multiple out parameters through the same invocation mechanism).

Actual Behavior

System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.

System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.
   at CitizenFX.Base.NativeApi.Invoke(UInt64 hash, String nativeName)
   at CitizenFX.FiveM.Client.Native.GetGroundZFor_3dCoord(
       Single VecCoors_x,
       Single VecCoors_y,
       Single VecCoors_z,
       Single& ReturnZ,
       Boolean waterAsGround,
       Boolean ignoreDistToWaterLevelCheck)
   at <call site>

This is thrown even when the call site is wrapped in try { ... } catch (Exception ex) { ... }. The catch block is never reached, and the exception instead propagates directly to the process's top-level unhandled exception handler, consistent with a native access violation or other corrupted-state exception rather than a normal managed exception.

Additional Context

[WithLithum]

consistent with a native access violation or other corrupted-state exception rather than a normal managed exception

SEHException means that an exception came from C++ side and CLR don't know what it means. Access violations from C++ side are automatically thrown as AccessViolationException. I am not super familiar with the details but upon looking up the docs I suspect that SEHException in itself is not recoverable.

[unknown-urge]

One more note: The issue seems to happen on both 0.0.3 and 0.0.2 Nuget versions.

[europium-cfx]

Hey! This issue has been fixed in the latest patch b123 and CitizenFX.FiveM NuGets 0.0.4-alpha. Please try again and let us know if the issue persists.

[unknown-urge]

Can confirm this is fixed.