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.

Macs should never shut down or restart of their own accord, nor should they ever freeze. If yours does any of those, you should assume it’s the result of a kernel panic, and that’s not something you should ignore. The most important evidence as to what happened in a kernel panic, and clues as to why it happened, comes in the panic log, shown shortly after you’ve logged back into your Mac. Don’t dismiss that dialog until you’ve saved its contents for future reference.

Save the panic log

Panic logs used to be saved in /Library/Logs/DiagnosticReports, from where you could open them in Console, but more recently were found somewhere closer to /var/db/PanicReporter, but now seem to vanish into thin air. You therefore need to copy its contents as soon as it appears and before sending it to Apple.

If the alert isn’t already showing the panic log, click on its Report… button, then open a text editor like TextEdit. Copy the whole contents of the panic log into a new text document and save it somewhere safe before clicking on the button to send the report to Apple. Once you’ve done that, the alert is dismissed and can’t be brought back.

Unlike app crash logs, panic logs are normally brief and to the point. Although they may be non-specific and not help much, in many cases they contain obvious clues as to what caused the panic. Formats have changed over the years, and the current Paniclog version is 14, but the following sections are likely to prove worthwhile examining.

Immediate cause

At the very top, following the first word panic, the log gives summary information and may suggest a cause:
panic(cpu 0 caller 0xfffffe002f4e48bc): cannot find IOAESAccelerator
tells you that the panic occurred on CPU core 0, because a key kernel extension couldn’t be found, a cause that isn’t particularly useful in discovering why the panic occurred.

Other non-specific examples include:
panic(cpu 0 caller 0xffffff80015efa76): Kernel trap at 0xffffff7fa047645c, type 14=page fault, registers:
panic(cpu 4 caller 0xfffffe001b91de94): Kernel data abort. at pc 0xfffffe001c2b2538, lr 0x65a4fe001c2b28ec (saved state: 0xfffffe402ecdb310)

Sometimes you strike lucky at the start:
panic(cpu 1 caller 0xfffffff01731bd68): SEP Panic: :SEPD/MDMA: 0x0000b72d 0x0002791b 0x0000971f 0x00003a91 0x00003bb7 0x00000000 0x00000000 0x00000000 [rnit]
reveals that it was the SEP, Secure Enclave Processor, that panicked. That’s likely to result in a boot-loop panic, where every time the Mac tries to start up, it panics immediately, and continues to cycle through booting and panicking until you or your Mac force it to shut down.

panic(cpu 8 caller 0xffffff80017729eb): "zalloc: zone map exhausted while allocating from zone kalloc.12288, likely due to memory leak in zone kalloc.48 (6586956000 total bytes, 137228148 elements allocated)"@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-6153.141.1/osfmk/kern/zalloc.c:3627
is pure gold, as it reveals a probable memory leak as the cause.

Exceptions mentioned here can include page faults, in which something has tried to access an invalid memory address, invalid instruction codes for the processor, and general protection faults which include a wide variety of other bugs. As far as the user is concerned, all exceptions indicate a bug or problem in the code that’s being run.

Further down you should see confirmation that this was a kernel panic, in a line like
Debugger message: panic

OS details

Normally you’ll see a couple of lines reporting the version number of macOS running at the time. For example
OS version: 24C101
Kernel version: Darwin Kernel Version 24.2.0: Fri Dec 6 18:57:59 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_VMAPPLE
You can compare those with the build number of macOS shown in System Information / Software, and in Mints. This is an unusual situation, as RELEASE_ARM64_VMAPPLE means this is from a virtual machine running on an Apple silicon Mac.

Sometimes you might see a line like
OS version: Not set yet
simply indicating that the version hasn’t been recorded yet.

On Apple silicon Macs, you should also see the iBoot version, and the current level of boot security:
iBoot version: iBoot-11881.61.3
secure boot?: YES
The latter is important, as running in Secure Boot means that no third-party kernel extensions have been loaded.

Memory leak

