[SOLVED] Easy way to debug <Fatal-Error> editor crashes at startup (after creating new FPS Project)?

Its rare you see a ‘Fatal Error’ dialog at startup with no other useful info. It can happen if you run out of disk space and auto-save kicks in etc. I’m seeing another scenario where the Editor is crashing after creating a new FPS project. It doesn’t happen with any other project type. The crash occurs just before the editor window should pop up (95% / 96% loading point). Anyone have ideas or know which logs to check? Its affecting airgapped PC’s using 4.18 binary build (no debug-symbols installed).


Install debug symbols and launch c++ project running in editor mode from Visual Studio, that will launch the UEditor with debugger attached and point to where it is crashing.

Narrowed the crash down… Its happening just prior to the Map-Check completing and seems to be tied to **static lighting, **and on some level
compiling shaders (aborts at the same point everytime during LogTexture: Display: Building Textures).

I generally only use Dynamic Lighting. But as the FPS template has static lighting, I disabled the BuiltAsset.uasset for the FirstPersonExampleMap - and now finally SUCCESS!!! The new FPS template project loads up in the Editor… That gave me the idea to try Building Lighting on a new TPS template project instead, AND that is crashing (even if the TPS template map itself loads up in the editor just fine).

So what’s going on… Anyone seen this before? - BTW: Testing on a second rig shows no issues with either the engine install or the project. There’s no obvious ‘D3D device lost errors’ or anything in the logs either… (Using an RTX-2070 rig and UE4.18).


You’d have provided callstack (information from Crash Reporter, also included at the of Log file in case of crash), so anybody could help you in any way.
You need to download debug symbols for that, as mentioned above. There’s a chance someone would guess the reason for your crash.

Can’t guarantee that… Often the best would be to catch a crash in Visual Studio and inspect data. You would even get asset causing crash.
Otherwise, maybe the best solution for you would be just removing part of assets from the crashing map, repeat it until you’d isolate which asset is crashing.


Can you infer anything at all from the screengrab above dude? The crash occurs after attempting to Build Lighting on a new ThirdPerson template. BTW: The rigs are airgapped (offline machines)… So its not going to be that simple to install symbols and find a full standalone version of VS…

Solved: Missed one dependency: Nvidia-Texture-Tools - nvtt_64.dll - msvcr120.dll…

how did you find that problem ? how one can get a callstack or anything besides “Fatal error” message for that matter ?

If you’ve ruled out the obvious like project corruption (always start with basic templates whenever you get a crash), Then you’ve basically got 3 options to fix a problem like this:

  1. Run engine prerequisites to make sure the base UE DLL support is there. This is the easiest low-tech fix for many problems (especially new rigs). However, it does depend on how much you trust Microsoft. Parts of Win10 telelmetry is illegal in Europe and other Microsoft products are actually banned. Basically ever since Microsoft deliberately used malware-like dirty tactics to dupe people into upgrading to Win10, they’ve completely lost credibility. Sneaking in even more telemetry doesn’t help!

  2. Follow the advice above from Bruno / Moth Doctor. Install UE Debug Symbols and Visual Studio and connect to a live running instance of UE and step through the code, until you track down where the crash happens. This has its own advantages / disadvantages. First it assumes you have a fast net connection and you’ll be able to properly install Vis Studio which may have its own dependency issues (related or not related to the above crash). Separately if you’re at a client site, the local techs there may balk at the idea of you installing anything, in which case good luck with that.

  3. Use old-school Microsoft utilities / diagnostics to help track down the problem, tools such as Sysinternals → ProcMon → ProcExplorer → Depends. These are all a tiny download and don’t require any install. But they’ll help you track down what DLL dependencies are missing. This is the option I opted for to fix the issue above. Overall, you’ll have to wade through the logs patiently, but it will highlight any issues found.