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.

To celebrate the New Year, I’m taking a look back at how macOS has changed over the last five years, from 10.14 Mojave to 15.2 Sequoia. While you can read about many of the details in articles here and elsewhere, in this article I focus on its architecture, in particular the contents of the main system library folder, together with its bundled apps. Tomorrow I’ll look in more detail at one phenomenon, the rise of Private Frameworks, and what that tells us.

Mojave was in many ways the last of the traditional versions of what started out as Mac OS X, and not just for its support for 32-bit code. It was most significantly the last to integrate both the system and user files in a single volume, by default quaintly named Macintosh HD. Within that, most system files were concentrated in /System/Library, but many sprawled out from there, and bundled apps were installed in the single main /Applications folder. Although there was a separate Recovery volume, Macintosh HD was macOS and more.

Catalina changed that, first by requiring all code to be 64-bit, and by separating almost all macOS system files into a System volume, with user files on the Data volume. At that stage, System was a real volume mounted read-only, but that was just an intermediate step to the modern boot volume group, with the system being an immutable snapshot of the System volume, the Signed System Volume, SSV. The latter first appeared in macOS 11 Big Sur, and with the addition of a paired Recovery volume, continues in Sequoia.

Over that period, the contents of /System/Library grew considerably in size.

In Mojave, there were just under 4,800 bundles in that folder. Catalina’s reorganisation increased that to around 5,500, and each new major version of macOS since has added another few hundred, culminating in 15.2 with just over 9,000 in all.

Much of that growth has been in Private Frameworks to support macOS and its bundled apps and tools, shown in purple in the bar chart above. Public Frameworks have grown from 546 to 800, similar to kernel extensions, and all the remaining folders from 2,000 to 3,000.

Because bundled apps were only separated in Catalina, their numbers only start in late 2019, as shown in the next chart.

There was a marked rise for Big Sur, since when the total has risen more slowly, from about 55 to 64 today. Some have been removed over that time, such as Network Utility, and others have been relegated to /System/Library/CoreServices/Applications, as has Keychain Access in Sequoia.

The timeline of growth in the number of bundles in the System Library folder matches milestones in Mac history. The first steep rise occurred with Catalina’s novel version of the boot volume group, and since then there have been further steep rises immediately before the release of the first of each family of M-series chips.

The largest of those rises was for the M3 (900), with the M1 (600) and M4 (600) also being substantial. Strangely, that for the introduction of the M2 seems to have taken place over six months in advance, and was smaller at 500 bundles.

Of all the system components that should reflect changing Mac hardware, effects should be greatest on kernel extensions.

Over this period of more than five years the number of kernel extensions stored in /System/Library/Extensions has risen from a low of 515 in 10.15 to 930 in 15.2, five years and two months later. Almost all of that occurred with the release of Big Sur, the first version of macOS to support Apple silicon Macs, when kernel extensions rose from 535 (10.15.7) to 788 (11.0.1). Most of those were required to support all the new hardware devices in the M1 chip. Subsequent families of new M-series chips have required few additional kernel extensions, although their number has been rising more rapidly since macOS 13.0 in October 2022.

It’s hardly surprising that, when someone makes the leap from an old Mac running Mojave to a new model with Sequoia, they’ll encounter so many fundamental differences in macOS. After nearly twenty years of steady evolution, in the last five macOS has changed beyond all recognition.

Given how many of those changes have been required for the introduction of Apple silicon Macs, it’s hard to see how Apple could have reduced the frequency of major macOS upgrades over that period. Even if it had been possible for engineers to have taken macOS from 10.14 to 11.0 in a single step, I suspect that no user or developer could have survived such as huge change at once. Yet without those changes, Apple wouldn’t have been able to release the M1 in late 2020, and we’d probably still be using Intel Macs. I will revisit that in more detail at the weekend.

Tomorrow I’ll look in more detail at how its APIs have changed.

In case the message isn’t clear yet, third-party kernel extensions are on their way out, particularly in Apple silicon systems. Although macOS continues to extend the capabilities of its kernel using nearly 700 of them, for almost all purposes user apps and devices should now have switched to using modern system extensions and their equivalents. This article considers how you can clean your Mac of those old kernel extensions (kexts), particularly in preparation for a new Mac.

The problem

In the past kexts have been used widely to support third-party hardware and features like software firewalls and security protection. Because those run at a highly privileged level, in what’s known as Ring 1, they have been a well-known cause of instability leading to kernel panics. They also provide malicious software with an opportunity to wreak havoc at the highest level. Replacing kexts with system extensions run at a user level should improve both stability and security, although experience shows that the first of those isn’t yet guaranteed, as macOS support for system extensions hasn’t been as free of bugs as it should have been, and sometimes has caused kernel panics.

From Big Sur onwards, the previous scheme of prelinked kernels has changed to use kext collections pooling kexts to be loaded into one of three:

