Hello,
We are currently in the process of migrating our project from Unreal Engine 5.5.4 to 5.6.0. The project is relatively large and branchy.
We have:
- Addressed all deprecated APIs,
- Removed unsupported plugins,
- Updated all compatible plugins to their 5.6.0 versions,
- Successfully built the project.
However, we’re encountering a crash during project startup. The Editor fails to fully open the project and throws the following assertion errors:
`Assertion failed: !Object->HasAnyFlags(RF_NeedLoad | RF_NeedInitialization)
[File:D:\build++UE5\Sync\Engine\Source\Runtime\CoreUObject\Private\Serialization\AsyncLoading2.cpp] [Line: 10517]
Object=‘BP_CombatFunctionLibrary_C /Game/Avatars/Shared/CombatSystem/Blueprints/BP_CombatFunctionLibrary.Default__BP_CombatFunctionLibrary_C’
Flags=Public | ClassDefaultObject | ArchetypeObject | NeedLoad | WasLoaded, InternalFlags=0x04504000
Assertion failed: !Object->HasAnyFlags(RF_NeedLoad | RF_NeedInitialization)
Assertion failed: !Object->HasAnyFlags(RF_NeedLoad | RF_NeedInitialization)
[File:D:\build++UE5\Sync\Engine\Source\Runtime\CoreUObject\Private\Serialization\AsyncLoading2.cpp] [Line: 10517]
Object=‘BP_GameplayController_C /Game/zSpaceContent/Game/Blueprints/PlayerControllers/GameplayController/BP_GameplayController.Default__BP_GameplayController_C’
Flags=Public | ClassDefaultObject | ArchetypeObject | NeedLoad | WasLoaded, InternalFlags=0x04504000`Additionally, we found that removing three DataAssets (out of 22) listed under Project Settings → Asset Manager → Primary Asset Types to Scan prevents the crash from occurring. This seems to point toward a possible issue with asset loading or initialization during the early startup phase.
We’ve tried the following steps, without success:
- Re-saving the affected assets and their dependencies,
- Running “Validate Assets” and “Validate Assets and Dependencies”,
- Refreshing blueprint nodes in the critical assets,
- Deleting intermediate and derived data folders, followed by regenerating project files.
At this point, we are unsure what is causing these Class Default Objects to retain or flags during loading. It’s possible this relates to internal loading order changes or stricter validation in 5.6.
Could you please advise on what might be causing this and how we might proceed with diagnosing and resolving the issue?
Thank you for your support.
Best regards,
Harut
Hi there,
Would you be able to provide the callstacks for these assertions? This might tell us more information about where these loads are coming from.
Also, if you haven’t already, I would recommend clearing your Saved directory, as this directory can include references to assets (particularly in EditorPerProjectUserSettings.ini) that could be causing issues.
Regards,
Lance Chaney
Hi Lance,
We’ve already tried removing all generated content, including the entire Saved directory, prior to running the project with UE 5.6, but unfortunately, the issue still persists.
As requested, please find attached the following:
- The generated Saved directory
- The .dmp (crash dump) file (Please find the dump file link here. )
- The stack log / callstack
Please let us know if any additional information is needed.
Thanks,
Harut
Thanks for providing the callstack and the crash dump. This is quite a tricky issue to debug. It seems like there might be several things working together to create this crash. Unfortunately I haven’t been able to create a replication of this crash, so I’m doing a bit of an info dump below in hopes that it will be able to assist you in debugging the issue.
The first sanity check I would do is see if you have somehow set bDeferDependencyLoads to false in your DefaultEngine.ini under <ProjectDir>/Config. I notice your callstack includes a code path in FindImportObject that is somewhat difficult to trigger. Having bDeferDependencyLoads=false makes this code path more likely to be hit, as it skips the previous fallback. There seem to be a couple of ways I have found to hit this code path (with bDeferDependencyLoads=false). One is a circular dependency load on a primary asset, the other is if the file the engine is looking for no longer exists (or has been renamed, presumably without proper redirectors).
From looking through your crash dump, it seems like the main part of your issue is coming from a nested call to flush async loading. Which in turn seems to be coming from the engine trying to load: /Game/Avatars/Shared/CombatSystem/Blueprints/BP_Projectile. The screenshot below is from your crash dump. The code path it is going through here is the final fallback for not being able to find this package through any other search methods. As I mentioned above, this path seems to get hit either on a missing package, or when there is a circular reference back to the primary asset that triggered the first flush async loading call. When this code path gets hit, it tries to load the object using StaticLoadObject, which will flush async loading. I’m guessing the final cause is some kind of loading dependency issue that triggers after this point, during the nested flush async loading call. I note that both BP_GameplayController and BP_CombatFunctionLibrary are on this preload chain, before the second flush async loading call is triggered. Which is probably why you’re getting a crash when async loading encounters these assets again, while they are already partway through loading.
[Image Removed]I think checking the BP_Projectile asset is your second point of call for debugging this, as it appears like it could be missing, or the editor is for some reason unable to locate it. Maybe this asset was moved in your previous engine version and had redirectors setup, but they have been lost during the update process. You could also try setting this asset reference to be a soft class ptr in Content/Avatars/Shared/CombatSystem/Data/Structs/ST_ActorImpactSound. Which appears to be where it is referenced from (see screenshot below). This will hopefully prevent it from trying to load the asset and triggering the second flush async loading call.
[Image Removed]Please let me know if any of this was helpful and if you need further assistance
Regards,
Lance Chaney
[mention removed]
Thank you very much for helping us figure out the issue.
You were absolutely right — the problematic asset was BP_Projectile. Re-referencing the asset, as you suggested, resolved the issue.
Thanks again for your valuable insights!