If there has been a memory leak, the panic log may well contain a breakdown of system memory zones giving more detailed clues.
Zone Name Cur Size Free Size
vm objects 78041088 26795008
…
Zone Name Cur Size Free Size
kalloc.32 280834048 3040
kalloc.48 6586956000 4896
kalloc.64 4241453056 5000896
…
Note how the Free Sizes of kalloc.32 and kalloc.48 are very small, and that of kalloc.64 is fairly low too. This is consistent with the kernel running out of memory in one of those zones. Further information may follow:
Backtrace suspected of leaking: (outstanding bytes: 288)

Because there’s the suspicion of memory leakage, the panic log also gives a detailed backtrace of where it suspects that leakage is occurring, and details of the kexts involved in that. Note that those may not coincide with any kexts identified earlier as possible culprits.

Panicked task

It’s worth looking through the log to discover the task that was running at the time of the panic. That might simply be the kernel
Panicked task 0xfffffe166cff1f18: 10735 pages, 374 threads: pid 0: kernel_task
or may give more specific information
BSD process name corresponding to current thread: WindowServer
Boot args: chunklist-security-epoch=0 -chunklist-no-rev2-dev
or
Panicked task 0xfffffe1b55369798: 24964 pages, 8 threads: pid 800: com.apple.Mobile
alternatively
Process name corresponding to current thread: mediaanalysisd

This is the name of the process running its code at the time, and can give another clue as to where the problem lies.

You may also be given a list of kernel extensions that might be involved:
Kernel Extensions in backtrace:
com.apple.filesystems.apfs(1412.141.1)[6DA33D13-4501-3D48-B4D8-0329E6AEC86D]@0xffffff7f84e7d000->0xffffff7f84fa4fff
dependency: com.apple.kec.corecrypto(1.0)[804DD660-F561-3444-A076-05D7A52D65E3]@0xffffff7f82746000
…

Third-party kexts

Whatever the cause, you should next look at the list of unloaded and loaded kexts forming the rest of the panic log. These are listed in the order that they were loaded, with the most recent kext at the top. As third-party kexts are the last to be loaded, the top of the lists start with any third-party kexts installed on that system and loaded at the time of the panic:
last loaded kext at 939128480512562: >!UAudio 323.4 (addr 0xffffff7f86baa000, size 434176)
last unloaded kext at 948795488738566: >usb.IOUSBHostHIDDevice 1.2 (addr 0xffffff7f8556c000, size 45056)
loaded kexts:
>!ATopCaseHIDEventDriver 3430.1
…
In most cases, the name of the kext as you’ll find it in /System/Library/Extensions is the last part of the ID given. For example, the kext with the ID of com.apple.driver.AppleMobileFileIntegrity is named AppleMobileFileIntegrity.kext.

If those lists contain any third-party kexts, they should be immediately suspected as being the cause of that panic, unless another cause is apparent.

Keep your Mac’s panic logs

Although you’ll want to get on with whatever you were going to do when you were so rudely interrupted by that kernel panic, put that record of the panic log somewhere safe. If your Mac does suffer another panic, you can then refer back to it for any common features that might indicate they had the same cause. Panic logs are also invaluable for others who might assist you in discovering what was wrong. I’m very grateful to those who send me their panic logs, and here wish to acknowledge Joe, who kindly sent me my first SEP panic, a real collector’s item.

There’s more information about dealing with kernel panics in the following articles here:
Crashes, panics, freezes and other unexpected events
How to deal with a kernel panic

A kernel panic is completely different from an app crash. When apps suddenly vanish because of a bug or error, everything else should carry on as normal. When your Mac restarts of its own accord, or you find it shut down and have to start it up again, that’s almost certainly a kernel panic, and should be taken seriously.

Kernel panics occur when macOS can’t continue running any more due to severe (software) damage, and its only option is to restart itself in order to resume normal services. When this happens before the login window appears during startup, it normally results in a boot loop, as discussed elsewhere. This article covers the more common situation when a Mac restarts spontaneously and completes login without any further panic occurring.

Virtual machines (VMs) can also suffer kernel panics, as well as causing the host macOS to panic. Those should behave like other panics, although if you’re unlucky the VM might be damaged and unable to restart properly. If that happens, your only option is to try starting that VM up in Recovery, to see if it can be repaired there. If not, and you can’t get it to start up again, you’ll need to trash it and restore its last backup copy.

Save the panic log

