For at least the last decade you’ve been able to discover why a Mac last shut down by finding the cause code written in its log. Last week I finally got round to updating the old information given here about how to read that shutdown cause code in the log. It wasn’t a feature that I’d looked at yet in Apple silicon Macs, where I was disappointed to find no trace of them.

The explanation for this difference from Intel Macs hinges on understanding the origin of those cause codes, as revealed in the log. They come from the System Management Controller, according to their log entry with AppleSMC as the senderImagePath, in Unified log terminology. As it’s responsible for managing Intel Mac hardware, it makes good sense that it should keep track of events such as shutdown and sleep, and have a good idea of why they should have happened. It has thus been puzzling that all those years Apple has never seen fit to acknowledge the existence of the SMC’s cause codes and provide a list of them.

One of the more subtle changes in Apple silicon chips is that they use completely different SMCs, embedded within the chip itself. While I’m sure they too know what’s going on with such major system events, they don’t appear to breathe a word about them in the log. Despite searching through log entries from and about these new SMCs, nowhere did they mention the cause of the last shutdown, even by giving an inscrutable code.

Looking in the most obvious places, such as System Information and NVRAM, drew a blank. Instead, by comparing logs between restarts following a kernel panic in a Virtual Machine with those from normal boots of the host Mac, I was able to discover signs of whether a panic had been responsible for that restart:

• Look for /var/db/com.apple.DumpPanic.panicLogPathBreadcrumb. If that file exists, drag-copy it to your Documents folder and open it with a text or property list editor. It should contain a single dictionary, with a UUID key and a string. If that’s empty, there’s no panic log, otherwise it may give you a further clue as to where the log might have been saved.
• Look for the word paniclog in the eventMessage field for log entries in the minute or two after the Mac restarts. If that extract reads failed to map memory for paniclog output - 0x3 then there’s likely to be a panic log somewhere.
• Browse log entries from the subsystem com.apple.DumpPanic in the minute or so after startup. That subsystem handles generation of the panic log, makes it clear whether there is one, and even reveals its opening line.

While those should be useful for determining whether the last shutdown and subsequent restart were the result of a kernel panic, they still won’t tell you the cause of other shutdowns, for example because of power or other hardware problems.

Since then I have been following another lead, this time in the information provided by sysctl. Although that can be complicated to obtain from the command line, there’s easy access offered in Mints. What I don’t know yet is how consistent or reliable those entries are in Apple silicon Macs, but after a normal shutdown and Power button startup they read:
kern.bootreason: pwrbtn
kern.shutdownreason: wdog,reset_in_1 rst_in,reset_in_1_deassert target_off_restart ap_shutdown

My panic-to-order Virtual Machine doesn’t offer such useful information in sysctl, probably because it only has a virtual SMC.

Another line might have been to read the SMC’s own log using
pmset -g log
or in the Logs item in System Information. Although that provides lots of undoubtedly fascinating information about what it’s up to, there seems to be nothing about reasons for shutdown or startup.

For the time being, at least, Apple silicon Macs don’t seem to provide any equivalent to the shutdown cause code found in the log of Intel Macs. Perhaps it’s time to file a Feedback request for the return of the lost cause code, or would that in itself be a lost cause?

One of the most unnerving experiences with a Mac is to discover that it has either restarted and is waiting for you to log in, or has shut itself down completely. This article explains what might have happened, and how you can distinguish between those causes.

Power failure

The commonest single cause for these events is loss of power to the Mac’s internals, which could mean anything from the mains power supply or internal battery through to the Mac’s power supply unit (PSU). Even if your Mac is up and running fine again, and supplied by an uninterruptible power supply (UPS), confirm that there hasn’t been a power glitch. Any good UPS should keep an event log that you can check to see whether there was anything untoward.

Intermittent PSU faults are rarer but can be tricky to diagnose, and hardware diagnostics may fail to pick them up. If you don’t have any evidence that anything went wrong with power supply, put it to the bottom of the list for the moment. However, if you suspect your Mac’s PSU might be defective in any way, don’t use it again until a trained Apple technician has checked it carefully and assured you that it’s safe. Mains power still kills many people, including those who should know better.

Other hardware faults

There’s a long list of other hardware causes, from a defective system management controller (SMC) to faulty memory. If your Mac is getting long in the tooth or has shown other signs suggesting it might have a hardware problem, now is the time to run hardware diagnostics to check. But if it has been working fine, move this lower down in your list, to return to later if other causes aren’t evident.

Kernel panic

