What Is a Kernel Panic on Mac?

The short answer. A kernel panic is macOS deciding that it can no longer guarantee the machine is in a correct state, and stopping it. The screen goes dark or shows a message, the Mac restarts, and afterwards you get a dialog saying it restarted because of a problem. The panic is a safety mechanism rather than a fault in itself; the fault is whatever the kernel found, and the log it wrote on the way down usually names it.

This guide covers what the log says, the five causes in order of how often they occur, and how to tell a panic from the three other things people call one.

What actually happens

macOS runs code in two modes. User-mode code — applications — runs in its own memory space, cannot touch hardware directly, and can be killed without affecting anything else. Kernel-mode code runs with full privileges, shares one address space with the rest of the kernel, and can do anything.

That asymmetry is the whole point of the distinction. A bug in an application crashes the application. A bug in the kernel corrupts the state of the machine, and there is no smaller unit to kill.

So when the kernel detects a condition it cannot recover from — an invalid memory access in kernel code, a failed assertion, a driver returning an impossible result — it has two options. It can continue and risk writing corrupted data to your disk, or it can stop. It stops. That is a panic, and it is the correct behaviour: a machine that halts loses your unsaved work, and a machine that continues with a corrupted filesystem can lose everything.

The message is not an error report in the ordinary sense. It is the kernel’s last statement before it goes down, and it is written to disk precisely so that someone can read it afterwards.

What you see, then and now

Older versions of macOS showed a grey curtain with a message in several languages, telling you to restart. That was a panic with a visible UI.

Since OS X Mountain Lion, the machine restarts automatically and shows nothing at the time. On the next boot you get a dialog: “Your computer restarted because of a problem.” with an option to send a report to Apple. If the panic happens during boot, the machine may loop — restarting, panicking, restarting — and never reach the desktop.

On Apple Silicon the panic is also recorded by the Secure Enclave and, if the machine restarted without a clean shutdown, a short summary may appear in the boot log. The file in /Library/Logs/DiagnosticReports is the one to read.

Reading the log

The panic log is a text file with a predictable shape. Here is the part that matters, from a typical example:

panic(cpu 2 caller 0xffffff8000a1b2c3): Kernel trap at 0xffffff7f9a1c3d40, type 14=page fault
...
Panicked task 0xffffff95234a1000: 0 pages, 412 threads: pid 0: kernel_task
...
Kernel Extensions in backtrace:
         com.example.driver.kext(1.2.3)[A1B2C3D4-...]@0xffffff7f9a1c0000->0xffffff7f9a1dffff
         dependency: com.apple.iokit.IOPCIFamily(2.9)[...]@0xffffff7f...

Four things to read, in this order:

The first line. panic(cpu 2 caller 0x…) tells you which CPU and which function called the panic. type 14=page fault means the kernel accessed an address it should not have. Other common types are assertion failures and explicit panics from a driver.

Kernel Extensions in backtrace. This is the list of code involved. Anything starting with com.apple. is Apple’s; anything else is third-party. A third-party entry here is the answer in the overwhelming majority of cases.

Panicked task. Often kernel_task with pid 0, which tells you the fault was in kernel context rather than in a user process. If it names a real process, that process was running when the fault occurred — which makes it a suspect, not a conviction.

The timestamp and the sequence. If you have three panic files and two of them are identical, you have one reproducible bug rather than three faults. That is the single most useful thing to establish before you change anything.

The files live in /Library/Logs/DiagnosticReports and end in .panic or, on newer versions, .ips. Console.app lists them under Crash Reports in a readable form. From Terminal:

log show --predicate 'eventMessage contains "panic"' --last 24h

The five causes, in order of frequency

1. A third-party kernel extension

This is the most common cause by a wide margin, and it is the one to eliminate first.

Kernel extensions — kexts — run in the kernel. A bug in one is a bug in the kernel, and the machine panics. They are also the component most likely to be out of date, because they are installed by hardware vendors and audio interface makers who update them rarely, and because macOS changes the kernel interfaces they depend on with every major release.

The usual suspects: virtual machine hypervisors, audio interfaces, RAID and storage controllers, VPN clients that install a network extension at the kernel level, older security software, and anything that advertises “system-level” features.

KextViewer lists what is loaded with signing information; KnockKnock lists what is installed persistently, which is more useful because a kext that panics at boot may not be loaded long enough to appear in the first list. The list of loaded kexts from the command line is kmutil showloaded, which replaced the older kextstat.

2. Failing hardware

Memory, storage, the logic board and the GPU all produce panics when they fail, and the signature is a panic whose log blames no third-party code and whose backtrace is entirely Apple’s.

