Crash Reports: How To Use Them To Troubleshoot Why Your Mac Crashed

This article’s focus is on macOS crash reports. More specifically this article explains how you can (1) locate crash logs (2) and read them to diagnose a crash.

Your Mac can crash, rarely. These crashes usually mean nothing important, if it is rare. Thus it is not something you should worry about. In most cases, restarting your Mac will resolve the issue. Your Mac will automatically reboot itself.

However, if your Mac is crashing frequently, you may want to find our why these crashes occur so that you can prevent them from happening again. And the most important thing you should do is to find more specific error details.

In this article we are going to take a look at using the crash logs that your system generate. These logs will help you identify what’s causing the crash.

See also: How To Use Network Utility on Mac

Where to find crash reports

There are two ways to access your crash reports. You can use any of the methods:

  1. Console AppYou can use the Console app. The Console app included with your Mac. You can open this app by going to Applications > Utilities > Console. You can also use Spotlight to access Console. Select your Device and click Crash reports under the ‘reports’ section.Console Crash Reports
  2. You can also find your crash reports in ~/Library/Logs/DiagnosticReports/. Here is how you can access there:
    1. Go to Finder
    2. Now press the Option key and then click Go (while you are pressing the Option key)
    3. Click Library
    4. Click the Logs folder
    5. Click the DiagnosticReports folder
    6. And open the file that says “Crash”Crash Reporter

See also: Restart your Mac in Safe Mode

How to read macOS crash reports

Understaing these reports can be difficult as they are usually big. Here is how you can decipther a crash report:

1. The first section of a crash report includes what process crashed. Something like this:

Process: [6929]
Path: /System/Library/Frameworks/WebKit.framework/Versions/A/XPCServices/
Version: 15608 (15608.
Build Info: WebKit2-7608002030001001~1
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Safari [509]
User ID: 501

In this case, said process is WebKit (Safari).

2. The next section of a crash report includes date/time and operating system, like this:

Date/Time: 2019-10-26 10:25:58.412 +0300
OS Version: Mac OS X 10.15 (19A583)
Report Version: 12

3. The next section includes more crash details (The Exception), something like this:

Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000004

There are four common exeption types, according to Apple:

EXC_BAD_ACCESS/KERN_INVALID_ADDRESS — This is caused by the thread accessing unmapped memory. It may be triggered by either a data access or an instruction fetch; the Thread State section describes how to tell the difference.

EXC_BAD_ACCESS/KERN_PROTECTION_FAILURE — This is caused by the thread trying to write to read-only memory. This is always caused by a data access.

EXC_BAD_INSTRUCTION — This is caused by the thread executing an illegal instruction.

EXC_ARITHMETIC/EXC_I386_DIV — This is caused by the thread doing an integer divide by zero on an Intel-based computer.

The next section includes backtrace information. There can be one or multiple threads. In reverse chronological order, each thread shows the series of events .

To understand this section, find the thread that crashed. You can easily find that, because the report will say something like this: Thread (thread number) Crashed. This section explains what lead to the crash.

Like this:

Thread 0 Crashed:: Dispatch queue:
0 0x00007fff3e26977a WebCore::HTMLMediaElement::mediaCanStart(WebCore::Document&) + 90
1 0x00007fff3cda7057 WebCore::Page::setCanStartMedia(bool) + 343
2 0x00007fff32be97eb WTF::RunLoop::TimerBase::timerFired(__CFRunLoopTimer*, void*) + 27
4 0x00007fff2e585bb0 __CFRunLoopDoTimer + 872
5 0x00007fff2e5855c3 __CFRunLoopDoTimers + 317
6 0x00007fff2e566860 __CFRunLoopRun + 2227
7 0x00007fff2e565d38 CFRunLoopRunSpecific + 503
8 0x00007fff30c26cad -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
9 0x00007fff30c26bc6 -[NSRunLoop(NSRunLoop) run] + 76
10 libxpc.dylib 0x00007fff65b809d6 _xpc_objc_main.cold.4 + 49
11 libxpc.dylib 0x00007fff65b697e1 _xpc_objc_main + 559
12 libxpc.dylib 0x00007fff65b692fc xpc_main + 377
13 0x00007fff3f2fbeef WebKit::XPCServiceMain(int, char const**) + 539
14 libdyld.dylib 0x00007fff65916405 start + 1

There are four columns here:

  • The first one is the frame number (reverse chronological), like 0, 1, 2, 3….
  • The second one is the name of the program or other process that performed the task. In this instance,
  • The third column is the counter program address.
  • The fourth column is the task.

From this example, we know that, for example, “ 0x00007fff3e26977a WebCore::HTMLMediaElement::mediaCanStart(WebCore::Document&) + 90” is responsible for the crash.

Now you know what caused the crash and series of events triggered the crash. This will help you idendify the problem and then address it appropriately.

If your problem is a third-party app, you may want to contact its developer. Tell them your problem and you may want to send a copy of this crash log. You can click the share icon in the Console app to send the report.

See also:

Dr. Serhat Kurt worked as a Senior Technology Director. He holds a doctoral degree (or doctorate) from the University of Illinois at Urbana / Champaign and a master’s degree from Purdue University. Here is his LinkedIn profile.

Thank you for choosing to leave a comment.

Please note the following:

  • All comments are moderated.
  • Your email will NOT be published nor shared.
  • All SPAM comments will be deleted.
  • Please see our comment policy page for more info.

Leave a Comment