macOS is designed to keep its kernel running through thick and thin, even when apps are crashing all around it. Sometimes, though, the most robust of kernels can reach a point of no return, and it should then panic, allowing the Mac to restart (or in some older Macs, shut down) and try again. That’s a better option than everything grinding to a halt in a ‘freeze’, when you have to force the Mac to shut down by pressing and holding the Power button, which may not result in production of a panic log.

Shortly after starting up following a kernel panic, you should be offered the panic log, as I’ve described elsewhere. But what do you do if you think it might have been a panic but don’t see any dialog offering a log? Your next move depends on whether it’s an Apple silicon Mac or an Intel model.

Intel: cause codes

When an Intel Mac starts up (including following a restart) or wakes from sleep, the reason for the previous shutdown (or initiation of a restart) or sleep should be reported in the log as a cause code. In El Capitan and earlier versions of OS X, you can find recent cause codes in the logs using Console: search for shutdown cause, or sleep cause when looking for a wake event instead. From Sierra onwards, you’ll need to check the unified log; in macOS 14.6 and later, that’s simplest using LogUI. Set its Predicate menu to read eventMessage, and enter shutdown cause in the text box to the right. Ensure the time period includes the first few seconds of the boot or reboot, and you should then be presented with an entry similar to:
2025-04-16 19:48:55.630+0100 kernel Previous shutdown cause: 5

Negative cause codes refer to hardware causes originating mainly from the SMC, and positive codes refer to software. A special code of 0 indicates an intermediate, which can occur when there’s sudden loss of power on some systems.

Among the hardware cause codes, the following are notable:

• -3 multiple temperature sensors too high
• -61, -62 unresponsive app resulting in forced shutdown
• -64 kernel panic
• -71 memory too hot
• -74 battery too hot
• -75 MagSafe power adaptor communication problem
• -78 incorrect input current from power adaptor
• -79 incorrect current from battery
• -86, -95 proximity temperature (heatsink etc.) too high
• -100 power supply too hot
• -101 display too hot
• -103 battery voltage too low
• -104 unknown battery fault
• -127 PMU/SMC forced shutdown for another cause

In the software cause codes, there seem to be only two that occur commonly:

• 3 is a ‘dirty’ shutdown resulting from a forced restart or shutdown
• 5 is a ‘clean’ shutdown initiated by the user.

You can find a more detailed list on George Garside’s blog. However, these don’t appear to be given for Apple silicon Macs, and even Intel models don’t seem as reliable at writing them to the log now.

Apple silicon: hunt the panic

Although you can try finding a log entry giving a cause code, I’ve not been successful yet on an Apple silicon Mac, where you have to look for other clues as to whether the cause was a kernel panic. Those include:

• Look for /var/db/com.apple.DumpPanic.panicLogPathBreadcrumb. If that file exists, drag-copy it to your Documents folder and open it with a text or property list editor. It should contain a single dictionary, with a UUID key and a string. If that’s empty, there’s no panic log, otherwise it may give you a further clue.
• Look for the word paniclog in the eventMessage field for log entries in the minute or two after the Mac restarts. If that extract reads failed to map memory for paniclog output - 0x3 then there’s likely to be a panic log somewhere.
• Browse log entries from the subsystem com.apple.DumpPanic in the minute or so after startup. That subsystem handles generation of the panic log, and makes it clear whether there is one.

From bitter experience, I regret to inform you that trying to gain any information about a kernel panic, or its cause, from log entries made before the Mac shut down or restarted are almost certainly doomed. In any case, most of the time you don’t know when the Mac shut down or restarted, so would waste time trying to discover that.

DumpPanic

In an Apple silicon Mac, at least, if there are log entries from com.apple.DumpPanic confirming that a panic log was generated, you’ve struck gold, even if you can’t find the log itself. Make a note of the time that subsystem reports
DumpPanic launched after boot to check for device panic data
then use that as the start time for a log extract set to a subsystem of com.apple.osanalytics.preoslog, and examine those entries. Starting with the entry
preoslog dump begin
you’ll see breadcrumb data from iBoot stages 1 and 2, each introduced with the emoji , and ending with
preoslog dump end

A little further on, com.apple.DumpPanic should give the first line of the panic log, such as
embedded panic string decoded: panic(cpu 0 caller 0xfffffe002513b34c): Kernel data abort. at pc 0xfffffe0025acf058, lr 0x70c77e0025acf40c (saved state: 0xfffffe8dff723310)
Even if you can’t see the full panic log, at least you’ve got its punchline.

Causes to consider

• Loss of mains or battery power.
• PSU fault.
• Other hardware faults.
• Kernel panic, or freeze preventing that.
• Human or animal intervention.