How to read an iPhone panic log

Updated 2026-10-14

Start with the header: bug_type 210 marks a kernel panic, product gives the model (iPhone16,2 = iPhone 15 Pro Max) and os_version the iOS build. Then read the panicString: its first message names the family (SMC sensor array, missing sensor, watchdog…) and the code or sensor that points to the part. Always interpret the code for that exact model.

What does a panic full look like?

A panic-full file is plain text. It starts with a one-line JSON header, followed by a larger JSON body. Most of it is technical noise for a repairer; four fields matter.

Shortened, a typical file looks like this:

{"bug_type":"210","os_version":"iPhone OS 17.x (…)","incident_id":"…"}
{
  "product" : "iPhone16,2",
  "crashReporterKey" : "…",
  "panicString" : "panic(cpu 0 caller 0x…): SMC PANIC - ASSERTION FAILED … SMC BSC failure …
                   sensor array 0 - 4 is 0, 4194304, 0, 0, 0 …"
}

What are the key fields?

Field What it tells you Example
bug_type The report type. 210 = kernel panic, the one you want "210"
product The model identifier, not the commercial name iPhone16,2 = iPhone 15 Pro Max
os_version iOS version and build at the time of the panic iPhone OS 16.5.1 (20F75)
panicString The actual panic message: family, code, sensor or process SMC PANIC … sensor array …

The product field matters more than it seems. Model identifiers don't follow commercial names: iPhone16,1 and iPhone16,2 are the iPhone 15 Pro and 15 Pro Max, iPhone15,2 is the iPhone 14 Pro. Since codes change meaning between models, a wrong model means a wrong part.

incident and crashReporterKey are identifiers. They are useless for the diagnosis, and Check Panic Full removes them before storing a log.

How do I read the panicString?

The panic string always starts with a line of this form:

panic(cpu 0 caller 0xfffffff0…): <message>

Ignore the CPU number and the address: they change from one panic to the next. The message after the colon is what you read. Its first words give the family:

  • SMC PANIC … SMC BSC failure … sensor array → a mandatory sensor stopped answering;
  • userspace watchdog timeout: no successful checkins from … → a process did not check in;
  • AOP PANIC … → Always-On Processor;
  • ANS2 …, nvme … → storage (NAND);
  • SEP … → Secure Enclave;
  • i2c… for device … → a device on an i2c bus.

The rest of the message gives the detail: a code, a sensor name, a process name or a device.

How do I read a "sensor array" code?

This is the most common restart-loop signature on recent iPhones:

SMC PANIC - ASSERTION FAILED … SMC BSC failure …
sensor array 0 - 4 is 0, 4194304, 0, 0, 0

The system management controller lists several values. The non-zero one is the code. Depending on the iOS version, it is printed in decimal or hexadecimal:

  • 4194304 (decimal) = 0x400000 (hexadecimal);
  • 524288 = 0x80000;
  • 2097152 = 0x200000.

Each bit of the value represents one mandatory sensor. When a single sensor is missing, you get a single bit (0x100000, 0x200000, 0x400000…).

What are combined codes?

When several sensors are missing at the same time, their bits add up. The code is then the sum (a logical OR) of several values:

  • on an iPhone 14, 0x300000 = 0x100000 (charging port) + 0x200000 (proximity);
  • on an iPhone 14, 0x700000 = charging port + proximity + wireless coil.

A combined code means two or three parts to check, or one common cause upstream such as corrosion or a logic board fault.

Why does the same code change meaning with the model?

Because the bit layout is different on each generation. A few examples from the database:

Code iPhone 14 iPhone 15 iPhone 15 Pro
0x100000 Charging port flex Front sensors (proximity) Charging port flex
0x200000 Front sensors (proximity) Wireless charging coil Front sensors (proximity)
0x400000 Wireless charging coil — Wireless charging coil

Some codes are not even bits: on the iPhone 14 Pro, 0x41 designates the battery; on the iPhone 15 and 15 Pro, 0xa1 does. This is why reading a code without the model is guesswork. The table lists every documented code per model.

How do I read "Missing sensor(s)"?

On other generations, the same problem appears as a watchdog panic that names the sensor:

userspace watchdog timeout: no successful checkins from thermalmonitord
… Missing sensor(s): mic2

thermalmonitord waited for readings from a sensor that never came. The sensor name is the clue:

  • mic1, prs0 (barometer): usually the charging port flex;
  • mic2: the power button flex (secondary microphone, flash side);
  • TG0B, TG0V, TB0V: battery-related sensors.

If thermalmonitord times out but no missing sensor is listed, the iFixit wiki considers it generally a software problem.

How do I read a watchdog timeout?

userspace watchdog timeout: no successful checkins from wifid

A system process (wifid, the Wi-Fi daemon here) did not check in with the watchdog within about 180 seconds, so iOS restarted. Read the process named after "checkins from": the "service: …" list that follows often shows other services that are healthy.

Many of these timeouts are software, especially logd and SpringBoard on early iOS 16 releases. For wifid, the software cause is the best documented, with a possible Wi-Fi module fault if it persists after a clean restore. Restore before ordering a part.

How do I read an i2c error?

An i2c panic names a bus and, often, a device: for example a message ending with for device followed by a name such as audio-speaker-top or display-pmu. The bus number and the device name, read with the model's schematic, point to the flex or the component. The assignment of each bus varies by model, so check the schematic before replacing anything.

A worked example: iPhone 15 Pro Max

A customer brings an iPhone 15 Pro Max that restarts about every three minutes. The log shows:

  • bug_type 210: kernel panic;
  • product iPhone16,2: iPhone 15 Pro Max;
  • panicString: SMC PANIC … SMC BSC failure … sensor array 0 - 4 is 0, 4194304, ….

Reading: SMC family, silent sensor. 4194304 = 0x400000. On the iPhone 15 Pro and 15 Pro Max, 0x400000 points to the wireless charging coil (MagSafe, back glass). The DFRWS 2025 study reproduced this exact panic on an iPhone 15 Pro by disconnecting the coil.

Next test: check the coil flex and its connector (seating, crease, corrosion), then try a known-good back glass / coil from the same model. Pitfall: the coil sensor is paired to the logic board, so a non-Apple back glass or coil can reproduce the same panic.

What should I do next?

Whatever the reading, it gives a probable part. Confirm with a known-good part before ordering.

Frequently asked questions

Is the sensor array code in hexadecimal or decimal?›

Both exist. Some logs print 0x400000, others print 4194304: it is the same value. Convert decimal to hexadecimal before comparing it with a table.

What does a combined code like 0x300000 mean?›

Sensor array values are bitmasks. A combined code is the sum of several bits, so several sensors can be missing at once. 0x300000 = 0x100000 + 0x200000.

Can I read a panic log without the model?›

You can identify the family, but not reliably the part. The same code points to different parts on different models, so check the product field or confirm the model by hand.

What if the panicString matches nothing I know?›

It may be a software panic or a family that is not documented yet. Copy the signature, restore iOS to rule out software, and compare with other logs from the same device.