EXCEPTION_ACCESS_VIOLATION reading address Error when playing in Editor or Standalone

So anytime that I try to run the game in the editor (using Unreal Engine 5.3.2), it crashes on me. I think I know what the problem is, but I’m unsure as how to fix it.

In short, I was doing some basic Viewport editing to my main playable character. As seen below, this is how I originally had my player set up:

image

This ran fine as usual. After deciding to try to rearrange the heirarchy to test some camera movement, this is what I was left with, just moving the FirstPersonCamera so the MultiplayerMesh would be the parent of it:

image

I made FirstPersonCamera transform adjustments, like changing it’s location and rotation values since I set the FirstPersonCamera to be in a parent socket of the MultiplayerMesh. This also ran fine inside of the editor.

However, I decided to revert the changes and undid everything by just doing Ctrl-Z quite a few times, which brings me back to the first image. Once I saved and compiled, it brings us to the problem at hand currently, where there is a problem of when I press Play, it freezes for one second then Unreal Engine crashes.

Another map of mine, a basic Main Menu screen with functionality, works as intended and can play, so I do believe it’s something going wrong inside of my playable character inside of my main playable map. I’ve also tested to see if it can run in standalone, but it also crashes, as it shows my playable character barely spawning in before crashing.

Below is the general crash report as well as the crash log. I’ve combed through it but can’t really make much sense of it:

Crash Report:

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0x00000000000002d0

UnrealEditor_Engine
UnrealEditor_Engine
UnrealEditor_Engine
UnrealEditor_Engine
UnrealEditor_Engine
UnrealEditor_Engine
UnrealEditor_Core
UnrealEditor_Core
UnrealEditor_Core
UnrealEditor_Engine
UnrealEditor_Engine
UnrealEditor_Engine
UnrealEditor_Engine
UnrealEditor_UnrealEd
UnrealEditor_UnrealEd
UnrealEditor
UnrealEditor
UnrealEditor
UnrealEditor
UnrealEditor
UnrealEditor
kernel32
ntdll

Crash Log:
BodyCamMazeHorror.log (221.2 KB)

Any help with this would be phenomenal because I can no longer work on my game until this is somehow fixed, and it’s been driving me insane.

the callstack is not really helpful without the Debug symbols (we know that it was a crash in one of the 100 some UnrealEditor_Engine module cpp files (:person_shrugging: thanks…), but you probably didn’t modify that file and we are “supposed to trust” those.
for this to be useful it would require the Debug symbols (if you installed the Editor/Engine from the Epic Game Launcher then in the drop down for the given Engine install->Options-> “Editor Symbols for Debugging”
for best usefulness this might also require installing and setting up the integration for an IDE like Visual Studio for PC (the Community version is free, and works fine be sure to get it directly from Microsoft)

it might be that some of your reroute nodes (the little dots you can drop in the middle of wires to make them prettier or have multiple outputs) for something (not necessarily your FirstPersonCamera) might have pointer/reference data from a now invalid configuration; because the SetupAttachment() (this is called in the secret Constructor for your blueprint) that is called for each Parenting action of the hierarchy is working with pointers for the object any one of which could be incorrectly assigned. For example the FPSArmsMesh might now be incorrectly assigned in that constructor or something like that.

  • try first to just save, close the Editor and launch the stand alone again (sometimes the Editor might do a “hey wait a minute”) this is actually a long shot but can “magically work”
  • you may need to go through your blueprint and just redo you reroute nodes at the very least. I would suggest taking a screenshot so that everything gets reconnected as it was, and remember you can hover over a pin or wire to have the connection be highlighted)

Saving makes sure the current state of the thing will be in that state when you next open the editor; it has no real impact on how the application behaves.

Blueprint compiling only really makes sure that a few logical flow issues don’t happen (like infinite loops) and that types for each pin matches up. Because the Engine is built on C++ where it is “relatively easy” to re-assign a pointer to be almost anything valid or otherwise, or even passing in a Null-Pointer to something that expects a non-Null-Pointer (the safeguards of the Engine try to help, but don’t always) the Blueprint compiler has no way of knowing what if anything is incorrect with regards to whether a pointer is, or will be valid at the moment it is executed

This is why doing isValid() checks is important at least for things external to the specific object/class/blueprint, but sometimes for things that are internal and just might not be there.

kind of a side note: you don’t actually have to save your blueprint to try stuff out, as long as it compiles it will run (or try to…).
keep in mind that if the Editor crashes you will probably lose those changes (they can be recovered with the temporary files created by the Editor but this shouldn’t be relied on)

so if you are just trying something out you you are unsure of you could:
-Save the current “trusted working” state
-make the change in the blueprint, Compile, and if it succeeds try it out
-if you like it then Save the blueprint
-if you don’t like it, close the Editor, and re-open it (re-opening a project that was just closed can be a lot faster then the initial opening)

this is a lot more reliable then using Undo which has limitations based on queue size, and you might go too-far or not-far-enough.