As the title says, Unreal has been acting up, freezing for no apparent reason for the past… 6 months or so, I guess. Sometimes (as has been with the unstable UE 4.20 source) it will freeze as soon as it opens up, others it will wait until the mouse hovers the window and yet others it will work for hours on end until I focus some other window and try to come back to the editor a bit later.
At some point, someone from Epic did reach out to me in Answer Hub, but unfortunately I haven’t been able to find a way to reproduce the issue, so I couldn’t properly report this as a bug.
I tried both executable and source code versions of the engine in 3 different machines, but all had this same result.
Their specs are:
Win 10 Pro, 32GB DDR3 RAM, GTX 980 and Core i7 3700K
Win 10 Pro, 24GB DDR3 RAM, GTX 970 and Core i7 2700K
Win 10 Home, 16GB DDR4 RAM, GTX 870M and Core i7 4700HQ (an MSI laptop here)
So other than all using Windows, they have pretty much nothing in common, yet all presented the same problem.
There are no crash messages or anything, the editor simply freezes and stays like that until I kill the process.
Stepping through the source code, what I managed to gather is that the engine is usually forever stuck in a loop waiting for an event.
Here’s the relevant bit of code from RenderingThread.cpp
do
{
CheckRenderingThreadHealth();
if (bEmptyGameThreadTasks)
{
// process gamethread tasks if there are any
FTaskGraphInterface::Get().ProcessThreadUntilIdle(ENamedThreads::GameThread);
}
bDone = Event->Wait(WaitTime); //<----- This ends up NEVER being false
bool IsGpuAlive = true;
const bool bOverdue = FPlatformTime::Seconds() >= EndTime && FThreadHeartBeat::Get().IsBeating();
if (bOverdue)
{
if (GDynamicRHI)
{
IsGpuAlive = GDynamicRHI->CheckGpuHeartbeat();
}
}
if (!IsGpuAlive)
{
UE_LOG(LogRendererCore, Fatal, TEXT("GPU has hung or crashed!"));
}
// track whether the thread ensured, if so don't do timeout checks
bRenderThreadEnsured |= FDebug::IsEnsuring();
}
while (!bDone);
That “Wait” call goes into WindowsPlaftformProcess.cpp" which in turn is always returning false.
Or trying to handle a Crash Event (WindowsPlaftformCrashContext.cpp)
/** Main loop that waits for a crash to trigger the report generation */
FORCENOINLINE uint32 Run()
{
while (StopTaskCounter.GetValue() == 0)
{
if (WaitForSingleObject(CrashEvent, 500) == WAIT_OBJECT_0)
{
ResetEvent(CrashHandledEvent);
HandleCrashInternal();
ResetEvent(CrashEvent);
// Let the thread that crashed know we're done.
SetEvent(CrashHandledEvent);
break;
}
}
return 0;
}
To me, this means something is wrong in the Windows API side of things, but I currently lack knowledge to dive in any further. The fact that I don’t see complains everywhere about this also tells me that it is not a widespread issue, but rather has something to do with my project or the way my machines are setup, somehow.
Truly, I am at a loss… any thoughts?
=-=-=-=-=-=EDIT=-=-=-=-=-=-=
I have downloaded 4.19 from the Launcher in order to test it again (previously had only tested through a source build).
After a couple hours using it, I have yet to face this problem in particular (though there was already one crash, but I hadn’t installed the debug symbols so there was no way to look further into it…).
I’ll try downloading the source for 4.19 (since it’s stable now) and see whether the problem starts happening again. Should that be the case, it may have something to do with running the engine from Visual Studio.
=-=-=-=-=-=EDIT 2=-=-=-=-=-=
I haven’t had the time to actually test 4.19 from source yet and judging by the silence here, it seems this is may be even harder to fix than I initially thought
Still, I have been using 4.19 from the Epic Launcher, as I said, and I noticed something that may be relevant here.
From time to time, seemingly at random, when I switch from one BP tab to another, the editor will crash with the following log (which I already submitted to Epic)
Access violation - code c0000005 (first/second chance not available)
UE4Editor_SlateCore!SWindow::InitialMaximize() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\slatecore\private\widgets\swindow.cpp:1360]
UE4Editor_SlateCore!SWindow::ShowWindow() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\slatecore\private\widgets\swindow.cpp:1291]
UE4Editor_Slate!FDockingDragOperation::OnTabWellLeft() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\slate\private\framework\docking\fdockingdragoperation.cpp:88]
UE4Editor_Slate!SDockingTabWell::OnDragLeave() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\slate\private\framework\docking\sdockingtabwell.cpp:349]
UE4Editor_Slate!FSlateApplication::RoutePointerMoveEvent() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\slate\private\framework\application\slateapplication.cpp:5648]
UE4Editor_Slate!FSlateApplication::ProcessMouseMoveEvent() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\slate\private\framework\application\slateapplication.cpp:6142]
UE4Editor_Slate!FSlateApplication::OnMouseMove() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\slate\private\framework\application\slateapplication.cpp:6076]
UE4Editor_ApplicationCore!FWindowsApplication::ProcessDeferredMessage() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\applicationcore\private\windows\windowsapplication.cpp:1764]
UE4Editor_ApplicationCore!FWindowsApplication::DeferMessage() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\applicationcore\private\windows\windowsapplication.cpp:2172]
UE4Editor_ApplicationCore!FWindowsApplication::ProcessMessage() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\applicationcore\private\windows\windowsapplication.cpp:889]
UE4Editor_ApplicationCore!FWindowsApplication::AppWndProc() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\applicationcore\private\windows\windowsapplication.cpp:726]
user32
user32
UE4Editor_ApplicationCore!FWindowsPlatformApplicationMisc::PumpMessages() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\applicationcore\private\windows\windowsplatformapplicationmisc.cpp:129]
UE4Editor!FEngineLoop::Tick() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\launch\private\launchengineloop.cpp:3263]
UE4Editor!GuardedMain() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\launch\private\launch.cpp:166]
UE4Editor!GuardedMainWrapper() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\launch\private\windows\launchwindows.cpp:134]
UE4Editor!WinMain() [d:\build\++ue4+release-4.19+compile\sync\engine\source\runtime\launch\private\windows\launchwindows.cpp:210]
UE4Editor!__scrt_common_main_seh() [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253]
kernel32
ntdll
Once such crash happens, I am unable to use Unreal until I restart my PC because guess what? It freezes! It opens up and I can navigate around my map, but as soon as I hover anything in the Content Browser, it stops working and I have to end the process manually.
Unfortunately, I don’t know how to reproduce the crash, but once it happens, all I have to do in order for the editor to freeze is hover pretty much anything outside the viewport. Attaching Visual Studio to the Editor and stepping through its execution, it appears the problem is indeed with the RenderingThread.cpp forever waiting for an event from WindowsPlatformProcess.cpp.
That doesn’t tell me much, but if anyone can enlighten me, I’d really appreciate it.
I’ll keep updating here with anything new I find.