No crash or panic should ever happen, kernel panics least of all. What happens in a kernel panic is so seriously damaging to the macOS kernel that it simply can’t recover, so forces your Mac to restart (or, sometimes, to shut down). This article describes how to recognise and diagnose kernel panics, and what you should do about them.

Recognition

Kernel panics follow one of two patterns, depending on when they occur:

• When a panic occurs after logging in, the Mac freezes, displays a black screen, then restarts (or, sometimes, just shuts down).
• When a panic occurs during startup, that startup can’t continue, so after a black screen the Mac tries to start up again. That normally results in another panic, so it continues to restart and panic in a loop.

It’s essential not to call this a ‘crash’. Crash is a general term which obscures the severity of a panic. A crash can be as simple as an app unexpectedly quitting, while a panic is highly disruptive and should never happen.

Immediate action

Within a minute or so of successfully restarting, the Mac should display a panic log in a window, inviting you to send that log to Apple. Don’t do anything yet: open a new document in TextEdit or another text editor, select the entire contents of the panic log (Command-A), copy it (Command-C) and paste it into that text document. Save that as your record of the event, then please send the panic log to Apple as requested.

Apple will not respond to your log. Panic logs are collected and analysed automatically, and don’t reach Apple Support. Unless you contact Apple Support yourself, you will hear nothing more about that panic.

Study the panic log for clues

Although the panic log may look overwhelming and cryptic, it’s easy to gain most important clues from it.

At the very top, following the first word panic, the log may suggest a cause. This is most common when a memory leak is the cause:
panic(cpu 8 caller 0xffffff80017729eb): "zalloc: zone map exhausted while allocating from zone kalloc.12288, likely due to memory leak in zone kalloc.48 (6586956000 total bytes, 137228148 elements allocated)"@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-6153.141.1/osfmk/kern/zalloc.c:3627

In other cases, you may not as lucky, and the cause is just given as an ‘exception’, or
cannot find IOAESAccelerator
so you’ll need to look for other clues. As the name implies, exceptions are conditions which require special handling by the operating system. They include page faults, in which something has tried to access an invalid memory address, invalid instruction codes for the processor, and general protection faults which include a wide variety of other bugs. As far as the user is concerned, all exceptions indicate a bug or problem in the code that’s being run.

If there’s been a memory leak, the panic log may well contain a breakdown of system memory zones, which can give more detailed clues.
Zone Name Cur Size Free Size
vm objects 78041088 26795008
…
Zone Name Cur Size Free Size
kalloc.32 280834048 3040
kalloc.48 6586956000 4896
kalloc.64 4241453056 5000896
…
Note how the Free Sizes of kalloc.32 and kalloc.48 are very small, and that of kalloc.64 is fairly low too. This is consistent with the kernel running out of memory in one of those zones. Further information may follow:
Backtrace suspected of leaking: (outstanding bytes: 288)
…
Because there’s the suspicion of memory leakage, the panic log also gives a detailed backtrace of where it suspects that leakage is occurring, and details of the kexts involved in that. Note that those are unlikely to coincide with any kexts identified earlier as possible culprits.
Kernel Extensions in backtrace:
com.apple.filesystems.apfs(1412.141.1)[6DA33D13-4501-3D48-B4D8-0329E6AEC86D]@0xffffff7f84e7d000->0xffffff7f84fa4fff
dependency: com.apple.kec.corecrypto(1.0)[804DD660-F561-3444-A076-05D7A52D65E3]@0xffffff7f82746000
…

Whatever the cause, you should next look at the list of unloaded and loaded kexts which forms the rest of the panic log. These are listed in the order that they were loaded, with the most recent kext at the top. As third-party kexts are the last to be loaded, the top of the lists start with any third-party kexts installed on that system (and loaded at the time of the panic).
last loaded kext at 939128480512562: >!UAudio 323.4 (addr 0xffffff7f86baa000, size 434176)
last unloaded kext at 948795488738566: >usb.IOUSBHostHIDDevice 1.2 (addr 0xffffff7f8556c000, size 45056)
loaded kexts:
>!ATopCaseHIDEventDriver 3430.1
…

If those lists contain any third-party kexts, they should be immediately suspected as being the cause of that panic, unless another cause is obvious.

I give a fuller account of reading a panic log in this article.

Follow-up

Commonest causes of kernel panics include:

• Hardware – check all connected peripherals thoroughly, including their cables and security of their connections. It’s wise to run your Mac’s diagnostics to confirm that there’s no obvious hardware fault responsible.
• Third-party kernel extensions – if any are listed as being loaded at the time of the panic, uninstall them if possible. If your Mac then stops panicking, you know the cause.
• Wake from sleep – this is a critical time for macOS, when extensions may need to be reloaded, and a common time for panics to occur. They may be related to peripherals which have also been asleep, but are accessed again during wakening, which can cause the panic.
• Firmware – incompatible or buggy firmware can make itself known through panics, often during startup and resulting in a boot loop.
• WindowServer-GPU crashes – these normally don’t progress as far as a kernel panic, but can do when they’re severe enough. The panic is then normally preceded by a long display freeze.

If you suspect a panic has occurred as a result of a problem in macOS, such as an incompatible (Apple) kernel extension, or a memory leak, please contact Apple and provide your copy of the panic log. Apple is normally very responsive and concerned to fix panics resulting from its own software.

Further details of recent panics and their diagnosis include:
Dealing with a kernel panic during M1 startup
How a kernel zone memory leak can panic macOS
WindowServer-GPU crash: different from a kernel panic

Summary

Kernel panics are serious and should never occur.
They normally precede a spontaneous restart, or can cause recurrent booting if they occur during startup.
Copy, paste and save the panic log displayed following restart.
The panic log often gives obvious clues as to the cause.
Check hardware thoroughly, and uninstall all third-party kernel extensions you can.
If the panic appears to be a problem with macOS, report it individually to Apple, either through Feedback, or to Apple Support.
Don’t panic!