• The Boot Kext Collection (BKC), on the Sealed System Volume in /System/Library/KernelCollections (Intel Macs) or the Preboot volume (M-series Macs). This is the equivalent of the old prelinked kernel, and contains the kernel itself, and all the major system kernel extensions required for a Mac to function. This is typically about 65 MB in size on Intel.
• The System Kext Collection (SKC), also on the Sealed System Volume of Intel Macs in /System/Library/KernelCollections, but not used on Apple silicon models. This contains other system kernel extensions, loaded after booting with the BKC, and typically around 370 MB.
• The Auxiliary Kext Collection (AKC), stored on the Data volume in /Library/KernelCollections when it exists, is built and managed by the service kernelmanagerd. This contains all installed third-party kernel extensions, and is loaded after the other two. In Full Security mode on Apple Silicon there’s no AKC.

Cleaning up old kexts is a valuable move even if you’re not intending to migrate to an Apple silicon Mac, and has grown in importance with newer Macs. For a kext to be used on an Apple silicon Mac its boot security has to be reduced, third-party kexts must be enabled, and each one installed with authorisation through Privacy & Security settings, something you’ll probably want to avoid.

Uninstalling kexts

Before going any further, you need to check each of the kexts installed on your Mac to ensure that it can now be safely removed, either because there’s a better substitute, or because they have simply become orphaned. In many cases, on older Macs, kexts currently installed aren’t used at all, but have been abandoned there.

As you may be aware, kexts are now found in two different locations. They should have been originally installed by the app they came with, and saved first to /Library/Extensions. macOS then normally copies them from there to a folder nested inside /Library/StagedExtensions. That presents a further problem, as the latter are protected by SIP and can’t be tampered with. Cleaning up old kexts might thus appear an impossible task.

The good point about /Library/StagedExtensions is that its contents are structured to inform you of where the original kext came from: if it’s in /Library/StagedExtensions/Applications, then the kext was installed by that app, otherwise its folder path should lead you in the right direction.

For kexts installed by an app, or its installer, the responsibility for removing that kext rests with the app or its dedicated uninstaller. Apps that use kexts have to install them before use, for which most run scripts to move or copy the kext into the /Library/Extensions folder. They will then use additional scripts to update or remove that kext, that should save you the trouble. First visit that app’s support pages, and consult the procedure described there for uninstalling it. If the copy you have installed on your Mac isn’t the current version, you are likely to be advised to update to that latest version in order to uninstall it correctly.

Orphaned kexts

When a kext appears to have become orphaned from its app, or perhaps was installed independently, you’ll need to remove it manually. The steps required are:

• Delete all apps and services that might try to use that kext, and any other kexts that might depend on it.
• Unload the kext.
• Delete the kext from the /Library/Extensions folder.
• Restart to allow the auxiliary kext collection to be rebuilt.

It’s important to remove the app and any services that might try using that kext, as some might even try to reinstall it if they’re run. Others that might be run from LaunchAgents or LaunchDaemons could get into difficulties without the kext. Good uninstall scripts should deal with this thoroughly without you having to resort to looking for yourself.

Kexts are now unloaded using a command of the form
sudo kmutil unload -b [bundle-identifier]
or
sudo kmutil unload -p [bundle-path]
where bundle-identifier is a reverse URL like com.highpoint-tech.kext.HighPointRR, or the bundle-path is similar to /Library/Extensions/HighPointRR.kext. kmutil is the replacement for the old kextunload command. Although you could still use the latter, it will merely call kmutil to do its work.

With the kext unloaded, you can then delete it from its accessible location in /Library/Extensions. macOS controls its own staged copy in /Library/StagedExtensions, which it ultimately may get around to removing as well. If you want to remove all kexts from the staging directory, use the command
sudo kmutil clear-staging
although that will also clear any that you might still need, and could require those to be reinstalled.

With those cleared away, you’re ready to restart, which should trigger macOS to rebuild the auxiliary kext collection containing third-party kexts before they’re loaded during the restart. If the auxiliary kext collection isn’t rebuilt correctly, you can force that with the command
sudo kmutil rebuild
and authorising that, followed by restarting the Mac to bring those changes into effect.

You can then check to see if that kext has been loaded using the command
kmutil showloaded --collection aux
to list all loaded kexts in the auxiliary kext collection.

Migration to Apple silicon

Not only is Migration Assistant reluctant to try installing kexts on your new Mac, because of their requirements for use on Apple silicon Macs, it’s unable to enable and load any kexts. However, if you do need to use kexts on an M-series Mac, you’re going to have to enable them first using Startup Security Utility in Recovery Mode, then run the app’s install sequence and authorise them in Privacy & Security settings. That isn’t something that can happen behind your back, and without changing boot security settings no third-party extensions can be loaded. By default, your new Mac should start as clean as a whistle.

Summary

• This is a good time to clean up old kernel extensions on your Mac.
• Where possible, follow instructions for their removal provided on their support site.
• Use an app’s uninstall feature, or its uninstaller, if provided.
• Manual uninstalls require deletion of apps and code relying on that kext, unloading using kmutil, deletion from /Library/Extensions, and restarting.
• Don’t worry about what may be left behind in /Library/StagedExtensions.
• Old kexts can’t be enabled automatically by Migration Assistant for an Apple silicon Mac.

Further reading

Installing a kernel extension (Apple)
Installing system extensions and drivers (Apple)