How to read a Mac crash report: the lines that matter

When an app on a Mac crashes, macOS writes a crash report: a long text file that looks like pages of hexadecimal. You do not need to read all of it. A handful of lines near the top tell you which app crashed, which version, on which macOS release and why the system stopped it. The rest is mostly detail for the app's developer.

Where to find Mac crash reports

Apple's Console app collects them:

1. Open Console from Applications, then Utilities.

2. In the sidebar, under Reports, select Crash Reports.

3. Choose the report for your app. Apple's developer documentation says reports are listed by the app's program name, which is not always the name you see in the Dock.

4. To get the file itself, right-click it and choose Reveal in Finder.

Apple's Console guide says crash reports use the .ips extension. Older reports may end in .crash. Console also lists Spin Reports (details about app or process issues such as hangs) and Log Reports, which are different from crash reports.

The lines that matter most

Here is a trimmed sample (synthetic, from a fictional Northgate Notes app):

Process: Northgate Notes [4127]

Version: 3.2.1 (3210)

OS Version: macOS 15.6 (24G84)

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11

Triggered by Thread: 0

Thread 0 Crashed:

0 NorthgateNotes 0x0000000102a3c2f4 -[NoteListController reloadNotes] + 120

Apple's "Examining the fields in a crash report" page explains each field:

• Process: the program that crashed. The number in brackets is its process ID, which changes every launch.

• Version: the app's version and build number. Check it against the latest version available.

• OS Version: the macOS version and build number. Crashes that start right after a system update are worth noting.

• Incident Identifier: a unique ID for this report. Apple says two reports never share one, which makes it handy when you contact support.

• Exception Type: the low-level reason the process ended, with the matching signal name in parentheses.

• Termination Reason: why the system stopped the process. Apple lists examples such as an invalid code signature, a missing library the app depends on, or accessing privacy-sensitive data without the required explanation.

• Triggered by Thread: which thread the problem started on. Apple notes it may appear as Crashed Thread instead.

Below these, each thread has a backtrace: a numbered list of the functions that were running, most recent first. Find the thread marked "Crashed" and read its first few lines. If they mention the app's own name, the fault is probably in the app. If they only mention system frameworks, the app may still be the cause, but the trail is harder to follow.

What the common exception types mean

Apple's page on exception types gives short definitions:

• EXC_BAD_ACCESS (SIGSEGV): the process tried to use an invalid or out-of-bounds memory address.

• EXC_BAD_ACCESS (SIGBUS): a bus error, often a misaligned or invalid memory address.

• EXC_CRASH (SIGABRT): the process received an abort signal. Apps often abort themselves when they hit a condition they were not built to handle.

• EXC_BREAKPOINT (SIGTRAP) or EXC_BAD_INSTRUCTION (SIGILL): often means the process violated a requirement or timeout.

• EXC_RESOURCE: the system stopped the process for using too much of something, like CPU time or memory.

• EXC_GUARD: the process broke a guarded resource protection, often related to open files.

None of these tells you exactly what went wrong inside the app, but they narrow it down. Memory errors and aborts are usually bugs for the developer. Resource limits can point to a very large file or a runaway task.

What to try before contacting the developer

1. Update the app to its latest version, then try again.

2. Check compatibility with your macOS version on the developer's website, especially after a major system update.

3. Repeat the steps that led to the crash. If it happens every time you open one file, note that file.

4. Restart the Mac and see whether the crash returns.

5. Read the Termination Reason closely. A code-signing or missing-library message often means a damaged or incomplete install, which reinstalling from the original source may fix.

6. Look for a pattern. Open two or three recent reports for the same app. If the Exception Type and the first lines of the crashed thread match each time, tell the developer: it points to one repeatable bug rather than bad luck.

Sending a crash report to support

Developers usually want the whole file, not a screenshot. Apple's developer documentation suggests sending the .ips file when one is available. Before you send it, skim the report: crash reports can include file paths with your user name, and sometimes the names of documents. If you need to post one in a public forum, our guide on sharing logs safely explains what to remove. If the developer sends back a trace from their side, our guide to reading a stack trace covers the same ideas in other languages.

In your message, include the app version, the macOS version, the Incident Identifier, what you were doing and whether it happens every time.

Have the crash report explained

EasyToDecode is launching soon. You will be able to paste or upload a Mac crash report and get the lines that matter quoted back to you (process, version, exception type and the crashed thread), a plain-English explanation, and a short message to send the app's developer. See how it works or join the waitlist to hear when it opens.