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.
When running on your Mac, macOS (or OS X) has protected areas, including 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’s then likely to be a period during which the app’s developers blame Apple, Apple says little, and eventually the problem gets resolved.
When an app unexpectedly quits, 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 used to keep all 1600+ old articles in it, it often took 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 in red 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 clean 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.
macOS Sierra has a much more robust kernel than El Capitan, but sometimes it seems to be struggling for survival. This occurred more commonly in its initial releases (10.12 and 10.12.1), and has gradually gone away. When this occurred, it was like your Mac trying to run through treacle: the clock could stop for twenty or thirty seconds or longer, everything on the screen froze, and sometimes even the pointer wouldn’t move. Given a bit of time, it could break out of this and get back to running normally – and at least it didn’t panic, even if the user was starting to.
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. In the classical form (OS X 10.7 and earlier), the whole screen of the Mac becomes greyed, and a multilingual message informs you that macOS has encountered a fault and needs to restart: this is a kernel panic.
From OS X 10.8 on, this behaviour has changed and you may not even be informed of the kernel panic. Instead, your Mac might just freeze for a minute or so, then spontaneously restart, or just shut down altogether. Unless you have told it to restart or shut down, that can only be the result of a kernel panic.
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. You can learn more about how to recognise and deal with a kernel panic here.
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, nor to restart promptly. 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 Magic 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, later 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 was only properly fixed with the new kernel delivered in macOS Sierra, which is for most users much more robust.
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. In El Capitan and earlier, you can browse those using Console, but Sierra introduces a new logging system and Console is of very limited value. If you’re running Sierra, you should take a look at my free Consolation, available from the Downloads item above. More details are given here.
Every log entry 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.