In a kernel panic, something happens in your Mac which is so injurious to the kernel code running at its heart, that the kernel has to be halted: it then issues a panic.

Panics used to be quite common in early versions of Mac OS X, and had become very infrequent by Yosemite (10.10), unless your Mac had a hardware problem. Defective memory has always been a likely cause, although panics can be the result of a serious disk fault, or any other failing hardware. Since then, different models have been prone to panic with different versions of macOS, and different firmware versions. Most recently, they have probably been most common when firmware hasn’t been fully compatible with basic features like waking from sleep.

Current likely causes of kernel panics include:

• firmware bugs, damaged firmware, particular when waking from sleep and performing other fundamental tasks;
• serious bugs in macOS, including its kernel extensions and other low-level code;
• incompatible third-party kernel extensions and other low-level components;
• hardware failure, especially memory, storage or logic board.

When a regular user app crashes or ‘unexpectedly quits’, this should never result in a kernel panic, although if the cause is low-enough down in the software it can on occasion.

Over various releases of OS X and macOS, Apple has also changed the way in which kernel panics are handled. Prior to OS X 10.8, they were usually marked by the display of a special panic screen, shown below.

If you ever see this, the only way ahead is to press and hold the power button of your Mac, which will force it to shut down. After a few seconds, you can press that button more briefly to start it up again.

Since 10.8, as documented in Wikipedia’s excellent potted history of kernel panics in OS X, Macs have behaved differently: they automagically restart themselves, sometimes displaying a kernel panic dialog when next starting up, for “a few seconds”. If your luck has really run out and there are five more kernel panics within three minutes of the first, a prohibitory sign should be shown on the display for thirty seconds, and the Mac shuts down and doesn’t attempt to restart again: that’s a ‘recurring kernel panic’, or more like a whole monthful of Friday 13ths.

Apple’s account of these issues is now quite different. They’re not kernel panics any more, but unexpected restarts, which makes them seem as innocuous as unexpected quits, perhaps; they’re not – no Mac should ever experience a single panic.

From El Capitan to Catalina, you’re unlikely to see any of the informative dialogs which Apple shows in that article. Chances are that your Mac will freeze for a while, restart, then hopefully re-open all the apps and windows just as they were when the panic occurred, and you might be none the wiser of the event. Instead of forcing a restart, some older models may simply shut down, leaving you to start them up again in the usual way.

When your Mac has restarted after a kernel panic, it normally saves a ‘backtrace’ of the event. Initially, because of the nature of the panic, this is saved to the NVRAM, but one of the jobs carried out during the restart should be to write that out to a .panic file. These are normally written to /Library/Logs/DiagnosticReports, from where you can browse them using the Console app in /Applications/Utilities. This might have changed, though, in Catalina: Console there no longer lists log folders as such, but lists them by type.

Panic files should be named something like Kernel_<date and time>_<machine name>.panic. If you can’t find one, it might still be held in NVRAM, in which case you can view it using the Terminal command
nvram -p or nvram -xp

Interpreting panic files or logs isn’t easy, although sometimes they give a good clue as to what went wrong. Apple provides more information in Technical Note TN2063, Understanding and Debugging Kernel Panics, although that has not been updated for over five years, and is no longer an accurate reflection of what happens in any recent version of macOS. However, I can’t find any more up to date account from Apple.

Apple’s documentation also doesn’t cover the worst type of kernel panic of all: one which occurs early during startup. In that case, if the panic forces a restart, your Mac can become locked in a cycle of panics and forced restarts which can only be broken by your intervention. These have occurred when there is significant hardware failure (memory again), the firmware has become damaged perhaps by a failed update (it has occurred in models with the T1 chip following firmware update), or storage is damaged or failing, particularly if it hosts the startup volume.

If your Mac starts cycling through these, press and hold the Power button to force it to shut down, then cross your fingers. Recovery from a failed firmware update is quite complex, and details are given here.

Because your first kernel panic is quite likely to result from a hardware problem, disconnect all non-essential peripherals apart from any network connection, any displays, the keyboard and mouse/trackpad, then start up in Diagnostics or Hardware Test.

If you’re confident that hardware is not the cause, consider starting up in Recovery mode, running Disk Utility, and applying First Aid to your startup disk. This can fix any corruption which might have occurred during the panic, although that should be much less likely to occur in APFS than HFS+.

It is also worth considering starting up in Safe mode, which should prevent any third-party kernel extensions and similar components from loading. This could provide the opportunity to check for those, and remove them if necessary.

If you have other diagnostic software, such as TechTool Pro or EtreCheck, you may find that they can identify the most likely cause, so that you can deal with it.

A kernel panic which has occurred soon after a macOS software update may well be the result of a problem with that update, and is considered in this article. If you can’t fix it by installing the standalone or Combo update, it’s worth re-installing macOS, which is examined in detail here.

Sometimes, the problem causing a kernel panic can be fixed by performing an SMC or NVRAM reset, which is detailed here.

If you cannot find a cause, and your Mac continues to suffer occasional kernel panics, then do not become complacent and just accept them: it should not do that, you need to get to the bottom of the problem, and fix it. You may even find it helpful to contact Apple Support. This is particularly true for problems with firmware updates, and new versions of macOS. Even if they can’t fix your problem, at least Apple is then aware of it.