Same here!
You have a similar bug in Fortnite
1 Like
Someone else with FAsyncLoadingThread crash when trying to load staged or packed build? Getting no errors when cooking and playing works in editor, but when game tries to load it Fatal Crashes. In Unreal Insight FLinkerLoad::Preload fails to load certain blueprints (shows infinite symbol). When removing those there is always new BP with same never ending load before crash issue. Maybe related to actor components, but cant find clear cause. Had no issues with earlier UE5 versions.
Tried to toggle async loading thread off and generate optimized blueprint component data but no help. How to turn the async loading off. E.g. for wanted blueprints. Very odd issue. :S
3 Likes
@Amanda.Schade Can we get a Hotfix to correct the Fatal Crashes???
I figured I’d put this here as I’m not seeing any specific release notes that make note of it or mention the loss of lumen in 5.5 dx11.
5.5 no longer supports lumen in DX11 with SM5 which is a huge loss in my honest opinion because it was by far the most performant GI supported pipeline with traditional LODs vs nanite and a lighter weight shader cost and shadow casting (CSM). In order to have Lumen GI (as of 5.5 release) now you have to enable SM6 and DX12.
UE5.5 DX11 (No longer working)
UE5.5 DX12 SM6 CSM instead of VSM
20+ frames lost just for GI
Update:
After some digging it appears the 5.5 docs still mention DX11 and SM5 however in the feedback thread below an epic staff member said it was deprecated?
Lumen GI and Reflections feedback thread - Development / Rendering - Epic Developer Community Forums
I do a much better job of breaking out DX11, SM5 and DX12 across each shader model in the below forum post. This is a huge loss in my opinion and directly impacts many studio and orgs business models.
Lumen no longer working in UE5.5 DX11 SM5 - Development / Rendering - Epic Developer Community Forums
5 Likes
Same a ton of us are having this issue
5 Likes
Looks great, but none of my assets seem to be upgraded to work in the new version. Any ideas on what to do? Thanks! Len
Has the possibility of integrating RenderTarget2D as an input into the DeformerGraph been considered?
If that’s not possible, could an interface be provided in Niagara to notify DeformerGraph? This would allow the GPU to be used for creating interesting physical properties.
It seems that the official groom system has implemented some of these features, but it could be more customizable. Perhaps this is not a simple task?
Disabling all the interchange plugins worked. Skeletal meshes now import correctly again. Thanks.
Wanted to mention that it appears pak chunking and asset label behavior has stopped working correctly in ue5.5 release. Was working in 5.4 without issue. Wanted to give everyone here the heads up.
I hunted this down and posted findings in UE Source discord. There appears to be something going on with TMaps and GC dealing with index counting and changes. This appears to lead to recursion for things that lean on them “Like Ultra dynamic Sky” which uses maps for the weather component. After talking with my community and doing reproductions of each report the first common factor was alot of these people used UDS. The second was alot of them used some other plugin or module consisting of Tmaps. SImpleUGC and pack chunking with asset labels and parent label behavior has also been impacted.
[2024.11.17-04.25.42:694][ 0]LogConfig: VeryVerbose: (ActorComponent) 'Default__Random_Weather_Variation_C' loading configuration from Engine
[2024.11.17-04.25.42:694][ 0]LogConfig: VeryVerbose: Loading value for bReplicateUsingRegisteredSubObjectList from [/Script/Engine.ActorComponent]
[2024.11.17-04.25.42:694][ 0]LogConfig: VeryVerbose: Loading value for bCanEverAffectNavigation from [/Script/Engine.ActorComponent]
[2024.11.17-04.25.42:694][ 0]LogConfig: VeryVerbose: (Random_Weather_Variation_C) 'Default__Random_Weather_Variation_C' loading configuration from Engine
[2024.11.17-04.25.42:694][ 0]LogConfig: VeryVerbose: Loading value for bReplicateUsingRegisteredSubObjectList from [/Game/UltraDynamicSky/Blueprints/Weather_Effects/System/Random_Weather_Variation.Random_Weather_Variation_C]
[2024.11.17-04.25.42:695][ 0]LogConfig: VeryVerbose: Loading value for bCanEverAffectNavigation from [/Game/UltraDynamicSky/Blueprints/Weather_Effects/System/Random_Weather_Variation.Random_Weather_Variation_C]
Exception thrown at 0x00007FF6C6CD0BF6 in STVisualizer-Win64-DebugGame.exe: 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, 0x0000007507E83F28).
Unhandled exception at 0x00007FF6C6CD0BF6 in STVisualizer-Win64-DebugGame.exe: 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, 0x0000007507E83F28).
UE5.5 is also ALOT more sensitive to circular dependencies it seems as someone above has mentioned that specific functions of the engine are much slower … only utilizing 2/3 cores in some cases like HLOD building. Let’s hope these get addressed in a hotfix.
1 Like
That Random_Weather_Variation_C also was one of the BPs triggering FAsyncLoadingThread crash / FLinkerLoad::Preload failing to load. Circular dependencies sound like causing the crash, but would be bit overkill to add interfaces for everything.
1 Like
This is very true. There has been a bit of digging since this post and we landed here
The current thought is maybe this isn’t working as intended in 5.5 since 5.4 presented with no issues.
They have changed row 678 in linkerload.cpp. It was
if(OldObjectLinker->GetSerializeContext())
{
OldObjectLinker->GetSerializeContext()->PRIVATE_PatchNewObjectIntoExport(OldObject, NewObject);
}
Now
FUObjectThreadContext::Get().GetSerializeContext()->PRIVATE_PatchNewObjectIntoExport(OldObject, NewObject);
Also in FLinkerLoad::Preload the “Toggle support for IDOs” (around row 4640) was
// Toggle support for IDOs
FUObjectSerializeContext* LoadContext = FUObjectThreadContext::Get().GetSerializeContext();
// Enable property path tracking when IDO support is enabled. Both property bags and IDO creation require the paths.
const bool bHasIDOSupport = UE::IsInstanceDataObjectSupportEnabled(Object);
TGuardValue<bool> ScopedTrackSerializedPropertyPath(LoadContext->bTrackSerializedPropertyPath, bHasIDOSupport);
// Enable creation of a property bag to hold any property that does not match the current class schema,
// except when impersonation is enabled because that implies we are deserializing an IDO.
const bool bCreateIDO = bHasIDOSupport && !LoadContext->bImpersonateProperties;
TGuardValue<bool> ScopedSerializeUnknownProperty(LoadContext->bSerializeUnknownProperty, bCreateIDO);
In UE5.5 now:
UE::FScopedIDOSerializationContext IDOLoadContext(Object, *this);
This been removed in row 4773
// Object has been deserialized, if IDO is enabled, generate it
if (bCreateIDO)
{
UE::FPropertyBagRepository::Get().CreateInstanceDataObject(Object);
}
As soon as you turn on Hardware Raytracing to turn on MegaLights and do a Windows Shipping Build you get this : LowLevelFatalError [File:D:\build++UE5\Sync\Engine\Source\Runtime\D3D12RHI\Private\D3D12Util.cpp] [Line: 991]
RayTracingDevice->CreateStateObject(&Desc, IID_PPV_ARGS(Result.GetInitReference())) failed
at D:\build++UE5\Sync\Engine\Source\Runtime\D3D12RHI\Private\D3D12RayTracing.cpp:663
with error E_INVALIDARG
0x00007ff71f4ef477 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71f49a895 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71f49c690 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71f49d4e8 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71da50ff1 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71dbed682 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71da5223b BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71f48e0a1 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71f4a4a13 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71f5bf494 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71f5c1920 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71da50ff1 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71da3d7bf BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71da402ee BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71da52c23 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71da3a191 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71dac7db4 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71dc08117 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ff71dc07ee9 BRAVE-Win64-Shipping.exe!UnknownFunction
0x00007ffcd3337374 KERNEL32.DLL!UnknownFunction
Crash in runnable thread Background Worker #2
Having interface event and one bp with same infintely preload so most likely the interfaces will not fix the crash.
BTTAsk_RandomMoveLoc_C have no references except behaviour trees. All data using interfaces. And that last AIDrive_IF_SetWingMan is interface event passing actorref.
1 Like
Found one more error from one preload it dosent fail but give non crashing error. BlueprintGeneratedClass.cpp _ line 759
// This feature requires EDL at cook time, so ensure that the source template is also fully loaded at this point.
// Also ensure that the source template is not a class default object; it must always be a unique archetype object.
if (SourceTemplate != nullptr
&& ensure(!SourceTemplate->HasAnyFlags(RF_NeedLoad))
&& ensure(!SourceTemplate->HasAnyFlags(RF_ClassDefaultObject)))
Seems like SourceTemplate could be nullptr but the condition also do the ensure check. Should it be inside separate if?
Building source now and I can toss it in and check. TY very much for digging in here with me 
Have you narrowed this down any further? I attached symbols and I’m stepping through but I simply cannot see the cause just yet.