At least once a week, someone tells me that their Mac keeps “crashing” when what they actually mean is that it’s suffering repeated kernel panics. This article explains why kernel panics are so important, why they’re not mere “crashes”, and what you need to do about them.

The term “crash” is vague, and could mean any software problem. It might just mean that an app suddenly quits when you don’t expect it to, or it could mean that your whole Mac has collapsed in a snotty heap and had to restart itself. A “crash” could mean anything untoward, so is almost meaningless.

What makes the kernel panic

macOS is divided up into two main parts: there’s the kernel, together with hundreds of kernel extensions, which run in their own protected space, and there’s the user area, which includes many processes being run as root, and those of other users like you. This is intended to protect the kernel from the mayhem that can happen in user space, with processes running into trouble and being terminated for different reasons. What’s important is that the kernel keeps running in the face of whatever happens in userland.

Inevitably, this doesn’t always work, and sometimes the kernel is reduced to a state that the only way it can recover is to restart. The way that it does that is to panic, which should then result in your Mac being restarted, although some Mac models on some occasions simply shut down and leave you to restart them. There are also occasions when problems in the kernel are so bad that it can’t even panic properly, and your Mac just freezes, requiring you to force shutdown using the Power button.

A kernel panic is therefore pretty well the most serious software failure of all. It should never happen, and if it does, you must take it seriously and not just dismiss it as a “crash”, whatever that might mean. If it happens repeatedly, then it demonstrates that something is seriously wrong, and needs fixing. So discovering what caused a kernel panic is critical.

What you see

Many versions of macOS ago, most kernel panics displayed a characteristic screen which made clear what had happened. You’ll never see that again, and if you Mac’s unattended when it panics, you might be almost unaware of what happened; if you witness it, it’s unmistakeable, as your Mac spontaneously and unexpectedly restarts. A little while after you’ve logged back in, you should see a Panic Alert, as I’ll explain later.

If your notebook panics in its sleep, or when trying to wake, all you might see is that Mac shut down, or prompting you to log in when it should instead have woken up normally. It’s easy just to get on with it, and to miss the Panic Alert altogether, if it appears. On one occasion, I didn’t notice it for several hours, until it surfaced from among all the windows I had open.

The panic log

If you ever see an alert warning you that your Mac was restarted because of a problem, that’s diagnostic of a recent panic. Don’t simply send the report to Apple, though, as it’s the only readily accessible record of what happened. Panic logs used to be saved in /Library/Logs/DiagnosticReports, from where you could open them in Console, but more recently may be found somewhere closer to /var/db/PanicReporter. They’re thus best copied as soon as they appear and before sending them to Apple.

If the alert isn’t already showing the panic log, click on its Report… button then open a text editor like TextEdit. Copy the whole contents of the panic log into an empty text window and save it somewhere safe before clicking on the button to send the report to Apple. Once you’ve done that, the alert is dismissed and can’t be brought back again.

It’s common to assume that sending a panic log to Apple means that an engineer will look through it and get back to you with some sort of diagnosis. That isn’t what the report does, though. Instead it’s processed automatically and, while there’s nothing stopping someone at Apple contacting you about it, that simply doesn’t happen. Only by saving a copy of the log could you then contact Apple Support and ask for their help. Also consider filing a Feedback report containing a description of what happened and your copy of the panic log, particularly if you have clues as to its cause.

If you haven’t saved a copy of the panic log, then there’s little more you can do until the next kernel panic. Because many panics still result from hardware problems, it’s always worth running hardware Diagnostics. You should also check through any third-party kernel extensions, and other third-party hardware and software which might be involved.

You’ll find further information here, and here, and more details about panic logs in this article.

Remember:

• Don’t just carry on; kernel panics are one of the most serious software problems that can occur and should never be ignored. Apps can crash, but kernels panic.
• Don’t accept that your Mac just panics often. It should never panic at all, and anything more than one panic a year needs to be properly investigated and reported.
• Copy and paste the whole panic log into a text document for reference.
• Report kernel panics to Apple using Feedback as well, and when you get time ask Apple Support for their help.