How macOS reports crashes

When an app or other software crashes, it used to be Crash Reporter that told you in a modal dialog containing the crash report. In recent versions of macOS, this has been replaced by a complex of processes with Problem Reporter, located on the System volume in /System/Library/CoreServices, doing the interface work. This doesn’t apply, of course, to kernel panics, which work very differently and should automatically restart your Mac, then display a Panic Log.

Crash Reporter had a chequered history. Many years ago, Apple released a broken version of the app in a macOS update, which not only crashed itself, but sometimes turned a simple app crash into a full-blown kernel panic. Thankfully the current combination seems to work largely as advertised.

Crash reports now depend on CrashHandler and two ReportCrash processes, one for root and the other for the user. The latter are run by launchd according to the Property Lists in

/System/Library/LaunchAgents for the user ReportCrash
/System/Library/LaunchDemons for the root ReportCrash com.apple.ReportCrash.Root.plist

Another System LaunchDaemon is responsible for launchd running CrashReporterSupportHelper. As each of these components – /System/Library/CoreServices/ReportCrash, /System/Library/CoreServices/CrashReporterSupportHelper and /System/Library/CoreServices/Problem Reporter.app – and those Property Lists are all stored on the System volume, they can’t be removed or changed.

Oddly, the behaviour of Problem Reporter is partly determined by a preference file still named after its predecessor Crash Reporter, found at ~/Library/Preferences/com.apple.CrashReporter.plist. This can be changed using the defaults command tool, but currently there seem to be only two functional preferences. A separate preference file named com.apple.ProblemReporter.plist saves settings for window size, position and other interface controls.

The default LogCrashes = YES writes crash logs into a traditional log file accessible in Console under Crash Reports. The setting UseUNC = 0 is more useful. As Guilherme Rambo @_inside has pointed out, setting that to 1 changes crash reports from their default modal dialog to a notification.

This is the default crash report with UseUNC = 0.

And this is the notification which replaces it when UseUNC = 1. Hover the pointer over the lower right of the window and you can then click to see the default window instead. The command to use for that reads
defaults write com.apple.CrashReporter UseUNC 1
to use notifications instead of the dialog.
Apple also used to supply a utility with Xcode named CrashReporterPrefs.app which could change Crash Reporter’s preferences, but that is now old and can’t even be opened.

In the distant past, you could turn Crash Reporter off. Now that it’s Problem Reporter and locked away on the System volume, you can disable ReportCrash, according to its man page, using the commands
launchctl unload -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

You can restore crash reporting with the following two lines:
launchctl load -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

I haven’t tested those in Monterey, though.

Crash Reports

Although Apple provides little information for users about Problem Reporter, crash reports are now documented extensively. The master page provides links which explain:

the structure of a modern crash report,
the exception types given for different causes,
how to identify the cause of common crashes.

In practical terms, unless the software that crashed is yours, trying to interpret the cause of the crash from a crash report is difficult and achieves little to help you. However, sending the developer the crash report together with instructions as to how to reproduce the crash is invaluable, as it will help them fix the crash, and improve their software.

Occasionally, though, crash reports are revelatory for the user. Here, for example, is one that I have deliberately generated. This is the summary or ‘translated report’.

Incident Identifier: 71383068-FEF5-422C-AC90-21B8CED55EED CrashReporter Key: E29803D9-C348-491D-3236-CFF765A4E549 Hardware Model: iMacPro1,1 Process: Signet [90704] Path: /Users/USER/Documents/*/SignetTest1.app/Contents/MacOS/Signet Identifier: co.eclecticlight.Signet Version: 1.0b1 (1) Code Type: X86-64 (Native) Role: Default Parent Process: launchd [1] Coalition: co.eclecticlight.Signet [94569]
[snip]
Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: CODESIGNING 1
[snip]
EOF

It should be obvious that the app’s signature was invalid, and as a result of that macOS deliberately crashed the app.

Crash/problem reports can be browsed at your leisure using Console.

4Comments

Add yours

1

Sebby on December 14, 2021 at 5:25 pm

CrashReporterPrefs is still available and is maintained with modern Xcode; you just have to retrieve it from Apple Developer under the obscure “More Downloads” page where Apple drops all the sundry stuff most people don’t need for development (kernel debugging, conformance tests, Windows tools, standalone command-line installers, etc, etc). It supports the new NC preference in the UI.

LikeLiked by 1 person
- 2
  
  hoakley on December 14, 2021 at 8:18 pm
  
  Thank you.
  I have a copy in my XcodeTools folder here, but for some reason macOS decided it was broken with a signature problem. As it turns out, it isn’t particularly useful anyway.
  Howard.
  
  LikeLike
3

Ian Nieves on March 5, 2022 at 7:47 pm

I believe that crash reports, just like log data and debug output of any kind are almost always the only starting point you have to resolve/fix issues. If you don’t get comfortable analyzing these, you are basically guessing in the dark at a fix or ignoring a problem, both of which are bad for you.

LikeLiked by 1 person
- 4
  
  hoakley on March 5, 2022 at 10:05 pm
  
  Thank you.
  I’d place the starting point rather earlier and more basic: careful observation, and, if possible, discovering a reliable way to reproduce the problem. When a user can tell me how I can see the same issue that they’re encountering, it’s worth a thousand crash reports, which in non-debug builds seldom contain much useful information at all. Log excerpts are excellent, although very few users are capable of accessing the log, so asking for them is usually asking for the impossible.
  Howard.
  
  LikeLike

Share this:

Like this:

Related