[BUG - Release] "Access violation in UObjectBase::IsA via ForEachUObject/FindFirstOf" - reproducible, identical crash across sessions with different mods active

[hdwiggins]

Summary

Repeated, fully reproducible access violation (0xc0000005, read) inside UObjectBase::IsA, reached via ForEachUObject --> FindFirstOf. Two separate crash sessions (with a different set of active Lua/DLL mods each time) produced an identical call stack down to the exact hex offset within UE4SS.dll, which I think rules out any single mod as the cause and points at the core object-iteration path.

Environment

• UE4SS build: experimental, "Clean 146", commit dated 2026-06-11T22:16Z

Crash signature

• Exception: c0000005 (access violation, read)
• Faulting function: UE4SS!RC::Unreal::UObjectBase::IsA+0x1e (module offset 0x36d3be in both dumps)
• Call chain (identical offsets in both dumps):
  ... --> LuaMadeSimple::Lua::call_function --> Unreal::Hook::FCallbackOptions::FCallbackOptions --> UObjectGlobals::ForEachUObject --> UObjectGlobals::FindFirstOf --> UObjectBase::IsA (crash)
• The register holding the "object" pointer at fault time contains what appears to be fragments of UTF-16 text rather than a valid UObject address in both dumps (possibly FindFirstOf/ForEachUObject handing back a pointer into FName/FString data instead of a live UObject).

Reproduction notes

• First crash: StateIndicator (third-party Lua+DLL mod) enabled, along with several other Lua mods (SwimSpeed_Increased, LockpickSettings, G1R_InGameClock, etc.)
• Second crash: StateIndicator disabled, all other mods unchanged; produced the exact same stack, same offset, ruling out that specific mod.
• Both crashes occurred a short time after gameplay events likely involving object destruction/GC (an NPC load transition in the first case, closing a lockpicking minigame on a chest in the second); consistent with a race between object teardown and the iteration in ForEachUObject.

What I've already ruled out

• Not a bUseUObjectArrayCache staleness issue (already false)
• Not specific to any one Lua mod's logic (identical stack with mod disabled)

Attachments

• crash_1.dmp (StateIndicator enabled)
• crash_2.dmp (StateIndicator disabled)
• UE4SS

.log

• mod list.png

UE4SS.log

(enabled mod list at time of second crash)

Happy to provide more detail, test a patched build, or gather anything else that would help; this is 100% reproducible on my end.

[Shirowwww]

I think I found this one. Not on Windows, I hit the same thing on a Linux dedicated server (Palworld, UE 5.1), same signature: the "object" pointer holds text instead of a UObject.

ForEachUObject_Chunked walks every slot of every chunk (NumElementsPerChunk) instead of stopping at GetNumElements(). Chunks are allocated at full capacity, so the tail of the last chunk is memory the engine never wrote an FUObjectItem into, or has reused since, and FName/FString text is a common tenant. The existing guard can't catch it:

const auto Object = ObjectItem->GetUObject();
if (ObjectItem->IsUnreachable() || !Object) { continue; }

ObjectItem isn't an item there, so IsUnreachable() reads garbage too. Then FindFirstOf does Object->GetClassPrivate() and IsA on it, and you're dereferencing text as a vtable. ForEachUObject_NonChunked bounds it correctly with GetNumElements(), the chunked paths (what UE4.25+/UE5 use) don't.

Fix is to clamp each chunk to what's actually there:

const auto NumElements = ObjObjects.GetNumElements();
const int64_t ChunkFirstElement = (int64_t)ChunkIndex * TUObjectArray::NumElementsPerChunk;
if (ChunkFirstElement >= NumElements) { break; }
const int64_t ElementsLeft = (int64_t)NumElements - ChunkFirstElement;
const int32_t ItemsInChunk = ElementsLeft < TUObjectArray::NumElementsPerChunk
                           ? (int32_t)ElementsLeft : TUObjectArray::NumElementsPerChunk;
for (int32_t ItemIndex = 0; ItemIndex < ItemsInChunk; ++ItemIndex) { ... }

Same for ForEachUObject_ChunkedInRange and the single chunk variant. FindFirstOf also derefs Object/Class before validating, while FindAllOf already guards, so that's worth a null check too.

Being honest about what I can and can't claim: I never reproduced your Windows crash, and on my side the storm I was chasing turned out to be a box64 bug (ptitSeb/box64#4055), so this fix alone didn't stop my crashes. But the out of bounds read is real and independent of platform, and it explains text showing up where an object pointer should be. Whether it's exactly your crash, you'd have to confirm.

Also bUseUObjectArrayCache being false doesn't help here, it's the iteration bound that's wrong, not the cache.