Memory errors are the classic. A bad RAM module corrupts a pointer in kernel code and the fault appears somewhere unrelated — which is why a memory fault looks like a software bug in a random subsystem. On Intel Macs with replaceable memory, reseating or swapping the modules is a cheap test. On Apple Silicon the memory is in the package and the test is Apple Diagnostics.

Storage produces a different pattern: panics during heavy I/O, sometimes with the disk disappearing from Disk Utility afterwards. A drive that is failing electrically can drop off the bus under load, and the kernel panics because a device it was talking to has gone.

3. A GPU or display driver fault

Panics that occur when waking from sleep, when connecting an external display, or when a GPU-heavy application starts. The backtrace names the graphics driver. On Intel Macs with switchable graphics this is more common than on Apple Silicon, where the GPU is part of the same package.

A test worth running: does the panic stop if you never connect the external display, or never let the machine sleep? If the answer is yes, you have isolated the trigger, which is most of the diagnosis.

4. A bug in macOS itself

Real, and rarer than people assume. The pattern is a panic that occurs on many machines of the same model running the same version, with no third-party kexts involved. The .panic log will show a backtrace entirely in Apple’s code.

The response is to update. Apple fixes these, and a machine that panics on a specific point release usually stops after the next one.

5. A corrupt system file or a full disk

A disk with no free space, a corrupted system volume, or a broken sealed system snapshot can produce a panic at boot. This is the case where the machine loops rather than starting, and where Recovery is the only way in.

The pattern test

Before you change anything, write down three things about the last panic:

1. When did it happen? At boot, during sleep or wake, under load, or after connecting something.
2. How often? Once in six months is a different problem from twice a day.
3. What changed recently? A new peripheral, a new app, a system update, a new cable.

Those three answers cut the search space more than any tool. A panic at wake with no new software is a driver. A panic under load on a machine that also runs hot is thermal or hardware. A panic that started the day you installed a virtual machine is the hypervisor.

Safe Mode, and what it proves

Safe Mode loads only Apple’s software, skips third-party login items and kernel extensions, and rebuilds some caches on the way in.

On Intel: restart holding Shift until the login window appears. On Apple Silicon: shut down, hold the power button until the startup options appear, select your disk, then hold Shift and click Continue in Safe Mode.

Use the machine normally for a day in Safe Mode. If it does not panic, a third-party component is responsible, and the job is to find it — remove the most recently installed one first, then work backwards. If it does panic in Safe Mode, the cause is hardware or the system volume, and no amount of extension hunting will help.

Safe Mode is also the state in which you can remove a kext that panics at boot, because it is not loaded there.

Apple Diagnostics

The built-in hardware test, and the right next step when Safe Mode panics too.

On Intel: restart holding D, or Option-D to run it over the network. On Apple Silicon: shut down, hold the power button until the options appear, press Command-D.

It runs for a few minutes and returns a reference code. A code starting with NDD or a P series points at memory, storage or the logic board; the exact meaning varies by model, and the code is what to quote when you contact support or book a service. A clean result does not prove the hardware is fine — it proves it passed the tests it ran — but a failing result is conclusive.

What is not a panic

Three other things get called a panic, and they have different answers.

A hang. The machine stops responding, the pointer may still move, the spinning beachball appears, and nothing restarts. That is a deadlock or an overloaded system, not a panic, and there is no panic log because the kernel is still running. sudo spindump captures what every process is doing, which is the closest thing to a log for a hang.

An application crash. One app disappears, the rest of the machine is fine, and a crash report appears in Console. That is a user-mode fault, and the kernel is not involved.

A sleep or wake failure. The machine fails to sleep, or wakes to a black screen, and writes a Sleep Wake Failure report to the same folder. It is a separate log type with a separate set of causes, usually a peripheral or a driver that cannot handle the power transition. It is worth knowing the difference because the fixes do not overlap.

When the Mac will not boot at all

A panic during boot produces a loop: the machine restarts, panics again, restarts. The desktop never appears, so none of the diagnostic steps above are available.

The way out is Recovery. On Apple Silicon, hold the power button until the startup options appear; on Intel, hold Command-R at startup. From Recovery you can run First Aid on the volume, reinstall macOS, or open Terminal to look at the panic logs that were written to the Data volume — they are still there, because the machine got far enough to mount it.

Three outcomes from Recovery, and they mean different things:

• First Aid finds and repairs errors, and the machine boots. The system volume was damaged, and the repair worked. Reinstall macOS over the top for good measure, since a repaired volume is not a verified one.
• First Aid finds errors it cannot repair. The filesystem is damaged beyond what the tool can fix. Erase and reinstall, then restore from a backup. This is the point at which a backup stops being a good habit and becomes the whole plan.
• The machine will not start even into Recovery. That is hardware, and no software step will help. Apple Diagnostics is not reachable in this state, so the next move is a service appointment.

