Hi all,
i’m desperately trying to understand which is the best debugging method for a call stack crash.
Editor symbols are downladed for the engine version i’m currently using (which is 4.11.2) but the crash reporter obviously says i don’t have the required symbols to show what caused the crash.
In my packaging settings i’ve checked “Include Debug files” so i tried to analize the generated minidump inside VS2015 but i don’t understand which is the proper way to load UE symbols.
Finally i tried to build UE from source code to use the symbol debugger but even here i don’t understand completely how to load UE symbols.
If someone can explain this step-by-step to me it would be really appreciated!
Hello FraZack,
When you experience your crash, are you in your packaged game? If so, what configuration and platform are you packaging for? If it’s shipping, you likely won’t be able to get the information you’re looking for. If you are in Development, you should be able to see the correct information.
If this is in the editor, you should see it as long as “Editor Symbols for Debugging” are installed for that version of the engine, which you’ve mentioned they are.
Could you also check the log files for the callstack? They can be found in the project’s directory under Saved/Logs and inside of the packaged game’s folder if that’s where the crash is occurring.
If all else fails and you can’t find any information, could you provide me with the EpicID or MachineID from the crash reporter window? I could look up the crash for you at least so we can get that looked at.
As far as the Symbol Debugger goes, unfortunately that wouldn’t be of much use to you in your situation. The Symbol Debugger is meant to link up with Perforce so that teams can get debugging symbols from other members to attempt to debug their crashes for them.
Hi Matthew,
thank you for your answer!
Now things start to be more clear for me and i really appreciated it.
Crashes happens mostly in packaged build which is for Shipping x64 so this may be the reason for CrashReporter not displaying crash details.
Opening the minidup the only details i can collect is that the crash was caused by an access violation error (0xC0000005).
So if i’m understanding it right i have to include debug files but build for Development? What about DebugGame instead?
Just one another quick question: in one of my computers when the game crashes no CrashReporter is opened and no minidump or crashcontext is generated, recently i’ve done a windows clean installation but this has not fixed the issue, what could it be?
When you go to build your game, there are differences between your Visual Studio build configurations and your Packaging configuration. When you package, you have the choice of Development or Shipping. Shipping will exclude any debug files that Development would normally include. Debug Game is an extra one that is only available when you’re building in Visual Studio. This is for running the game through debug in Visual Studio and has no impact on your packaged product.
Access violation errors are caused by a null pointer in most cases, meaning something was expected that wasn’t there. It’s a very general error so you’ll need to look at the surrounding functions and information to learn more about that.
If the game was packaged for Shipping, I wouldn’t expect any kind of debugging information to show up when a crash occurs. Does this computer also have the editor installed? Did you just send the packaged project over to this computer?
Thank you again for the fast answer.
So between Development and DebugGame i should always pick Development for debugging purpose.
About the computer where crashreporter is not opened, it is a computer dedicated only to testing purpose so it has no engine installed but as you mentioned the problem may be caused by the wrong build configuration. I will make some tests by today then i’ll come back with my results.
Thanks!
Hey Matthew thanks a lot for your support.
This happens to be the reason of the crash
I see it has something to do with foliage, am i right?
Could you post the entire log file? Majority of the time, the messages prior to the error can give more information about the issue than the error itself. It seems like it’s getting “nan” which stands for “Not a number”. This means that whatever is setting the bounds of this Foliage is giving it some sort of value other than a number. I would suggest looking at anything that could be changing the settings of this foliage actor.
Sure here is the link to all the appcrash related files:
Most of the times the handled error happens briefly after a streaming level is loaded in and from that point after some random time the game crashes.
From looking at the log and the limited information I can get from the minidump (Our minidumps don’t include heap data so I would need the project’s binaries as well to be able to make use of the minidump), the foliage issue you pointed out above could be related but doesn’t seem to be the main cause. For one, it’s an ensure. Ensures are put in place to warn a user about things but rarely, if ever, cause actual crashes. Usually the process continues past it as shown in the log file. From looking at the minidump, I can at least see that you’re still getting an 0xC0000005 exception code from the actual crash that occurred, which means it’s an Access Violation.
A few questions about this:
- Is this only occurring in a packaged game?
- It seems from looking at the minidump that this game was published to and then downloaded from Steam, based off the file directory. Is that required as part of the reproduction?
- Do you get any crash reporter windows with the new build configurations? If so, please provide either your Epic ID or Machine ID as well as submitting every crash report you get so that I can look them up.
Thanks again for your quick answer:
-
Yes, it is only occurring in packaged game (both Shipping/Development x64)
-
Nope, as far as i noticed steam integration is not related to the crashes occurring.
-
Sure thing:
MachineID:
EpicAccountID:
Here’s another one:
MachineID:
EpicAccountID:
It would’ve helped if I noticed this sooner but I just realized that you’re working out of 4.11. When looking up the crashes you’re receiving, it seems like both of them have been fixed in 4.12 and 4.13. I would suggest upgrading to 4.14 if you can. Please make sure you make a backup copy of your project first however, and try to do the conversion by 1 major version update at a time, as trying to convert across 3 versions might cause a multitude of issues.
Hi Matthew thank you for your effort on this, really appreciated.
The Nans crash is the one which occurs the most and the one we would like to fix:
what i have noticed is that it happens only in a specific map of our game. Within this map the only big thing that differs from other maps is that LPV is enabled across all the level.
But if i understood it right, those crashes are “engine related” (even the one about Nans) and the only solution is to switch engine version to a newer one where they have been fixed, am i right?
It does seem that is the case. I would suggest updating if it as it should fix the issues that you’re encountering.
Hi matthew,
what is the best practice to update to a newer version?
Use the “Switch Unreal Engine version” uproject file option or creating a blank project with the newer version and migrating all the necessary content?
In most cases, using “Switch Unreal Engine Version” should work just fine, but there can sometimes be conversion issues that can be fixed by migrating the content manually. Either way, I would suggest making a backup of the project before you convert in case anything goes wrong.