Within a minute or so after restarting, a Panic Alert is displayed, inviting you to agree to send the panic log to Apple. Don’t simply agree to that, though, as it’s the only record of what happened. Panic logs used to be saved in /Library/Logs/DiagnosticReports, from where you could open them in Console, but more recently may be found somewhere closer to /var/db/PanicReporter. You therefore need to copy its contents as soon as it appears and before sending it to Apple.

If the alert isn’t already showing the panic log, click on its Report… button, then open a text editor like TextEdit. Copy the whole contents of the panic log into an empty text window and save it somewhere safe before clicking on the button to send the report to Apple. Once you’ve done that, the alert is dismissed and can’t be brought back.

It’s commonly assumed that sending a panic log to Apple means that an engineer will look through it and get back to you with some sort of diagnosis. That isn’t what the report does, though: it’s processed automatically and, while there’s nothing stopping someone at Apple contacting you about it, that simply doesn’t happen. Only by saving a copy of the log could you contact Apple Support and ask for their help. Also consider filing a Feedback report containing a description of what happened and your copy of the panic log, particularly if you have clues as to its cause.

Immediate actions

The three most common reasons for kernel panics are:

• hardware (and device firmware) failure or error,
• kernel extensions,
• conflict with a peripheral.

If you suspect a hardware failure, or wish to rule that out, shut your Mac down once you have captured the panic log, disconnect all non-essential peripherals, and start it up in Diagnostics to run its hardware test routines. If you’re not reassured that all is well, don’t hesitate to get your nearest Apple store or authorised service provider to run their more advanced diagnostics as well.

On Apple silicon Macs, Diagnostics is different in relying on a hidden key combination: start the Mac up in Recovery by holding the Power button, and in the initial Options screen, hold Command-D until the Diagnostics Loader starts. This may require download of the disk image from Apple’s servers before testing can proceed, so a good Wi-Fi connection is important. Once loaded, there’s a hidden option for extended diagnostics that can be triggered by holding the Command-E key combination.

Panics associated with peripherals such as Thunderbolt docks and hubs are best diagnosed by running the Mac without the suspect hardware connected, to test if panics continue. If they do, and you remembered to save panic reports, even if you don’t understand their details you can still compare them to see if they look similar.

Kernel extensions

Third-party kernel extensions are normally found in /Library/Extensions or the app using them, from where macOS stages them into a folder in /Library/StagedExtensions where they’re protected by SIP. Most are only loaded on demand, so the mere presence of an extension there isn’t sufficient evidence to convict it of causing the panics. However, you should become suspicious when a third-party extension is named in the panic log as being part of the chain that may have caused it. Most software that used to rely on kernel extensions has now been updated to use system extensions or another modern replacement, so updating old software could solve the problem.

Tools for working with kernel extensions are detailed in the article on boot loops. If you need to remove a kernel extension, this article explains how to do that. One quick way to disable all third-party kernel extensions on an Apple silicon Mac is to start it up in Recovery, go through to the main Recovery window, open Startup Security Utility from the Utilities menu, disable loading kernel extensions and return it to Full Security.

Modern System Extensions don’t run with the same level of privilege as kernel extensions, so in theory shouldn’t be capable of causing kernel panics. However, experience has shown that the macOS kernel extensions required to support them can prove unstable and cause panics. This should be apparent from careful reading of the panic log.

Reading the panic log

Unlike app crash logs, panic logs are normally relatively brief and to the point. Although they may be non-specific and not help you much, in many cases they contain obvious clues as to what caused the panic. Formats have changed over the years, but the following sections are likely to prove worthwhile examining.

Immediate cause

At the very top, following the first word panic, the log may suggest a cause. This is most common when a memory leak is to blame, such as
panic(cpu 8 caller 0xffffff80017729eb): "zalloc: zone map exhausted while allocating from zone kalloc.12288, likely due to memory leak in zone kalloc.48 (6586956000 total bytes, 137228148 elements allocated)"@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-6153.141.1/osfmk/kern/zalloc.c:3627

This first tells you which CPU core the panic occurred on. If you have repeated panics, keep a note of these, as they may cast suspicion on a core with a hardware problem.

