When your Mac starts up after a kernel panic, it prepares a panic log which should be displayed in a window a minute or two after you have logged in. Before you add any relevant details about the circumstances of the panic and send it to Apple, select it all, copy and paste the text into a document for your study. More than anything else, this panic log will provide clues as to what went wrong, thus what you can do about it. This article steps through one example panic log, and tries to explain its most useful information.

Starting from the top:

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 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. Then it gives the likely immediate cause of the panic. In this case, it’s a specific diagnosis, which is invaluable, but in many cases it’s an ‘exception’ which may well mean nothing to you.

As the name implies, exceptions are conditions which require 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.

Backtrace (CPU 8), Frame : Return Address
followed by series of backtrace details is of no use to regular users.

Kernel Extensions in backtrace:
com.apple.iokit.IOAcceleratorFamily2(438.7.3)[9D052246-9911-3EB3-89E9-BDF771949C45]@0xffffff7f85909000->0xffffff7f859ccfff
dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)[CA079DB9-6FDB-3AB5-A5E5-506459E3F12E]@0xffffff7f8282e000
…
This identifies all the kexts which are referenced in the backtrace above, and gives you a more useful shortlist of those which should be suspected as being involved in the panic. 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.

BSD process name corresponding to current thread: WindowServer
Boot args: chunklist-security-epoch=0 -chunklist-no-rev2-dev
This is the name of the process running its code at the time, and can be another clue as to where the problem lies. Unfortunately, in this case it’s WindowServer, which is running all the time that a user is logged in, thus is almost certainly an innocent bystander in this particular panic.

Mac OS version:
19G73
This states the build number of the current version of macOS, as shown in the System Version given under Software in System Information.

Kernel version:
Darwin Kernel Version 19.6.0: Sun Jul 5 00:43:10 PDT 2020; root:xnu-6153.141.1~9/RELEASE_X86_64
…
This gives the version of the current kernel, which you can also find in Software in System Information.

System model name: iMacPro1,1 (Mac-7BA5B2D9E42DDD94)
System shutdown begun: NO
This gives the Model Identifier, and states whether the system had been preparing to shut down. One important piece of information omitted here is the current firmware version, which you can look up in the Hardware section of System Information, or check using my free utility SilentKnight.

System uptime in nanoseconds: 1239705131493706
This gives the time since the last startup, but in nanoseconds. To convert it to seconds, remove the last nine digits, here resulting in 1239705. From there, divide it by 60 to get minutes, and 60 again for hours. This turns out to be a bit more than 344 hours, or over 14 days.

Zone Name Cur Size Free Size
vm objects 78041088 26795008
…
The panic log may then give a detailed breakdown of system memory zones, which in this panic are going to be very important. Among the most crucial of those are:
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.

Backtrace suspected of leaking: (outstanding bytes: 288)
…
Because there’s the suspicion of memory leakage, the panic log also gives a detail backtrace of where it suspects that leakage is occurring, and details of the kexts involved in that. Note that those are unlikely to coincide with the kexts identified earlier as possible culprits, so you’ve got more to add to your list.
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
…

The log continues to give further details of the kexts which might be the cause
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
…
These are less useful, and the list long.

Combine the information you have gleaned from the panic log with any you might gain from the unified log, and your knowledge of the circumstances of the kernel panic, and you should have a shortlist of suspect causes.

Apple provides further details in an old and now retired Technical Note, TN2063. There are considerable differences between the panic logs shown there and those you’re likely to encounter in more recent versions of macOS, but some of the detail remains helpful for those who wish to dig deeper.

I wish you success.