Crash Reporter not showing up - what to do

Apologies for the delay. We are currently investigating this issue, and we’ll respond as soon as we have additional information.

Thanks for your patience.

I just found out that there are crash reporter log files stored under \AppData\Local\CrashReportClient\Saved\Logs.
This file indicates that the crash reporter starts, prints two warnings, and then (within the same second) exits again:

[2016.08.07-09.54.26:129][  0]LogCrashDebugHelper:Warning: CrashDebugHelperConfig invalid
[2016.08.07-09.54.26:129][  0]LogCrashDebugHelper:Warning: PDB Cache disabled

I attached the full log file.

Comparing this logfile to my colleagues (where the CrashReporter works), reveals that the warnings are normal. However, if you take a look at line 12, the command line (how the crash reporter got called) is completly different.

Usually the command line should contain arguments with crash-information. However, for some reason mine doesn’t. The location of my CrahReportClient.exe is also strange. But it seems that this doesn’t matter, because:

On my Laptop, the command line from line 12 looks normal (nice path with arguments). Other than that, it behaves the same. Immediately after the two warnings the CrashReporter exits.

UPDATE:
After downloading and debugging the CrashReporter, I was able to narrow down the issue. The CrashReporter itself is not the problem and works correctly.

However, the crash files within the Windows Error Reporting (WER) folder are incomplete. It seems that UE4 (or Windows?) should write dumps (*.log, *.xml, *.dmp) to the folder C:\ProgramData\Microsoft\Windows\WER\ReportQueue. Afterwards, the CrashRepoter looks through the files and generates the report.

On my machines, the crash report files are not written. There exist the correct subfolders within the ReportQueue directory, but they only contain a single Report.wer file. There are no xml files, and so the CrashReporter can’t do it’s job.

Who is writing these files? UE4 or Windows? Any idea why they are not present?

Hi Maja

The CRC log you attached appears to have an incomplete command line. I’d expect it to contain -AppName=BubblegumBase. That doesn’t look like an instance of he CRC that was executed by the engine. You can see the code that builds the command line here https://github.com/EpicGames/UnrealEngine/blob/4.12/Engine/Source/Runtime/Core/Private/Windows/WindowsPlatformCrashContext.cpp.

Also the editor log you posted earlier appears to show the editor being closed deliberately “[215]Cmd: QUIT_EDITOR” not crashing.

If you’re only getting Report.wer and not the other files saved to the crash folder, can you post that file please? Also, are you seeing any crashes saved to your project’s log folder? They will be in subfolders called UE4CC-Windows-*.

Chris

I’m also wondering if we are having problems with WER here. Can you double-check that a new folder is generated in your WER queue folder when you crash and tell us exactly where this folder is located. Might be worth checking the WER settings in the registry too. See here WER Settings - Win32 apps | Microsoft Learn

Finally!

Thanks for your help, I was finally able to resolve the issue.
The first thing I do (and what everyone else should do) after installing a brand new Windows 10 is changing the privacy settings. I don’t want my OS to send private information back to Microsoft. There are quite a lot of these settings, and one of them tells Windows Error Reporting (WER) to not create any memory dumps / diagonstic data (of course the name of the setting doesn’t tell much about that behaviour).

To find out if WER settings are the issue:

  • Open up a project in UE4
  • Open the console and type debug crash
  • The engine will crash instantly and there will be no crash reporter showing up
  • Go to the folder where WER stores debug information. The folder location can be looked up in the registry (msdn page). In my case, it’s “*C:\ProgramData\Microsoft\Windows\WER\ReportArchive*”
  • Look into the correct folder for the UE4 crash. If it only contains a single “Report.wer” file, windows error reporting has been disabled and WER is the issue.

How to resolve the issue:

  • In Windows 10, head to “Settings > Privacy > Feedback & Diagnostics

  • There will be a setting called “Diagnostic and usage data

  • This setting must be set to “Enhanced” or “Full” for the crash reporter to function

  • After changing this setting, the PC doesn’t have to be restarted. Just open up an UE4 project, enter debug crash in the console, and now the crash reporter should show up.

Other Resources:

How to open the UE4 console with a different (eg. german) keyboard layout

Microsoft article about the “Feedback & Diagnostics” setting

Locations of all Windows 10 Privacy settings

1 Like

Finally indeed! Though I had to reboot, this method worked.

Also not seeing the Crash Reporter, but nothing is generated in the WER folders. I am getting the UE4CC-etc folders in log, however.

Hoping for a solution soon; the logs don’t seem to contain anywhere near the information the Crash Reporter did. Many so far haven’t told me anything beyond “Fatal error”.

I am still on Windows 7 (I like 7 and was displeased with how they basically tried to shove 10 down my throat), so if anyone knows the 7 equivalent of the accepted answer, I’ll try that in case.

I’m glad this is working for you! I’ll add this info to my notes. We really shouldn’t be relying on these Microsoft settings. I’ll look into separating them.

You could look at the WER settings in the registry. I’m assuming these are now wrapped by the settings options in Win10…

No luck. Please do separate the crash reporter from Windows settings; having them connected means additional failure points.

A (non)update of the situation: testing in 4.13, still no crash reporter.

I need a solution. I’m flying blind with the inevitable crashes from UE4, as I haven’t seen a stack trace since this started. I never thought I’d miss seeing the crash reporter.

Solution Found: Soluto was “handling” the crashes. Disabling that feature brought back the reporter.