Alright, since the issue seems to be caused by different factors for each of us and we kinda loose track of the right answer in this horrible, small AnswerHUB layout, I will now try to update this Answer with the different solutions we find.
The Issue
To repeat the issue and not loose any information in all those answers.
The “issue” is a complete stall of the GameThread. Audio seems to keep running, but the game appears to be frozen.
When creating a dump file and debugging it in Visual Studio, all of us seem to see the same stall with “FEventWin::Wait”.
This is most likely happening when the “TG_EndPhysics” TickGroup is processed and then the previous “TG_DuringPhysics” TickGroup is cleaned up. The specific function being called for this is:
FTaskGraphInterface::Get().WaitUntilTasksComplete(TickCompletionEvents[Block], ENamedThreads::GameThread);
I haven’t heard from all of you yet if the exact same TickGroup is being process at this point.
Furthermore, this brings us to the idea that some event in the “TG_DuringPhysics” TickGroup is not completing and the GameThread stalls itself, as it waits on it and has nothing else to do.
When does this happen?
So this seems to be already different for some of us. Here are the different cases:
- Not inside the MainMenu. Only Packaged Game. Only when joining a DedicatedServer. Doesn’t need further interaction, just waiting until it freeze.
- Already inside of the MainMenu.
- ?
Possible Reasons
- Widgets
Widgets seem to be something Epic is targeting for this, however multiple factors speak against it.
One user removed all widgets and still had this happening.
I actually created an empty map, with a rotating block (to test if it freezes), which had all our UI (GameMode etc) in it, and it DIDN’T freeze. So our issue is inside of the map itself.
- Steam
Steam is probably completely out? Don’t know why it would cause this, so if you are running Steam: We couldn’t find a reason why Steam would cause this.
- libOPUS Library / DX11
While debugging the dump files with Windbg, we found that the last call stack is actualy listing some libOPUS functions, as well as DX11. Refreshing the library or playing in DX10 did NOT resolve the issue.
- TickGroup
A wrongly set TickGroup on a broken or non-broken object might cause this. It’s not clear if this is specific to Meshes (check Solutions) or can be caused by any kind of ticking object that has the TickGroup set by hand. It’s also not clear WHY this would cause the freeze.
Solutions
Now this list will be a bit shorter, as we are still investigating.
-
TickGroup was set on a child of SkeletalMeshComponent.
void UAvatarPart::BeginPlay()
{
Super::BeginPlay();
SetTickGroup(TG_PostUpdateWork);
}
Removing the SetTickGroup line seemed to have resolved the issue for the user.
- Particles
As we are currently testing, it seems like removing several particles from our map (which seems to be the cause of the freeze) seems to resolve it. We are yet to find out which particle causes this and then hopefully see WHY it causes it.
- Epic posted a POSSIBLE fix: [GitHub][1]
Make sure to be logged in into GitHub and have it connected to your Epic account, otherwise it will give you a 404 error. The fix hasn’t been tested by everyone yet, so it can be that it’s only a solution for one of us.
I’ll update the answer once this is more clear.
In addition, here is a link to the new [Bug Report][2]