Kernel panics aren’t ‘crashes’. When an app crashes, all that should happen is that it suddenly quits unexpectedly, but your Mac carries on working normally. You may be invited to send a crash report to Apple, but everything else continues as it was, just without the app that crashed.
What makes a kernel panic so distinctive is that your Mac shuts down or restarts when you didn’t tell it to. It does so because something so serious has happened to macOS that the only way out is to start it up from scratch, hence the restart or shutdown. This is something that should never happen to a Mac, an event you need to take seriously. It readily leads to data loss, and other problems that will affect what you do on your Mac. Whatever you do next, don’t simply ignore it, or dismiss it as a fault in macOS. It most probably isn’t.
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 start them up again. There are also occasions when problems in the kernel are so bad that it can’t even panic properly, and your Mac just freezes, leaving you to force shutdown using the Power button.
What happens next
A little while after you’ve logged back in, you should see a Panic Alert containing the Panic Log. 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.
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.
What you can do
When running recent versions of macOS, there are three common causes of kernel panics: a problem in your Mac’s hardware, a conflict with a peripheral, and a third-party kernel extension. Many panics occur at certain times, of which the most frequent is when trying to wake up from sleep. That’s because it’s a moment when your Mac also has to reconnect to hardware such as hubs/docks and displays. Drivers that seemed fine can then result in unexpected behaviour sufficiently severe to panic the kernel.
When your Mac has panicked unexpectedly, it’s always worth running Diagnostics to check its own hardware isn’t developing a fault. Kernel panics are a common early sign of failing memory or storage, as well as other faults in the logic board. If you’re not reassured that all is well, don’t hesitate to get your nearest Apple store or authorised service provider to run their more advanced diagnostics as well.
Panics can also be associated with peripherals such as USB and Thunderbolt docks and hubs. The best way to diagnose this is by running your Mac without the suspect hardware connected, and seeing if panics continue. If they do, and you remembered to save panic reports, even if you don’t understand their details you can still compare them to see if they look similar.
Third-party kernel extensions are normally found in /Library/Extensions, and should be uninstalled using the apps that installed them. Most are only loaded on demand, so the mere presence of an extension there isn’t sufficient evidence to convict it of causing the panics. However, you should become suspicious when a third-party extension is named in the Panic Log as being part of the chain that may have caused it. Most software that used to rely on kernel extensions has now been updated to use system extensions or another modern replacement, so updating old software could solve the problem.
The most difficult time for a kernel panic to occur is during startup. Because the kernel panic causes the Mac to restart only to encounter the same problem that caused the panic, your Mac is likely to cycle through restarting, panicking, and restarting again. If this happens, don’t wait to see if the problem will fix itself: press and hold the Power button until you force your Mac to shut down, then work out what to do to avoid further boot-looping.
Thankfully, boot loops are very rare. With an Apple silicon model, the best plan is to try starting up in Recovery mode, often a wise move for Intel models too. You can then try to work out what the problem is, and how best to tackle it. If the panics follow a recent attempt to update or upgrade macOS, they could be the result of an incomplete or failed firmware update; resolving that depends on the architecture of that Mac. Boot loops caused by hardware can often be resolved by reconnecting or disconnecting the offending peripheral.
A boot loop is a good reason for contacting Apple Support, or another source of expert help.
Reading Panic Logs
- 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 if necessary ask Apple Support for their help.
- Consider running hardware Diagnostics to check for a fault.
- Try running without third-party peripherals in case they are responsible.
- Uninstall suspect third-party kernel extensions.
- Don’t panic!