Diagnosing problems: crash, freeze, panic, or spinning beachball?

A kernel panic. It is an interesting exercise to get your own screen shot of one.

When something untoward happens to a computer, we often refer to it as a ‘crash’. That’s a succinct term, but not a very useful one. By understanding what happened, and what exactly that ‘crash’ was, we get very important clues as to what to do next.

Unexpected quit

When running on your Mac, macOS (or OS X) has protected areas, which includes the kernel itself, which apps should not be able to affect. Each app then runs in its own space, which should be kept separate from other apps, and from the protected system space. So the most common type of ‘crash’ should be one app taking a nose-dive when it has done something wrong. This normally results in that app suddenly quitting, so is most often termed an unexpected quit.

Unexpected quits can happen for a lot of reasons, but the most frequent are bugs in that app. If an app consistently quits unexpectedly when you try to do the same thing, then you can be fairly confident that it is a bug in that app, and should report that to the app’s developers. Of course this is not necessarily a matter of blame: many of these bugs occur when the app expects macOS to do something one way, and it doesn’t. There often follows a time when the app’s developers blame Apple, Apple says little, and eventually the problem gets resolved.

When an unexpected quit occurs, macOS and all your other running apps should be unaffected, but sometimes the app, when on its way out, leaves some damage in macOS, files on your drive, or elsewhere. So although you should be safe to work on, and restart the app which quit, be aware that other signs of odd behaviour may indicate more extensive damage. Restarting your Mac normally clears that.

Spinning beachball, or hang

More common than unexpected quits are spinning beachballs. These are occasions when an app hits a problem, and displays the spinning beachball pointer to indicate that it is working on the problem. This might be because you have asked the app to do more than it was expecting: I use MarsEdit to write and maintain this blog, but because I keep all 1600+ old articles in it, it often takes a few moments longer to do certain things. So long as the beachball doesn’t appear for too long, you should let the app sort itself out.


Sometimes an app appears unable to recover from the spinning beachball, and just hangs, unresponsive, eating up CPU cycles and getting nowhere. You may be able to force that app to quit and restart. To do that, click on another app’s window or use the Dock to switch to a different app, and press Command-Option-Escape to bring up the Force Quit dialog. Select the app which has hung, which is usually marked as not responding, then click on the Force Quit button. The app will then be shut down, and you can start it up again when you want to use it.

This should clear up properly after you have forced the app to quit, but as with unexpected quits, it sometimes leaves macOS and other apps in an unstable situation, requiring a restart.

Kernel panic

Early releases of macOS often did not protect the kernel and other central parts of the system well enough, and a bad bug in an app could bring the whole system tumbling down. This is now more likely to occur as a result of a hardware fault, such as a problem in memory, or a sudden failure of a disk. The whole screen of the Mac become greyed, and a multilingual message informs you that macOS has encountered a fault and needs to restart: this is a kernel panic.

A kernel panic. It is an interesting exercise to get your own screen shot of one.

If your Mac has a kernel panic, it must restart and load macOS from scratch. The kernel has suffered so much damage that it cannot recover in any other way. These days, the first thing that you should do after a kernel panic is to check your memory thoroughly using a specialised tool such as ATOMIC, and check each of your drives using Disk Utility or something better like DriveDx. Only when you are confident that your hardware is sound should you look any further for the cause.


When the macOS kernel and central parts of the system collapse completely, they may be unable to continue long enough to even warn you with a kernel panic. Instead, your Mac just stops dead in the water: the clock stops, you cannot navigate windows, indeed normally you cannot even move the pointer. An interesting symptom which may alert you to a freeze is that an Apple TrackPad 2 – which is software-driven – loses its ability to click at all, and feels ‘dead’.

If you encounter a freeze, leave your Mac for a minute or two, as it is likely to restart automatically. If it does not, then you should press and hold the Power button until you have forced it to shut down, wait a few seconds, then start it up again. Never disconnect or turn off the mains power supply, except in a dire emergency, as that runs a high risk of causing permanent damage to your Mac.

Like kernel panics, you should only see a freeze if you have a hardware problem. However recent versions of El Capitan (10.11.4 and later) are known for causing repeated sporadic freezing on certain models of Mac, including some iMacs and MacBook Pros. This is probably the result of a bug in the kernel itself, or low down in system software extensions or drivers, and we hope will be fixed in 10.11.6.

Problems associated with specific events

Crashing which occurs during startup can be particularly difficult, especially if it stops your Mac from booting up fully. Severe problems leaving your Mac with a uniform coloured screen – typically black or blue – usually indicate hardware failure, such as a defective graphics card. Lesser problems are often worked through by restarting in Safe mode, with the Shift key held down; this disables most third-party software, and can allow you to work out what is clashing and deal with it.

Another critical moment for problems to occur is when waking up from sleep. This normally requires macOS to reactivate hardware and it may need to load up drivers and other low-level software. It can precipitate any of the above types of crash. It is much more unusual to crash when going to sleep, but that is another helpful indicator which can help narrow down the cause.

The most important clues of all

Most of the above events are recorded with detailed information in your Mac’s logs, which you can browse using Console. Every entry there is accompanied by a time and date stamp. It is simple to correlate the time (shown on your Mac’s clock) with an event, and its record in the logs. Although at first sight log entries seem very technical and written in Martian, a little study quickly gives important clues which will help you work out what went wrong.

Log entries are also invaluable when you ask others to help, whether Apple Support, or by sending a question to an expert via a service such as MacFormat’s Genius Tips.