UE4 crash reports contain messed-up newlines

[Kalmalyzer]

Description

We use the UE4 crash reporter, integrated according to the guide in the docs. That is, we are not using the Sentry SDK directly.

We have noticed that the "Message" section of all crash reports that are sent via this mechanism does not handle line breaks properly. As in, the entire message (which contains text and callstack entries) is a single long line. I expect that message to contain line breaks.

This is a literal single-line message of one of our crashes (where I have replaced sensitive words with "Something"):

Ensure condition failed: somethingID != EGameModeSomethingID::UNASSIGNED [File:C:/W/ProjectName.CI.Win64-SSomething.ServerAndClient/ProjectName/Source/ProjectName/Private/Game/GameModes/GameModeGameState.cpp] [Line: 85] SomethingRole to SomethingID became Unassigned. Passed in UplinkOwner: ESomethingRole::Something Stack: 0x00007ff685aac44c ProjectName.exe!DispatchCheckVerify<bool,<lambda_ff0b810c303eff7d14db124cd1f3546e> >() [C:\W\ProjectName.CI.Win64-SSomething.ServerAndClient\UE4\Engine\Source\Runtime\Core\Public\Misc\AssertionMacros.h:164] 0x00007ff67faf174c ProjectName.exe!AGameModeGameState::Tick() [C:\W\ProjectName.CI.Win64-SSomething.ServerAndClient\ProjectName\Source\ProjectName\Private\Game\GameModes\GameModeGameState.cpp:85] 0x00007ff68351d9ee ProjectName.exe!AActor::TickActor() [] 0x00007ff6834f94ab ProjectName.exe!FActorTickFunction::ExecuteTick() [] 0x00007ff6842e574b ProjectName.exe!FTickFunctionTask::DoTask() [] 0x00007ff6842ed439 ProjectName.exe!TGraphTask<FTickFunctionTask>::ExecuteTask() [] 0x00007ff67fe57e76 ProjectName.exe!FNamedTaskThread::ProcessTasksNamedThread() [] 0x00007ff67fe582be ProjectName.exe!FNamedTaskThread::ProcessTasksUntilQuit() [] 0x00007ff67fe6739f ProjectName.exe!FTaskGraphImplementation::WaitUntilTasksComplete() [] 0x00007ff6843021d1 ProjectName.exe!FTickTaskSequencer::ReleaseTickGroup() [] 0x00007ff684307584 ProjectName.exe!FTickTaskManager::RunTickGroup() [] 0x00007ff683bcdedf ProjectName.exe!UWorld::RunTickGroup() [] 0x00007ff683bd9148 ProjectName.exe!UWorld::Tick() [] 0x00007ff683a29453 ProjectName.exe!UGameEngine::Tick() [] 0x00007ff67deca1c7 ProjectName.exe!FEngineLoop::Tick() [] 0x00007ff67dee063c ProjectName.exe!GuardedMain() [] 0x00007ff67dee070a ProjectName.exe!GuardedMainWrapper() [] 0x00007ff67dee2b5c ProjectName.exe!LaunchWindowsStartup() [] 0x00007ff67def46f4 ProjectName.exe!WinMain() [] 0x00007ff6857a316e ProjectName.exe!__scrt_common_main_seh() [D:\agent\_work\10\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288] 0x00007fff49cf7034 KERNEL32.DLL!UnknownFunction [] 0x00007fff4b782651 ntdll.dll!UnknownFunction []

When does the problem happen

• [ ] During build
• [ ] During run-time
• [x] When capturing a hard crash

Environment

• OS: Windows 10 64-bit
• Compiler: MSVC 19
• CMake version and config: N/A, we are using Sentry using the UE4 integration - no Sentry SDK involved

Steps To Reproduce

1. Create a UE4 application
2. Configure the INI files for crash reporting
3. Build your application for Win64
4. Run and trigger a hard crash within your UE4 application
5. Observe that the "message" section in your crash report is just one single, long line.

[Swatinem]

So by "crash report", you mean the Sentry Event that is being created? Can you link me to one of those? And do you have a UE4 crash report file attached to the sentry event?

[Kalmalyzer]

Yes, crash report == Sentry Event in the above text. Here is an example of such an event: https://sentry.io/organizations/falldamage/issues/3026682997/?project=1910542&query=is%3Aunresolved

The event contains several attachments:

• UE application log file
• Config file for UE's Crash Reporter: CrashReportClient.ini
• 'Context' file for UE's Crash Reporter CrashContext.runtime-xml
• Windows *.dmp file (minidump) UE4Minidump.dmp

Hmm, looking further into this, I notice that the CrashContext.runtime-xml file contains the same message within the <FGenericCrashContext/RuntimeProperties/ErrorMessage> XML tag. Formatted as a single line. I'm not sure whether that XML file is generated by UE's CrashReportClient or by your ingestion mechanism... but I am beginning to suspect that this is after all not a limitation in your ingestion but in UE's CrashReportClient itself.

[Swatinem]

I am beginning to suspect that this is after all not a limitation in your ingestion but in UE's CrashReportClient itself

I think your conclusion is right. We parse that xml file to extract these messages.