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
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.
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.
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 
Version: 1.0b1 (1)
Code Type: X86-64 (Native)
Parent Process: launchd 
Coalition: co.eclecticlight.Signet 
Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid))
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: CODESIGNING 1
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.