When your Mac goes wrong, it’s often called a ‘crash’. That’s a succinct term, but not very useful when you come to work out what went wrong and how to fix it. By understanding what happened, and what exactly that ‘crash’ was, we get important clues as to what to do next.

This article covers the following behaviours:

• when an app unexpectedly quits, often leaving you with an alert or crash report window;
• when an app becomes unresponsive to user control and displays a pointer resembling a multi-coloured spinning beachball;
• when the display freezes for several seconds, then becomes fully responsive again; this is normally when WindowServer crashes, and worst cases can require you to log in again;
• when your Mac spontaneously restarts, or shuts down of its own accord, because of a kernel panic;
• when the display freezes and nothing further happens.

Unexpected quit

macOS has protected areas, including the kernel itself, which apps shouldn’t be able to affect. Each app runs in its own separate space, kept apart from other apps, and from protected system space. So the most common type of ‘crash’ should be one app biting the dust 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 many reasons, but the most frequent are bugs in that app. If an app consistently quits unexpectedly when you try doing the same thing, you can be fairly confident that it’s a bug in that app, and should report that to the app’s developers. Of course this isn’t 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 is quietly 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 to macOS, files in storage, or elsewhere. So although you should be safe to continue working, and reopen the app which quit, be aware of any signs of odd behaviour indicating residual damage. Restarting your Mac normally clears that.

There are also several reasons for macOS forcing your app to quit suddenly. If this happens when the app is trying to start up, for example, it could be because there is a signature error, it tried to access privacy-protected resources to which it wasn’t entitled, or a problem with the app’s code or files. Unfortunately, in most cases – whether it quit of its own accord, or was forced to by macOS – all you will see is a crash report, which may invite you to re-open the app, or to send the report to Apple.

Reading crash reports is a specialised business, and normally needs insight into the workings of both macOS and the app which quit. If you have the option to send the report to Apple or the developer, please do so, as that may mean its developer gets a chance to see it. If you want to understand crash reports, this old Technical Note explains them, and there’s a whole session from WWDC 2018 devoted to the subject.

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 that. This might be because you have asked the app to undertake something huge: most apps aim to put long-running tasks into a background process and show a busy spinner or progress bar, but that isn’t always possible. So long as the beachball doesn’t appear for too long, you should let the app sort itself out.

Spinning beachballs aren’t themselves a reliable indication that an app is in distress: their meaning is simply that the foreground app is too busy processing to interact with the user at present. In many circumstances, this is quite benign, and the app is just busy doing what you wanted it to.

Sometimes an app appears unable to recover from the spinning beachball, and just hangs, unresponsive, eating up CPU cycles and getting nowhere. You should be able to force that app to quit, so you can open it again and try a different approach. To do that, 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.

When you force quit an app, and sometimes on other occasions, macOS may automatically generate a ‘spindump’ report; it also generates ‘microstackshot’ reports when there are performance issues. Interpreting these is unfortunately only really possible if you understand how the app works and what it was doing at the time.

Recurrent spinning beachballs in different apps and the Finder are a good indication of more general problems with macOS rather than those apps. These are most commonly encountered when you’ve just upgraded or updated macOS, and suggest a failed update, or a serious internal clash, perhaps with some incompatible third-party product.

One potential solution is to start up in Safe mode (with the Shift key held), leave your Mac for a minute or two, then restart back into normal mode. If that doesn’t fix it, try downloading and installing the latest Combo update, or re-installing that version of macOS, perhaps in Recovery mode. Third-party extensions and other lower-level software are disabled in Safe mode, so you should find the beachballs disappear in that mode. However, a lot of Apple extensions are also disabled, and you may be unable to run many of your apps at all.

WindowServer crash

WindowServer (or Window Server, with a space) is a key part of the GUI which sits between every app’s windows and the graphics hardware. It’s WindowsServer’s job to assemble all windows into a composite, which is then sent to the graphics system via its driver. It also works out which window clicks or taps occur on, and passes those actions to the correct app for it to handle.

Being in the middle, WindowServer is vulnerable to bugs in apps, and to problems in the graphics system such as an unresponsive GPU. When WindowsServer crashes, the screen freezes, normally including any system clock. If macOS is able to restart WindowServer and the graphics hardware is still running normally, all you may notice is that freeze for a period of seconds, until WindowServer is up and running again, when it may process some of the backlog of clicks/taps. If that’s all that happens, everything should continue normally again.

In worse cases, the GPU may crash or become unresponsive, so restarting WindowServer isn’t sufficient to restore normal function. This can lead to the Mac restarting, perhaps as a result of a propagated kernel panic, or the current user being logged out, the GPU being recovered, WindowServer restarting, and the user having to log back in. In the latter case, it’s probably wisest to restart your Mac when it’s next convenient, but it may run perfectly well without that. Further details, including log extracts which help you make this diagnosis, are in this article.

Frequent or recurrent WindowServer crashes should suggest bugs in the graphics driver, in a causative app, or an incipient fault in the GPU itself.

Kernel panic

Early releases of macOS often didn’t 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 its classic 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 probably won’t 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. Panics are also associated with firmware problems, which are discussed here.

Freeze

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 such 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 doesn’t, 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, to both its software and possibly its hardware.

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. Freezes are also widely reported on some models with certain versions of firmware.

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 more unusual to crash when going to sleep, but that is another helpful indicator which can help narrow down the cause. This article looks in more detail at those problems.

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 introduced a new logging system and Console is now of very limited value. If you’re running Sierra or later, you should take a look at my free Ulbow or Consolation, available from their product page, which contains links to many articles about using them.

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 at genius@macformat.com