DayZPlayerCameraBase caches the weapons command modifier once, in its constructor:

// scripts/4_World/entities/manbase/dayzplayer/dayzplayercamera_base.c:97
m_CommandWeapons = pPlayer.GetCommandModifier_Weapons();

and then dereferences it with no null check in two places:

:132  float target        = m_CommandWeapons.GetBaseAimingAngleUD();   // UpdateUDAngleUnlocked
:234  float aimingUDAngle = m_CommandWeapons.GetBaseAimingAngleUD();   // UpdateUDAngle

GetBaseAimingAngleUD() is proto native (scripts/3_Game/human.c:1095), so the script VM's null check is bypassed and the engine reads a member off a null this, faulting at offset 0x74.

GetCommandModifier_Weapons() returns NULL for a DayZPlayer whose command machine has not been initialised — a character that has never run a CommandHandler. DayZPlayerImplement.CameraHandler will happily return DAYZCAMERA_1ST for such a player: its unconditional first-person fallthrough (scripts/4_World/entities/dayzplayerimplement.c:2858) has no precondition on command state, and it defensively null-checks GetInputController() two lines earlier while the camera it hands you does not extend the same courtesy to m_CommandWeapons.

Because line 97 is the only write to m_CommandWeapons anywhere in the script tree, the snapshot is never refreshed. A camera constructed against an uninitialised player is therefore permanently broken and faults on every subsequent OnUpdate, rather than recovering once the command machine comes up.

Every other vanilla consumer of this pointer does null-check it — e.g. scripts/4_World/entities/dayzplayerimplement.c:2638 and scripts/4_World/systems/inventory/dayzplayerinventory.c:283 both assign to a local and test it. The two camera reads look like the oversight.

On a dedicated server, from a mod or mission script:

1. Entity e = GetGame().CreatePlayer(identity, "SurvivorM_Mirek", pos, 0, "NONE");

2. GetGame().SelectPlayer(identity, PlayerBase.Cast(e)); — in the same frame, before the new character has run a single CommandHandler.

3. The client that owns identity constructs DayZPlayerCamera1stPerson for the new character and crashes on its first OnUpdate.

The same happens when control is handed back to a character that was created earlier but dropped from the connection's selection before it ever simulated. It is a race: the wider the gap between creation and selection, the less often it fires, which is why it presents as intermittent.

No crash. Either null-check m_CommandWeapons at both reads and fall through to the existing non-aiming path, or re-resolve it from m_pPlayer when it is null so the camera recovers once the command machine is available.