Crash in shipping release since 4.18

Hello,

So I’ve got a massive problem and have no idea how to resolve it.

Since I’ve updated my project to 4.18, I get a “fatal error” every time I execute the release. It only does this when I choose the “Shipping” configuration for my release, and not in DebugGame or Development.

Here is what I tried :

  • removing Saved, Intermediate, Binaries and Config folders
  • removing all “Print String” nodes from my blueprints
  • removing all c++ classes
  • removing my game mode
  • disabling all plugins
  • Build on Shipping and cooker on debug : Crash
  • Build on Debug and cooker on shipping : works
  • Deleting every epic/unreal/project files that I could find in AppData
  • Rebuilding the project in VS in shipping/development editor
  • Verified engine version

but even with an empty map, no code and no gamemode, I get the crash on release.

I tried releasing on a new blank project, and it worked, so it definitely comes from my code, but I can’t isolate the problem.

Here is what gives me the UE4 Minidump :

0xC0000005 : the thread tried to read or write to a virtual address for which it does not have the appropriate access

I know this comes from the 4.18 update because I came back to a previous commit when my project was in 4.17, the release worked fine, then I tried updating to 4.18 and it crashed on execution.

I would really like to be able to use the new features for my project, like the Volumetric Lightmaps, there must be some thing in my blueprints that makes it crash, but I have no idea where to look. Any leads ?

Thanks in advance for your help,

Keep up the great work,

Marc.

Edit : I did rename the entire project recently (BEFORE updating to 4.18, and the release worked after renaming), and since 4.18 it created a newName.sln, so I removed the oldName.sln. Could it be related ?

Edit 2 : I just followed this tutorial to rename the project (should have done it before) but it didn’t change anything :frowning:

Edit 3 : So just to be sure if it was or not the renaming of the project, I came back to the original project (I didn’t exactly rename it, I cloned it and changed the name, so I still had the original one) which was in 4.17, I tried releasing, it launched fine, I updated to 4.18, it crashed. So… definitely not the renaming !

hi
have you tried with the 4.18.1 version ?
it fixed some crashing problems i had with the 4.18

Hello, thank you for your interest, but infortunately yes, I am already on 4.18.1.

Okay well, I finally solved it, and I still don’t know what caused it.

The solution was to create a new project (with the same name) and migrate everything, starting with c++ code, I had a lot of fixing and settings importing to do, but at least now the release works fine in shipping. No idea why, but well, as long as it is working, not gonna complain.

Hope it’s gonna help someone someday…

So I came across this exact issue earlier when updating my projects from 4.17 to 4.18.1. Everything works fine until I created a shipping package, which then fails “Fatal Error” with the same error message you received - “0xC0000005 : the thread tried to read or write to a virtual address for which it does not have the appropriate access”

When I debug the crash dump in VS2017, it leads me here, revealing the true error:

Sure enough, if I comment out all references to destructible meshes in code (in this particular project, there is only one destructible mesh in the Content dir and only one class using it), then the shipping build will successfully run and I can play as normal (albeit without destructible asteroids!).

However, uncommenting my code brings back the “Fatal Error” failure in shipping builds.

For whatever reason, creating destructible meshes in C++ no longer appears to work the same way as it did in 4.17. I mean, it works in editor, but not in packaged shipping builds. It appears to me as though this particular line of code:

static ConstructorHelpers::FObjectFinder<UDestructibleMesh> AsteroidMeshObject(TEXT("/Game/Environment/Meshes/Rocks/SM_Cave_Rock_Med_01a_DM.SM_Cave_Rock_Med_01a_DM"));

is failing to find the destructible mesh in the content browser (it exists there, trust me…), which causes an unhandled exception when I attempt to set the NULL mesh to the destructible component (line 44 in the screenshot).

I have tried to delete and re-create the destructible mesh asset from within the Editor, but this has not resolved the issue. Also unfortunate, the solution proposed by The Yojimbo (migrating the assets into a new project with the same name) did not work for me either - the Fatal Error in shipping builds persists, as long as I keep using destructible meshes in there.

I’ve had a similar crash due to some (haven’t found the exact culprit yet) Built-in plugin being disabled. Fixed the issue by removing all Enabled: False from the .uproject

■■■■ it works. I had tried disabling all plugins, did not thought to reenable them all. I’m gonna try to see which one is the cause. I mark your answer as the solution, it’s way easier this way !
Thank you very much, have a great day !

The only plugin that matters for this error is ApexDestruction (the only one that was heavily modified for 4.18…). Disabling that single plugin should avoid this error, however you obviously lose destructible assets.

See my previous reply in this thread for more information.

For me the culprits were TCP/UDP messaging. reenabling them fixed the project.
No idea why…

Sorry I did not reply to your previous reply, but I don’t use ApexDestruction. I’m sure it will be useful to other people though. The culprits in my case were, as rcortese said, the disabled plugins TCP/UPD messaging. Enabling them again made the trick. Thank you for taking the time, have a great day !

Yes, I confirm, I reenabled just these plugins and it fixed the crash. Thank you very much !

I solved an issue similar to this and hope this message helps someone in the future. I had crashes only in packaged builds (never editor) with the following log error:

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address ...

and

Warning: CreateProc failed: The system cannot find the file specified. 

Experienced devs told me 99% of the time it’s a null pointer error, meaning you are referencing something in your c++ or blueprints which can’t be referenced (usually because it doesn’t exist, for example it hasn’t yet been instantiated). This was true in my case.

The way to solve this issue:

  1. Look in your log folder. ([yourprojectname]>Saved>Crashes). Look for the FATAL ERROR near the end and look underneath that for the callstack hint which will steer you where your problem is. In my case, it looked like this:

    [2018.07.30-19.19.53:720][ 0]LogWindows: Error: Fatal error!
    [2018.07.30-19.19.53:720][ 0]LogWindows: Error:
    [2018.07.30-19.19.53:720][ 0]LogWindows: Error: Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0xfad70000
    [2018.07.30-19.19.53:720][ 0]LogWindows: Error:
    [2018.07.30-19.19.53:720][ 0]LogWindows: Error: [Callstack] 0x00007ff716532680
    AAADragonFresh.exe!AlgoImpl::IntroSortInternal<TBitArray,FIdentityFunctor,TDereferenceWrapper<TBitArray,TGreater<TBitArray > > >() []
    [2018.07.30-19.19.53:720][ 0]LogWindows: Error: [Callstack] 0x00007ff7165ca3b9 AAADragonFresh.exe!FSkeletalMeshLODRenderData::InitResources() []
    Notice the last message in mine. It contains the words “skeletalMesh”, “sort”, “TBitArray”. In my case, the null pointer was a reference to a skeletal mesh inside of a switch.

  2. Go into a blueprint you think the log could be referring to and disconnect the tick, begin play, and constructor wires, effectively deactivating the blueprint, and then package and run. If it stops crashing, you’ve found the blueprint with your toxic reference. You’re zeroing in!

  3. Reconnect your wires and disconnect only the part you think is responsible until the packaged build stops crashing. Find your bad reference, and then figure out why it’s a bad reference. Have you instantiated it yet? (You can put in printstrings, or you can put in breakpoints and step through your blueprints to find out). In my case, it was something stranger which really threw me off: I had imported the mesh from Blender with the skeleton turned to invisible. This was enough to throw off ue4, but only when ue4 was trying to load it (hence why only the crashes in packaged builds).

The first time debugging something like this is hell, but have faith that you can and will get through it, and once you do, you’ll have tremendous confidence moving forward!