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_type210: kernel panic;productiPhone16,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?
- Not sure about a code? Drop the file into the tool: it reads the header, extracts the signature and matches it for the exact model.
- Want the full list? See the codes hub.
- Diagnosing a loop? Read iPhone Restarts Every 3 Minutes: Why and How to Fix.
Whatever the reading, it gives a probable part. Confirm with a known-good part before ordering.