Skip to content

Glossary

Panic (kernel panic)

XNU's emergency stop. Triggered by unhandled exceptions, failed assertions, or explicit panic() calls. Writes a panic.log to disk; reboots.

A kernel panic is XNU's "I cannot continue safely." When triggered, the kernel:

  1. Saves the panicking CPU's state, the stack trace, the panic reason, and a list of loaded kexts into a panic_info structure.
  2. Halts every other CPU via IPI; only the panicking CPU runs.
  3. Writes a panic log to /Library/Logs/DiagnosticReports/Kernel_<date>_<host>.panic.
  4. If KDP is enabled, waits for a debugger to attach.
  5. Otherwise, reboots.
apple-oss-distributions/xnuosfmk/kern/debug.cpanic() and the panic state machine — what every kernel-side abort routes through.View on GitHub(line —)

Common triggers:

  • Unhandled CPU exception in kernel mode (null deref, bad address access).
  • Failed assertion (assert(x) is a panic in production kernels too).
  • Double fault — a fault while handling another fault.
  • Watchdog timeout — the kernel's heartbeat thread observed the scheduler making no progress.
  • Explicit panic("...") call from any kernel code.

The panic.log is the primary forensic artifact. With Apple's Kernel Debug Kit (KDK) and matching symbols, the addresses in the backtrace can be resolved back to source.

See also: KDP, and the kernel debugging article.