How to read a panic log

A panic-full file looks impenetrable at first, but the useful part is only a few lines. The rest is version information, timestamps and memory addresses. Here is which line to look at and what the common messages mean.

The parts of the file

The file opens with a header line containing:

• bug_type — The kind of report. For panics it is usually 210.
• timestamp — The moment the phone restarted.
• os_version — The iOS version installed at the time.
• product — The model code. iPhone15,2, for example, is an iPhone 14 Pro. This line matters: from iPhone 13 on, the same code maps to different parts on different models, so without it the result cannot be right.

Below the header comes panicString. That is where the real information is.

The panicString line

It usually begins with panic(cpu 4 caller 0x…):. The numbers in brackets are the processor core and a memory address, and are not needed for diagnosis. What follows the colon is the part to read. Some examples:

SMC PANIC

The SMC is the unit that manages the phone's sensors. This message usually comes with a sensor array and a set of numbers. Those numbers encode which sensor stopped answering. From iPhone 13 on they change from model to model, which is why they cannot be read without the "product" line.

With this kind of fault the phone often restarts at regular intervals, like clockwork.

AOP PANIC

The AOP is the section that keeps listening to sensors even while the phone is off. The ambient light sensor, the pressure sensor and some microphones are attached to it. The word next to "AOP PANIC" says which sub-unit was involved, and each one points to a different part.

Watchdog timeout / WDT

This appears when an answer the phone expected from a component never arrived. If a missing sensor is named next to it (something like PRS0 or Mic1), look at the part that carries that sensor. If no sensor is named and only a service appears, software becomes more likely.

i2c

i2c is a bus the components use to talk to the logic board. An i2c number in the log means one of the parts on that bus is not answering. Which part sits on which bus depends on the model.

Software-related messages

Some lines point at the kernel rather than the hardware. Messages such as "Invalid kernel stack pointer" or "Undefined kernel instruction" are mostly software or memory related; a restore is the first thing to try.

What the confidence level means

In the results on this site, every finding carries a confidence label:

• High — The message maps clearly to a specific part.
• Medium — The mapping is known, but the same message can come from another fault too.
• Low — A pointer rather than an answer; it gives an order to check in, not a single part.

Logs read from screenshots are shown one level lower, because letters can be misread.

Things to watch for

• A panic log is a clue. The same message can come from different faults; confirm the result by testing with a known-good part.
• Take more than one log. If they all point to the same part it is likely hardware; if each shows something different, software or the logic board becomes more likely.
• Use the whole log. The panicString line alone is not enough — without the "product" line the model is unknown.
• An old log can mislead you. Check the date in the file name and take the newest.

Paste your log on the analysis page to see which part it corresponds to.