In other cases, you may not be as lucky, and the cause is just given as an ‘exception’, or
panic(cpu 0 caller 0xfffffe002f4e48bc): cannot find IOAESAccelerator
panic(cpu 0 caller 0xfffffe001abd5e94): Kernel data abort
so you’ll need to look for other clues. As the name implies, exceptions are conditions requiring special handling by the operating system. They include page faults, in which something has tried to access an invalid memory address, invalid instruction codes for the processor, and general protection faults which include a wide variety of other bugs. As far as the user is concerned, all exceptions indicate a bug or problem in the code that’s being run.

OS details

You may see a line like
OS version: Not set yet
simply indicating that the version hasn’t been recorded yet. When it has, this gives its build number rather than version. Most importantly, you should see a statement of the kernel version running:
Kernel version: Darwin Kernel Version 24.2.0: Fri Dec 6 18:57:59 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_VMAPPLE
You can check that against that shown in Software in System Information.

On Apple silicon Macs, you should also see the iBoot version, and the current level of boot security:
iBoot version: iBoot-11881.61.3
secure boot?: YES
The latter is important, as running in Secure Boot means that no third-party kernel extensions have been loaded.

Memory leak

If there has been a memory leak, the panic log may well contain a breakdown of system memory zones giving more detailed clues.
Zone Name Cur Size Free Size
vm objects 78041088 26795008
…
Zone Name Cur Size Free Size
kalloc.32 280834048 3040
kalloc.48 6586956000 4896
kalloc.64 4241453056 5000896
…
Note how the Free Sizes of kalloc.32 and kalloc.48 are very small, and that of kalloc.64 is fairly low too. This is consistent with the kernel running out of memory in one of those zones. Further information may follow:
Backtrace suspected of leaking: (outstanding bytes: 288)
Because there’s the suspicion of memory leakage, the panic log also gives a detailed backtrace of where it suspects that leakage is occurring, and details of the kexts involved in that. Note that those may not coincide with any kexts identified earlier as possible culprits.

Panicked task

This may simply be the kernel
Panicked task 0xfffffe166cff1f18: 10735 pages, 374 threads: pid 0: kernel_task
or may give more specific information
BSD process name corresponding to current thread: WindowServer
Boot args: chunklist-security-epoch=0 -chunklist-no-rev2-dev
or
Panicked task 0xfffffe1b55369798: 24964 pages, 8 threads: pid 800: com.apple.Mobile
This is the name of the process running its code at the time, and can be another clue as to where the problem lies.

You may also be given a list of kernel extensions that might be involved:
Kernel Extensions in backtrace:
com.apple.filesystems.apfs(1412.141.1)[6DA33D13-4501-3D48-B4D8-0329E6AEC86D]@0xffffff7f84e7d000->0xffffff7f84fa4fff
dependency: com.apple.kec.corecrypto(1.0)[804DD660-F561-3444-A076-05D7A52D65E3]@0xffffff7f82746000
…

Third-party kexts

Whatever the cause, you should next look at the list of unloaded and loaded kexts forming the rest of the panic log. These are listed in the order that they were loaded, with the most recent kext at the top. As third-party kexts are the last to be loaded, the top of the lists start with any third-party kexts installed on that system and loaded at the time of the panic.
last loaded kext at 939128480512562: >!UAudio 323.4 (addr 0xffffff7f86baa000, size 434176)
last unloaded kext at 948795488738566: >usb.IOUSBHostHIDDevice 1.2 (addr 0xffffff7f8556c000, size 45056)
loaded kexts:
>!ATopCaseHIDEventDriver 3430.1
…
In most cases, the name of the kext as you’ll find it in /System/Library/Extensions is the last part of the ID given. For example, the kext with the ID of com.apple.driver.AppleMobileFileIntegrity is named AppleMobileFileIntegrity.kext.

If those lists contain any third-party kexts, they should be immediately suspected as being the cause of that panic, unless another cause is apparent.

Summary

• Save the panic log before sending it to Apple.
• Consider running Diagnostics if there’s the possibility of a hardware problem.
• Consider disconnecting a peripheral if that could be the cause.
• Consider removing/updating any third-party kernel extensions, or better, disabling them altogether.
• Read the panic log to provisionally identify its most likely cause, and try to address that.
• Report the panic to Apple Support and/or via Feedback.
• Keep a careful watch for any further panics, and be prepared to revise your provisional diagnosis.