A panic loop that starts immediately after a system update is its own case. The update left the machine in a state it cannot boot from, and the fix is usually to reinstall the same version from Recovery rather than to downgrade — the installer can repair an incomplete update in place.

Isolating a peripheral

If the panic correlates with a device rather than with software, the isolation method is mechanical and reliable.

Disconnect everything except the power cable and a keyboard. Use the machine for a day. If it is stable, reconnect one device at a time, using each for long enough that the panic would have happened — an hour is usually enough for a driver fault that fires on connect or on first heavy I/O.

The devices that cause this most often are external storage with a vendor driver, audio interfaces, docks and hubs that present several devices at once, and older USB-serial adapters. A hub is worth suspecting specifically because it can make a single port present as a different topology each time it re-enumerates, which is why a panic that seems random can be a dock.

The tell that a device is responsible rather than merely present: the panic log’s backtrace names a driver, and that driver belongs to the device’s vendor. A backtrace entirely in Apple’s USB stack with the device attached is weaker evidence — it may be the device misbehaving at the protocol level, or it may be macOS mishandling a legal device.

Reading the newer log format

Apple changed the crash report format from .panic text files to .ips files, which are JSON with a header line. The content is the same information in a less readable shape.

The two fields worth looking at:

• panicString — the equivalent of the first line of the old log, including the fault type and the calling address.
• kexts or the backtrace section — the extensions involved, with bundle identifiers and versions.

Console.app renders these into the same readable form the old logs had, which is why it remains the easier way to read them. From the command line, cat the file and look for panicString; the JSON is not pretty but it is searchable.

The dialog after the restart

The message that appears on the next boot — “Your computer restarted because of a problem” — offers to send a report to Apple. Sending it is optional and harmless; it includes the panic log and a list of loaded extensions, and it is used in aggregate to find patterns.

What it does not do is tell you anything. The dialog is a notification, not a diagnosis, and the file in /Library/Logs/DiagnosticReports is where the information you need actually lives. Dismissing the dialog does not delete the log.

If the dialog appears every time the machine starts, that is the boot loop described above rather than a new panic each time: the machine panicked once, failed to start, and the report is from that single event being re-presented.

When it is time to stop troubleshooting

Three panics in a month on a machine that has not changed is worth investigating. A panic a day is a machine to stop using for work until it is fixed.

The point at which to book service rather than keep testing: Apple Diagnostics returns a code, or the machine panics in Safe Mode with all peripherals disconnected, or the panics correlate with heat, or the disk has dropped off the bus at least once. Those four signs all point at hardware, and no amount of software removal will fix any of them.

Back up first, always. A machine that panics under load is a machine that may panic during a write, and a panic during a write is exactly the situation APFS is designed to survive — but the backup is what makes that a guarantee rather than a hope.

FAQ

Does a kernel panic damage my files? Usually not. APFS is copy-on-write and crash-safe by design, so the filesystem survives an unclean shutdown in a consistent state. Files that were being written at the moment of the panic may be truncated or missing, and everything unsaved in an application is gone. Running First Aid afterwards is a reasonable precaution rather than a requirement.

Why does my Mac panic when I connect a specific device? Because the driver for that device faults. The device itself may be fine; the driver may not support the current macOS. Check the vendor’s site for a version that does, and if there is not one, the device is not usable on that machine.

Can a panic be caused by a full disk? Yes, occasionally, because the kernel needs space for swap and for logs. It is not the common case, but a machine that panics repeatedly at a few hundred megabytes free is worth freeing space on before assuming anything more exotic.

Does reinstalling macOS fix panics? It fixes the ones caused by a corrupted system volume or a bad update. It does not fix a panicking kernel extension, because reinstalling over the top leaves it installed, and it does not fix hardware. Erase and install, without migrating anything back, is the version that eliminates third-party software — and if the machine still panics after that, the answer is hardware.

Are panics more common on Apple Silicon? No, they are rarer, because there are fewer third-party kernel extensions in circulation for it and the GPU and memory are in the same package. When an Apple Silicon Mac does panic, the cause is more often hardware or a bug in macOS than a third-party driver, which changes where to look first.

Should I report the panic to Apple? It costs nothing and the aggregate data is what Apple uses to find patterns across models and versions. The report contains the panic log and a list of loaded extensions, not your documents. If the panic is reproducible and you can describe the trigger, a report to the developer of the extension in the backtrace is more useful still — they can fix it, Apple cannot fix someone else’s driver.