Home > Jamf Pro, Mac administration, macOS, Scripting > Detecting kernel panics using Jamf Pro

Detecting kernel panics using Jamf Pro

Something that has (mostly) become more rare on the Mac platform are kernel panics, which are computer errors from which the operating system cannot safely recover without risking major data loss. Since a kernel panic means that the system has to halt or automatically reboot, this is a major inconvenience to the user of the computer.


Kernel panics are always the result of a software bug, either in Apple’s code or in the code of a third party’s kernel extension. Since they are always from bugs and they cause work interruptions, it’s a good idea to get on top of kernel panic issues as quickly as possible. To assist with this, a Jamf Pro Extension Attribute has been written to detect if a kernel panic has taken place. For more details, please see below the jump.

When a Mac has a kernel panic, the information from the panic is logged to a log file in /Library/Logs/DiagnosticReports. This log file will be named something similar to this:


The Extension Attribute is based off an earlier example posted by Mike Morales on the Jamf Nation forums. It performs the following tasks:

  1. Checks to see if there are any logs in the /Library/Logs/DiagnosticReports with a .panic file extension.
  2. If there are, check to see which are from the past seven days.
  3. Output a count of how many .panic logs were generated in the past seven days.

To test the Extension Attribute, it is possible to force a kernel panic on a Mac. To do this, please use the process shown below:

1. Disable System Integrity Protection
2. Run the following command with root privileges:

dtrace -w -n "BEGIN{ panic();}"

Screen Shot 2020 11 10 at 10 52 23 AM

3. After the kernel panic, run a Jamf Pro inventory update.

After the inventory update, it should show that at least one kernel panic had occurred on that Mac. For more information about kernel panics, please see the link below:


The Extension Attribute is available below and at the following address on GitHub:


# Detects kernel panics which occurred in the last seven days.
# Original idea and script from here:
# https://www.jamf.com/jamf-nation/discussions/23976/kernal-panic-reporting#responseChild145035
# This Jamf Pro Extension Attribute is designed to
# check the contents of /Library/Logs/DiagnosticReports
# and report on how many log files with the file suffix
# of ".panic" were created in the previous seven days.
PanicLogCount=$(/usr/bin/find /Library/Logs/DiagnosticReports -Btime -7 -name *.panic | grep . -c)
echo "<result>$PanicLogCount</result>"
exit 0

view raw


hosted with ❤ by GitHub

  1. Rob
    November 10, 2020 at 8:18 pm

    I have had my machine reboot this week and show the multi language prompt stating that there was an issue and it would continue to start after X seconds. I assumed that would be a kernel panic, but I have no .panic files in /Library/Logs/DiagnosticReports. Is that type of crash different and is it possible to track these?

    • November 10, 2020 at 8:28 pm

      I’ve observed that some kernel panics will have a log named “.content.panic”. The period in front of “content” will mark it as an invisible file, so it wouldn’t appear in the Finder.

      • Rob
        November 12, 2020 at 9:20 pm

        This is in Terminal using sudo ls -al /Library/Logs/DiagnosticReports. Still no panic files. Very odd. Thanks for the response.

  2. MikeK
    February 12, 2021 at 4:26 pm

    If you have a T2 Mac and the panic is being caused by the Bridge OS, the panic logs are written to /Library/Logs/DiagnosticReports/ProxiedDevice-Bridge/

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: