Well I post this in 4.14 but it happends to me in 4.13 aswell, I turn on Generate MEsh Distance Fields, hit the “restart” button wait to 45% and it crashes. I even made a new clean 3rd person and first person project and all I did was turning on Distance Fields and in both cases the same things happends, crash at 45%.
I’ve google and tried all answers I could find, despite them beeing very very few.
I am on Win10, Nvidia 1080GTX
Here is the log file and ID’s
MachineId:C494CA214865D8ED6FBFE9989EE0138C
EpicAccountId:fdb55adf62914aba8bbde6a078147601
Hello Magnus,
I was not able to get the crash to occur on my end when testing on a Windows 10 machine using a different graphics card. I will further test to see if I can get my hands on a Nvidia GTX1080, but in the meantime can you provide me with your ‘dxdiag’ so I can take a look at your system specifications?
Let me know if you have further questions or need additional assistance.
Thank you,
Here is my dxdiag, I have tested so manny different things, now different unreal builds, different projects, always the same result.
link text
So, from the sounds of it you are getting a universal crash on multiple engine versions and different projects. Do you recall when this started occurring?
We just ran a test using a similar set up as yours, and was not able to get the crash to occur. The interesting thing about your crash is that the callstack is only three lines (very odd), and your description mentions something about pushing memory to a pool. Increase NUM_ELEMENTS_IN_POOL.
The only thing I have been able to locate in regards to this context is a crash dealing with Android back on 4.11. Are you developing for any mobile platforms?
Do you have any other information that might help us figure out what could be occurring?
Thanks,
Not developing for Android. Just PC.
Well it never did work here, on this machine, and if I remember correctly it didnt work on my old machine, and this win10 ssd was just brought over from the old machine so…perhaps it never work on either…perhaps it is something with the win10 install…
Random info, that I come to think about when you ask that:
This is a dualboot system, 2x1TB SSD’s 1 for linux mint and 1 for win10.
My GFX card is in the 2nd PCI-E slot not the first since the CPU FAN’s where in the way, this seemed to cause an issue on linux where I had to use “nomodeset” at startup or gfx interface in linux wouldnt show up.
I got 32cores/64 threads, just at windows grouping limit, not sure if that matters but perhaps it does ? (I have run into gaming software like substance designer having issues with large amount of CPU’s have before).
My RAM is all ECC ram shouldnt matter and theoretically just do things better but hey ?
Speaking of RAM I got 64GB but just 32GB / CPU since this is a dual cpu system, and I am not using all 16 DIMM Slots either, just half of them, but still means I use all the ram channels. left it open for future upgrade to more.
EDIT: forgot to mention this windows have been upgraded from 8.1 to 10, to win10 aniversary, to win10 pro… but well everything else is working fine 
Wow, you have quite the frankenstein machine there. There is a lot of potential for error here, especially your graphics card setup. Also, your CPU’s are quite excessive so as you mentioned that could also be a potential problem.
The fact it has not worked ever makes it even harder to determine what is causing the issue. You have a pretty seriously powerful machine, and it probably isn’t the limitation of hardware, but just how you have your PC set up.
I would honestly start by trying on a simpler machine and eliminate some of your variables. Firstly, the hard drive that it never worked on.
Thank you,
So the answer is, re-install our software on a different machine with a different windows 10 install and then it hopefully works ?
Im sorry I am not made of money
That is not what I was implying, so apologies if that was unclear. I would just like you to test on a similar machine if applicable. My suggestion was to eliminate all the variables you know are going to cause it to work incorrectly…i.e. your hard drive you transferred over where you have prior knowledge of the engine not working on it.
Your processor is like nothing I have really ever seen in a normal spec gaming/development machine. Honestly the amount of cores you are working with is more than we have on our machines, or any machine we have available to test. I am trying to eliminate any of your outstanding variables so we can figure out your crash.
Let me know if you have further questions.
Thanks,
Unfortunatley it is not applicable, I only have one of these machine’s. I put this togeather as my main Workstation for Both Unreal and things such as Houdini/SideFX simulation/rendering thus the high amount of cores.
Is there no way you can give me a possibility to generate a better crash log or something ?
The crash log is going to generate what it wants based on the steps you are following. There is nothing I can force or do to get a more verbose log from you. That would be on your side of things.
Unless we can reproduce this crash on our end, we cannot really report the crash. If we were to report the crash, our engineers would need a way to reproduce the issue so they can determine how/where it is failing. Your callstack is only three lines, and the context of the description is incredibly vague.
Unfortunately, we don’t have a machine similar to your to test so there isn’t much we can do with this crash. Have you attempted any of the suggestions I have proposed?
Can you work in the editor without using the generate mesh distance fields checkbox?
Thank you,
Well I did re-install 4.13.2 and now it actually doesnt crash at 45% anymore but at around 90-95% so something feels different.
This is from Crash Reporter:
MachineId:C494CA214865D8ED6FBFE9989EE0138C
EpicAccountId:fdb55adf62914aba8bbde6a078147601
Assertion failed: Result && "Increase NUM_ELEMENTS_IN_POOL" [File:D:\Build\++UE4+Release-4.13+Compile\Sync\Engine\Source\Runtime\Core\Private\Stats\Stats2.cpp] [Line: 1000]
UE4Editor_Core!FDebug::AssertFailed() [d:\build\++ue4+release-4.13+compile\sync\engine\source\runtime\core\private\misc\outputdevice.cpp:421]
UE4Editor_Core!FThreadStatsPool::GetFromPool() [d:\build\++ue4+release-4.13+compile\sync\engine\source\runtime\core\private\stats\stats2.cpp:1001]
UE4Editor_Core!FQueuedThread::Run() [d:\build\++ue4+release-4.13+compile\sync\engine\source\runtime\core\private\hal\threadingbase.cpp:424]
UE4Editor_Core!FRunnableThreadWin::Run() [d:\build\++ue4+release-4.13+compile\sync\engine\source\runtime\core\private\windows\windowsrunnablethread.cpp:74]Unfortunately, this is the exact same callstack and description that we had previously. The fact you are getting the crash at a different percentage location is interesting, but not really all that helpful.
Looking further into the crash, this is only affecting two people in the wild which means it is not a common or widespread issue. There is something with your setup that is causing this crash, which will be very difficult for us to reproduce in order to get a bug entered and fixed.
If we cannot get your crash to occur in a new blank project using the steps you provided, then there is not much we can report or fix as the issue more than likely lies on your end.
Thank you,
I downloaded and compiled 4.13.2 on my linux in the dualboot setup. It compiles fine and starts no problem, but then I activate the Distance Fields and restart and crash again just like on windows. I zipped up all the crash files and attached them here. Personally I would have atleast shown this to a engineer to hear their thought about it instead of just denying it engineer time but well thats just me.
[link text][1]
[1]: 113426-linux_crash.zip (10.4 KB)
also it would be interesting if the other person has his GFX card in the 2nd PCI-E slot.
EDIT: Also if that other person has a great number of cores like I do.
any feedback on my linux efforts ? or are we done ?
I have gone ahead and entered a bug report for this issue. I tried to add as much helpful information to the internal comments and the bug report so that our engineers can try to figure out what is occurring, but without us being able to reproduce the crash internally it might not get much traction. Either way, we tried.
To track this issue follow the link below.
Let me know if you have further questions or need additonal assistance.
Thank you,
Thank you for posting it, the 3 cpps from the call’s stack certainly seems to indicate that is has something to do with threading, and since I have 64 threads/cores it might be worth mentioning in the bug shrug
Yeah, I kept all the real comments and things that the rest of the public might not need to see private. I made sure to add the fact that it might have something to do with the threading and amount of cores.
Ah ok, was a bit stumped since it looked so small like no one is gonna take that serious. But feels better now. thanks =)