Crash on map load after updating to 4.17

Hi,
I want to use 4.17’s VR Spectator mode on a project we have already created in 4.15.
I crated a new project in 4.17 and migrated the map (there’s only one) from our 4.15 build into the new 4.17 project.
That worked fine, and afaik all other dependencies are included (4.17 versions of the 3 plugins the project uses).
I open the new 4.17 project and open the map.
At 30% load the editor crashes with the ‘An Unreal process has crashed…’ etc
The Project.log file doesn’t include an info on why the crash occured, or any errors at all. It’s pretty short and looks pretty clean (stating stuff like MapCheck: Map check complete: 0 Error(s), 0 Warning(s), took 48.085ms to complete.)

How do I go about debugging and fixing this type of error?

I have sent the log files to Epic after the crash but I have done this before and they seem to just get sent and no answer/reply is there any way of chasing this up to get some experienced help on how to fix this issue?

I can subit the LoginId/EpicAccountId if needed or the log files directly if anyone can help?

Thanks

It sounds like a missing DLL. Get the crash log. It’s different from the UE4 log.

Thanks for your suggestion @anonymous_user_64f7311b

I have tried to locate the crash log using the wiki doc you sent me…

It states (under Crash Logs) that you can find the crash log at the following location…
%USERPROFILE%\AppData\Local\Microsoft\Windows\WER\ReportQueue
However, that path doesn’t exist (it gets as far as %USERPROFILE%\AppData\Local\Microsoft\Windows\WER and then the only file/directory available is called ERC and that’s empty.

Has the crash log path location changed since this doc was written?
Or am I looking at the wrong thing?

I’m hopeful if I can find the stack/crash log I will be able to do the rest myself but as you say I need the crash log not the UE4 log

Thanks

That might mean the crash report client didn’t get to compile the data. It can take a while. Perhaps try letting it crash and not killing the process. Tho I’ve let it report crashes and I don’t have a “ReportQueue” directory either. I looked around but I don’t see it anywhere

Does the crash reporter window pop up and ask you if you want to send the data to Epic?

You could also try to see if Windows logged the source of the failure. GL.

Thanks @anonymous_user_64f7311b

It turns out on my machine the crash logs are located at…
C:\Users\SJD\AppData\Local\CrashReportClient\Saved\Logs

So I have found the log and it is indeed missing dll files causing the crash it seems.
Specifically…

LogWindows: Failed to load ‘aqProf.dll’ (GetLastError=126) LogWindows: File ‘aqProf.dll’ does not exist LogWindows: Failed to load ‘VtuneApi.dll’ (GetLastError=126) LogWindows: File ‘VtuneApi.dll’ does not exist LogWindows: Failed to load ‘VtuneApi32e.dll’ (GetLastError=126) LogWindows: File ‘VtuneApi32e.dll’ does not exist

I have spent hours now trying to find a fix but I think it’s just simply a bug with Unreal that hasn’t been fixed yet.
I did find a couple of posts which gave me hope

and this

which led to this

But neither updating to the 4.17.2 (or Preview 4.18.1) or deleting Intermediate & Saved folders helped.
It’s still crashing when opening that map and throwing those ‘failed to load dll’ errors.

I thought I may be able to fix this myself but a bit stuck now.

Has anyone else came across this issue?

Anyone at Epic able to shed any light on it?

Thanks

Those missing DLL messages have been red herrings for a number of problems recently. If you look, they are at the beginning of the UE4 log file and it gets past that before it crashes. So the crash is from something later. I think it’s probably a different DLL that is missing. One that is deferred like for a third-party plugin. Was there anything else in the crash report?

I have those same missing DLL errors in my log and my game session didn’t crash. I suppose if your code needs them then it would. I doubt that’s it but you could try to figure that out.

If you didn’t have ntdll then I’m pretty sure you’d have a lot more problems than you do now. Post the entire log – actually, both the UE4 and crash logs. The toolbar lets you embed text/links/etc into a post. Or GDrive and link it, or something.

That’s handy to know - I thought it must be to do with those so good if it isn’t (hopefully!)

The only other reference in that entire crash log to a dll is under GetContextStackTrace() where it lists 71 frames wit the 71st being…
[2017.12.06-17.48.22:158][ 0]LogCrashDebugHelper: 70: ntdll
That’s the only place ‘dll’ comes up in a search/find in file.
So I don’t think it’s a missing .dll unless it does happen to be the red herring of aqProf/VtuneApi/VtuneApi32e ?

To be honest there’s nothing in that crash log that’s a smoking gun - no other ‘errors’ a few warnings
like
‘Warning: CrashDebugHelperConfig invalid’
‘Warning: PDB Cache disabled’
‘Warning: Callstack generated with 0 valid function names’

That’s about it?

I have found it only happens when I try and add a blueprint (created in 4.15 and referencing loads of other assets and blueprints so hard to isolate to an exact asset or piece of code/node) to my 4.17 project.
I can migrate the blueprint in, but if I try and add it to my map it also crashes it.

Something about 4.17 doesn’t like that blueprint or one of the assets but it’s hard to nail down which/where.

Would it only be the CrashReportLog.log which could contain debug / stack trace info, or are there other logs/places to look that might contain the answer?

Thanks again!

Haha - yeah I didn’t think it was the ntdll - though I’m no expert as you can probably tell!"

Thanks @anonymous_user_64f7311b

Here are the logs
link text
link text

Edit::
wrong UE4 (project) log! That one has errors and warnigns related to a plugin I didn’t have enabled. It’s from one of the trial and error tests I’ve been doing but those errors would also be red herrings. Instead of forestofserenity.log use FoS.log

This is the correct one…
link text

My bad :slight_smile:

K, so two things. First, if you’re using VR (I see motion controller messages) then you might want to make sure all the correct DLLs are in all the correct places.

The other thing is in the crash report. The stack trace isn’t very informative but it’s very long so I wonder if maybe there is a recursive loop in the code causing a stack overflow.

Finally, the crash log references “D:/Work/_temp/FoS/Shell_416/FoS/Saved/Crashes/UE4CC-Windows-6325A60F47D59437D4853FA9C5A657ED_0000/UE4Minidump.dmp”. Does that have any more info?

Oh, also, you should try building and running it in debug mode. You can debug in VS and it will stop in the code where the crash happens, and running it at all, the logs should be more robust.

A massive thanks for all your help and advice on this!
I’ve still not found the issue but am getting better at the debug process, I’m going to carry on tomorrow and will post up anything I find in case it can help anyone else.

Cheers

I got around to looking into this again today, and followed your advice of building and running in debug mode via VS.
That helped and I followed through the stack trace to what was essentially a variable naming error in one of the blueprints.
That naming issue wasn’t a prob in earlier versions of UE but was throwing an error in obj.cpp which helped me to track it down.

So in short - yes the missing aqProf/VtuneApi/VtuneApi32e dlls were a red herring so anyone that comes to this post because oft hat be aware that it may well be another issue but you will have those lines in your crash log anyway.

Thanks again @anonymous_user_64f7311b for helping me figure this one through and learn a little extra about debugging tools and processes in UE, I appreciate it.

Good to hear. Were you able to repair the name?