Telling what caused a kernel panic isn’t easy, but even if you’re not particularly technical you should be able to discover what went wrong using some basic clues. This article explains how you can do that.

What crashed my Mac?

The first thing is get away from referring to your Mac ‘crashing’. Like crashing a car, it could just be a bit of paintwork damage from a post, or the car could have been reduced to a total wreck. When you call your insurer, you’ll need to be much more specific – just as you must be when describing what happened to your Mac.

The first essential distinction to make is whether this is an app (or other software, such as a Preference Pane, or even the Finder), or macOS itself which has suffered a problem. macOS is engineered so that user processes like apps should be able to ‘crash’ and quit unexpectedly without affecting other apps or the rest of the system. The cause may not be the fault of the app, and unravelling exactly what went wrong is often impossible. macOS should offer you a crash report which you should send off, and the option of re-opening the app to try again.

Unless your Mac starts behaving oddly, it should be safe to carry on using it, opening the app again to see if you can get it to work better next time. If you do feel the need to clear away any debris, it should be sufficient to log out and log back in again, rather than having perform a full restart.

When macOS runs into trouble, the signs are more general and affect pretty well everything. Your Mac may spontaneously shut down or restart, you could be logged out suddenly, or everything could just freeze. The most common reason is a kernel panic, but another cause is a WindowServer crash, which normally freezes the screen for a short while before making you log back in.

The macOS kernel is engineered to keep going through all adversity, but sometimes an error or fault is too severe for it to be able to recover. If this results in the system simply stopping, the display may just freeze and show no signs of resolving. If your Mac doesn’t restart itself or shut itself down of its own accord, you may need to press and hold the Power button to force that to happen.

What happens next?

If you’re present when your Mac has a kernel panic, make a note of the time, as that will allow you to browse the log once it’s back up and running again. Sometimes, the panic happens when the Mac is unattended, and you come back to see it either shut down or waiting for you to log in after a restart. That makes it harder to discover when the kernel panic happened, but it’s by no means difficult.

When your Mac starts up after a kernel panic, after a minute or two you should be presented with a panic log in a dialog box, inviting you to add details and send it to Apple. Whatever you do, add information such as ‘spontaneous restart after trying to wake from sleep’, and anything else which might be useful, and send it. This enables Apple’s engineers to know that the panic happened, and the information will help them identify the cause and hopefully strive to fix it.

Select the text in the panic log, copy and paste it into a document for your reference. I’ll explain more about how to read panic logs in a later article, but in many cases the first lines will provide a useful if provisional diagnosis, such as “zalloc: zone map exhausted while allocating from zone kalloc.12288”, which means there’s a memory leak.

Common scenarios

The most common situation for a kernel panic in many Macs is when trying to wake from sleep, either because you’ve tried to wake it up, or a notification or other event has occurred. Wake from sleep panics occur because this transition requires macOS to reload and reactivate system components, in the course of which it may encounter a fatal problem. They’re most commonly attributed to bugs in the Mac’s firmware, although third party kernel extensions are another common cause.

The complementary pattern of kernel panics occurring in the transition to sleep are rarer, and occur when macOS is trying to unload in preparation for the sleep state. Causes are normally similar, in firmware or third party kernel extensions.

By far the most serious type of kernel panic is one which occurs during early startup. The Mac then enters a seemingly endless cycle of panicking and rebooting. The firmware should impose a maximum limit on the number of times your Mac cycles through this, but don’t wait for that to happen: press and hold the Power button until it shuts down. Startup-panic cycling typically occurs when there has been a serious problem with a firmware update: the last time it occurred in many Macs, Apple had distributed a broken firmware update for the T1 chip in MacBook Pros. It can also occur with hardware failure (as can all kernel panics), and should be followed by starting up into hardware diagnostics to check.

Kernel panics which seem to occur out of the blue can result from sudden catastrophe, or a longer-standing problem such as a memory leak. If the latter, browsing the log for the minutes before it ends may reveal many entries from the kernel as it tries to cope with running out of memory, killing processes, and trying to keep going. You can see good examples here.

More difficult are those panics which just happen regardless of what else is going on, and you can never find any evidence in the log. In many cases, the panic log may also be unhelpful. Try to discover their pattern if there is one, otherwise you’ll just have to keep observing carefully.

Useful checks

Normally, the most common cause of a kernel panic should be hardware failure. If you’ve ever had a disk develop a hardware fault, you may have experienced a panic because of that, and they can readily occur with failing memory or the logic board. Because of that, a valuable check after any kernel panic is to run hardware diagnostics, which should reassure you that there’s nothing fundamentally wrong with your Mac.

Third-party kernel extensions are disabled, together with a lot of other software which can cause panics, when you start up in Safe mode. However, disabled software includes many extensions and other items which are commonly needed to do anything useful, so you’re unlikely to be able to use this to diagnose the cause of a panic.

The unified log can give valuable information as to what led to a panic, and it’s always worth browsing soon after your Mac starts up again. However, don’t expect to see entries right up to the time of the panic: when the kernel panics, normal log function has usually already ceased, and any log records currently stored only in memory are unlikely to get written out to disk before your Mac restarts. This article explains how to investigate logs using my free tool Ulbow.

In more recent versions of macOS, when it restarts, your Mac may automatically perform a sysdiagnose, in which it collects logs and a great deal of other information, which is then archived and compressed ready to send to Apple’s engineers. If this happens, the Finder should open the folder containing the sysdiagnose to show you where it is. If you contact Apple Support, or report the panic using Feedback, you will then be asked to send Apple that sysdiagnose to help discover what went wrong. Otherwise it’s worth putting in the Trash, as it’s quite large.

Remember:

• Use a more specific term than ‘crash’.
• Identify whether it’s just an app or macOS which is affected.
• Note the time of any kernel panic, if you witness it.
• Add useful information to the panic log and send it to Apple.
• Run hardware diagnostics to eliminate hardware problems.
• Use the panic log and the unified log to look for a cause.
• Send any sysdiagnose to Apple when requested.
• No Mac should ever suffer a panic.