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. You 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.
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”

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: com.apple.WebKit.WebContent [6929]
Path: /System/Library/Frameworks/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.xpc/Contents/MacOS/com.apple.WebKit.WebContent
Identifier: com.apple.WebKit.WebContent
Version: 15608 (15608.2.30.1.1)
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 Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000004
Exception Note: EXC_CORPSE_NOTIFY

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: com.apple.main-thread
0 com.apple.WebCore 0x00007fff3e26977a WebCore::HTMLMediaElement::mediaCanStart(WebCore::Document&) + 90
1 com.apple.WebCore 0x00007fff3cda7057 WebCore::Page::setCanStartMedia(bool) + 343
2 com.apple.JavaScriptCore 0x00007fff32be97eb WTF::RunLoop::TimerBase::timerFired(__CFRunLoopTimer*, void*) + 27
3 com.apple.CoreFoundation 0x00007fff2e585ff6 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
4 com.apple.CoreFoundation 0x00007fff2e585bb0 __CFRunLoopDoTimer + 872
5 com.apple.CoreFoundation 0x00007fff2e5855c3 __CFRunLoopDoTimers + 317
6 com.apple.CoreFoundation 0x00007fff2e566860 __CFRunLoopRun + 2227
7 com.apple.CoreFoundation 0x00007fff2e565d38 CFRunLoopRunSpecific + 503
8 com.apple.Foundation 0x00007fff30c26cad -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
9 com.apple.Foundation 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 com.apple.WebKit 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, com.apple.WebKit.
• The third column is the counter program address.
• The fourth column is the task.

From this example, we know that, for example, “com.apple.WebCore 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:

• How To Reset Network Settings On Mac
• Mail App Keeps Crashing & Won’t Open; Fix