Choosing and using the correct term for unexpected events occurring on your Mac is central to troubleshooting them. A crash could mean anything from a full-blown kernel panic that brings your Mac to its knees, to an app showing an error message and quitting quietly. Before we even start thinking of causes or remedies, it’s essential that we 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 in order to resume normal services.
• A freeze is when the error is enough to prevent even 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 that was running suddenly quits without warning, but that doesn’t take down macOS or trigger a kernel panic.
• An unresponsive app is one that shows the spinning beachball and is listed in the Force Quit dialog as not responding.

Here I’ll outline each in turn, then deal with them in detail in further articles.

Kernel panic

The kernel runs at a special level of privilege, which should 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 two particular risks that the kernel is exposed to:

• hardware (and device firmware) failure or error,
• kernel extensions.

Hardware failure, whether it’s an ailing GPU, wobbly memory, or a failing disk, can cause kernel panics and is often a good reason for running Diagnostics if your Mac suffers a kernel panic. Apple silicon Macs have also had a track record of panics associated with certain models of Thunderbolt or USB 3 dock; disconnecting the peripheral can then stop those panics.

The kernel requires a great many extensions in order for it to do anything useful: macOS Ventura currently ships with around 600 as standard. In the past those have been augmented by third-parties, many of which have proved to be causes of kernel panics. These are being progressively replaced with system extensions and their relatives, and Apple silicon Macs in particular shouldn’t need third-party kernel extensions. On Apple silicon Macs they can only be used when Startup Security policy has been reduced and their loading has been explicitly enabled. There are no such restrictions for Intel models, though.

Because of the seriousness of kernel panics, they should generate a special panic log, the starting point for discovering why any panic has occurred. Without a panic log, it’s extremely difficult 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.

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, although it seems like an age at the time; 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.

Freezes can occur through a different mechanism: rather than a fatal error for the kernel causing it to panic, a freeze may originate from WindowServer and the GPU, hence the failure to update the display. If they don’t end in a panic with its log, there’s a greater chance of clues being found in the Unified log.

App crash

These have been 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. 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 always work, and the spinning beachball cursor is displayed to indicate that 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 dialog (actually handled for it by loginwindow). macOS writes special logs to record these problems, but they are of little or no use to the user.

What next

Having decided what type of event has happened, you are now well on the way to working out how to tackle it, using a more specific guide.