Using the correct term to describe unexpected events when they occur on your Mac is central to troubleshooting. Vague words like crash could mean anything from a full-blown kernel panic bringing your Mac to its knees, to an app showing an error message and quitting quietly. Before you can start thinking of causes or remedies, it’s essential to distinguish these main types:

• A kernel panic is when macOS can’t continue running any more due to software damage, and your Mac has to restart itself to resume normal services.
• A freeze is when the error is severe enough to prevent a normal, ordered kernel panic, and you have to force your Mac to shut down by pressing the Power button.
• An app crash is when an app suddenly quits without warning, but doesn’t take down macOS or trigger a kernel panic.
• An unresponsive app shows the spinning beachball and is listed in the Force Quit dialog as not responding.

Kernel panic

The kernel runs at a special level of privilege to isolate it from the chaos that may be going on in userland. Apps should be able to come and go, crashing whenever they need, but the kernel and its extensions should continue running unaffected. There are three particular risks that the kernel is exposed to:

• hardware (and device firmware) failure or error,
• kernel extensions,
• problems occurring in the Secure Enclave.

Hardware failure, whether it’s a sick GPU, wobbly memory, or a failing disk, can cause kernel panics and may be a good reason for running Diagnostics after your Mac has suffered a kernel panic.

The kernel requires a great many extensions in order for it to do anything useful: macOS Tahoe currently ships with around 945 as standard. Third-party kernel extensions have been common in the past, but now should have largely been replaced by system extensions and their relatives. Although the kernel is better isolated from those, that doesn’t always work reliably. As a result, kernel panics should now be rare in Apple silicon Macs, which have to be run at reduced security if they’re to load third-party kernel extensions.

Secure enclave panics are a recent phenomenon, can only occur in Macs with T1, T2 or Apple silicon chips, and should be extremely rare.

Because of the seriousness of kernel panics, they should generate a special panic log, the starting point for discovering why any panic has occurred. A minute or so after logging back into your Mac once it has restarted, you should see a panic alert with the offer to view its report. Without a panic log, it’s almost impossible to obtain any useful evidence as to their cause, as the panic usually ensures that all other log records are lost. Unfortunately, recent versions of macOS don’t make it easy to save the panic log, and many users just send a copy to Apple assuming that will do something to solve their panics, which it doesn’t. When you see a panic alert, always view the report, copy and paste it into a document, and save it for reference.

Freeze

It’s also possible for a Mac to come to a grinding halt, and rather than suffering a kernel panic, just freeze. You can experience something similar if you run Disk Utility’s First Aid on your Mac’s Data volume when running in normal mode: the contents of the display and clock stop updating, and the Mac is completely unresponsive to any input. When running First Aid, that should only last a few seconds; when your Mac freezes, it may recover spontaneously, but in many cases the only way to regain control is to force it to shut down by pressing and holding the Power button. Whatever you do, only shut mains power off to your Mac as a last resort, as that risks damage to file systems and loss of data.

Freezes can also occur through a different mechanism: rather than a fatal error in the kernel causing it to panic, a freeze may originate from WindowServer and the GPU, hence failure to update the display.

App crash

These are known under various euphemisms such as an unexpected quit, and come in two main forms. They most commonly result when an app encounters a problem it can’t solve, for instance if it’s expecting to find a chunk of data in memory, but instead there’s nothing, and its code can’t handle that gracefully. These should be reported to the developer so they can identify the problem and modify the app’s code to prevent the crash from occurring. For the user it may be possible to determine the circumstances that cause the crash, and work around them.

macOS itself will deliberately crash apps in certain circumstances, such as when its security system finds a broken signature, or the app tries to access something protected for privacy without having the right of access. While diagnosing bugs in apps is generally beyond the ability of even advanced users, an app’s crash report should reveal external causes such as a security failure, which are of importance to both user and developer.

Unresponsive app

Apps are generally written so that activities that might take noticeable time are run in the background and don’t impair the app’s responsiveness to the user. There are circumstances where that smooth running doesn’t work, and the spinning beachball cursor is displayed to indicate the app is no longer responsive.

This doesn’t mean that the app has crashed, and for certain operations it can be difficult if not impossible to avoid. For example, it’s possible to obtain log extracts containing hundreds of thousands of entries using Ulbow. When there are so many, formatting their text in the app’s window takes noticeable time and will inevitably result in pauses spent with the spinning beachball.

Apps can also enter more prolonged periods of unresponsiveness, sometimes indefinite, from which the only way out is to force them to quit using the Finder’s Force Quit window (Command-Option-Escape), actually handled for it by loginwindow. macOS writes special logs to record these problems, but they are of no benefit to the user.

Unexpected behaviour

Apps including the Finder can behave in many ways you don’t expect, as Pulp newsreader did when it first ran in macOS Catalina, above. In these cases it’s most useful to distinguish between problems that render the app unusable or result in data loss, and those that have lesser consequences and can possibly be worked around.

Key points

• A Mac restarts spontaneously following a kernel panic; watch for the panic log and save a copy.
• When everything stops dead, particularly on the display, the Mac has frozen and normally needs to be shut down by holding the Power button.
• When an app unexpectedly quits it has crashed, or has been crashed by macOS.
• A prolonged spinning beachball cursor is an unresponsive app, and may need to be forced to quit.