My Game Crashes In Specific Locations After Packaging, But Not In Editor?

Greetings, I’m working on a concept/prototype and it’s done, and everything in the editor functions to near perfection (Hooray!) However, there are two spots on the map that make the game crash once the player reaches them (Boo!) I’m not totally certain what’s going on here at all. Both crash sites are underwater in the game, but I’ve packaged the game both with and without the water trigger volumes, and it crashes either way.

Interestingly, if I right click on the .uproject file and click launch game, these crashes don’t happen. :man_shrugging: Currently I am running 4.26.2 with Windows 10 on a pretty beefy laptop.

This is what the crash reporter has to say:

LoginId:157902d64d1ed70bc610c5b1a2f4aaa9
EpicAccountId:618fda244e3f461d8fbd1f1c95886188

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0xffffffffffffffff

ProjectMoon_Win64_Shipping!TArray<FNiagaraParameterStore * __ptr64,TSizedDefaultAllocator<32> >::AddUniqueImpl<FNiagaraParameterStore * __ptr64 const & __ptr64>()
ProjectMoon_Win64_Shipping!GameThread_FindAllScalarParameterNames()
ProjectMoon_Win64_Shipping!UMaterialInstanceDynamic::K2_InterpolateMaterialInstanceParams()
ProjectMoon_Win64_Shipping!UMaterialInterface::OverrideBlendableSettings()
ProjectMoon_Win64_Shipping!FSceneView::OverridePostProcessSettings()
ProjectMoon_Win64_Shipping!UWorld::AddPostProcessingSettings()
ProjectMoon_Win64_Shipping!FSceneView::StartFinalPostprocessSettings()
ProjectMoon_Win64_Shipping!ULocalPlayer::CalcSceneView()
ProjectMoon_Win64_Shipping!UGameViewportClient::Draw()
ProjectMoon_Win64_Shipping!FViewport::Draw()
ProjectMoon_Win64_Shipping!UGameEngine::RedrawViewports()
ProjectMoon_Win64_Shipping!UGameEngine::Tick()
ProjectMoon_Win64_Shipping!FEngineLoop::Tick()
ProjectMoon_Win64_Shipping!GuardedMain()
ProjectMoon_Win64_Shipping!GuardedMainWrapper()
ProjectMoon_Win64_Shipping!WinMain()
ProjectMoon_Win64_Shipping!__scrt_common_main_seh() [d:\agent_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288]
kernel32
ntdll

I don’t read this stuff very well but I’m seeing the word postprocessing a lot, is there a problem with one or more of my post processing volumes? Any insight would be hugely appreciated.

Specifically this stands out to me

ProjectMoon_Win64_Shipping!GameThread_FindAllScalarParameterNames()

I you have potentially have a post process volume that is referencing a material and (something) is trying to change a get all parameters on it. And note that this is directly targeting a material instance. Usually being able to directly change parameters at runtime requires a dynamic material instance. Could be related to that?

Try watching the log while you’re playing in the editor. I think it might be an out of bounds array access. They are just warnings in the editor, but can cause a crash at runtime.

2 Likes

Try watching the log while you’re playing in the editor. I think it might be an out of bounds array access. They are just warnings in the editor, but can cause a crash at runtime.

Ok, that was really good advice. I did that, and I did get an error message. Surprisingly, it returned an AnimBluePrint error.

AnimBlueprintLog: Error: No Inertialization node found for request from transition ‘Idle Walk Run’ to ‘Jump’ in state machine ‘Leg State’ in anim blueprint ‘/Game/PlayerContent/3d_asseets/Animation/player_animbp.player_animbp’. Add an Inertialization node after this state machine.

Now I know for sure where exactly the issue is, and therefore can solve it. Thanks bro!
:heart: :orange_heart: :yellow_heart: :green_heart: :blue_heart: :purple_heart:

1 Like

Yeah that caught my eye too, I do use few of these kinds of materials that change in runtime based on scalar values. They’ve kind of been a pain the ■■■ tbh, as I’ve known the “Set scalar/vector parameter” nodes to simply stop working lol. I still haven’t fixed my crashes just yet so I’m still holding my breath that it’s not something to do with those :no_mouth: :fearful:

Hmm no luck. I got rid of that animbp error message that appeared in the editor, but it still crashes at the same points. Which seems bizarre because those messages only appeared at the crash sites. No other error messages appear in the editor’s output log but it still crashes at the same points, and only after packaging.

This is what the crash reporter has to say but I think it’s identical to the last one I pasted:

LoginId:157902d64d1ed70bc610c5b1a2f4aaa9
EpicAccountId:618fda244e3f461d8fbd1f1c95886188

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0xffffffffffffffff

ProjectMoon_Win64_Shipping!TArray<FNiagaraParameterStore * __ptr64,TSizedDefaultAllocator<32> >::AddUniqueImpl<FNiagaraParameterStore * __ptr64 const & __ptr64>()
ProjectMoon_Win64_Shipping!GameThread_FindAllScalarParameterNames()
ProjectMoon_Win64_Shipping!UMaterialInstanceDynamic::K2_InterpolateMaterialInstanceParams()
ProjectMoon_Win64_Shipping!UMaterialInterface::OverrideBlendableSettings()
ProjectMoon_Win64_Shipping!FSceneView::OverridePostProcessSettings()
ProjectMoon_Win64_Shipping!UWorld::AddPostProcessingSettings()
ProjectMoon_Win64_Shipping!FSceneView::StartFinalPostprocessSettings()
ProjectMoon_Win64_Shipping!ULocalPlayer::CalcSceneView()
ProjectMoon_Win64_Shipping!UGameViewportClient::Draw()
ProjectMoon_Win64_Shipping!FViewport::Draw()
ProjectMoon_Win64_Shipping!UGameEngine::RedrawViewports()
ProjectMoon_Win64_Shipping!UGameEngine::Tick()
ProjectMoon_Win64_Shipping!FEngineLoop::Tick()
ProjectMoon_Win64_Shipping!GuardedMain()
ProjectMoon_Win64_Shipping!GuardedMainWrapper()
ProjectMoon_Win64_Shipping!WinMain()
ProjectMoon_Win64_Shipping!__scrt_common_main_seh() [d:\agent_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288]
kernel32
ntdll

Guess I’ll start seeing if it’s got anything to do with postprocessing effects/scalarparameters like @Rumzie was talking about? This crash report is the only clue I have so far :sob:

Ah, ■■■■, never mind.

Yes, take a look at that. Just remove the volume to start with, and if that sorts it, then try fiddling with the parameters…

Update, if anyone out there is having a similar issue; come to find out there’s a problem with some of my post processing volumes. The specific problem seems to be where they over lap. By deleting, or even just moving these volumes I am able to package a stable version of the game. I’ll look into it more in the near future but I guess for now I’ll mark this thread as resolved.