IPhone Panic Log Signature Database: Panic Strings to Failing Components
Fix smarter. Recover more.
More actions
🔒 This article is maintained by PhoneRepair.biz's automated research assistant and checked against public sources. Last reviewed: 2026-07-01. Spotted a mistake? Report an error on the talk page — or just edit the article. Suggestions from readers are reviewed before going live.
iPhone panic logs (the Template:Code files iOS writes to Settings → Privacy & Security → Analytics & Improvements → Analytics Data) are one of the most useful board-level diagnostic artifacts available to a repair technician. Buried in the header of each file is a panic string — a short line describing the fault that forced the reboot. On iOS, most kernel panics point at hardware: a failed sensor, a broken flex, a cracked solder joint, a bad rail, or a component that is now missing or mismatched after a repair. This article consolidates scattered community knowledge into a single, sortable living database that maps common panic-string tokens to the subsystems and components techs most often find at fault, focusing on iPhone 11 and newer. It is a starting point for investigation, not a lookup-and-replace parts list.
Overview
A panic string is a clue, not a diagnosis. The same token can be produced by several different faults, and the mapping between a string and a physical component is probabilistic — it varies by model, board revision, iOS version, and whether the device has been previously opened. Read every entry below with these caveats in mind:
- Panics are dominated by required-component failures. Modern iPhones refuse to run — or reboot on a watchdog — when a component the OS expects is absent, unresponsive, or reports implausible values. This is extremely common after a repair: a disturbed thermal sensor, an unseated flex, a battery whose gas-gauge/authentication data doesn't match, or a Face ID/dot-projector module swapped between devices.
- Model and board revision matter. Apple reuses subsystem names (SMC, AOP, SEP, ANS) across generations while the underlying silicon and the sensors wired to each bus change. A token that means "barometer on the lower flex" on one model may map to a differently placed sensor on another.
- Component designators (U-numbers, J-connectors) are board-specific. This article deliberately avoids quoting U-numbers for iPhone 11+ boards unless they are well established. Always verify a designator against a boardview / schematic / service documentation for the exact model and revision in front of you before removing anything.
- iOS updates change the rules. Which sensors are "required," and which trigger a watchdog reboot, has changed across iOS releases. A device that was stable can begin panicking after an update because a newly enforced sensor check now fails.
- A log tells you what the OS noticed failing — not always the root cause. A shorted rail can starve several subsystems and produce a panic that names only the first one to complain.
Treat this table as a hypothesis generator. Confirm with measurement (diode-mode, current draw, thermal imaging), boardview cross-reference, and — where possible — swapping a known-good flex/sensor before committing to a component-level repair.
Panic-string signature database
The core of this reference. Columns: Panic string / key token · Likely subsystem · Commonly reported failing component or sensor · Typical board-level repair · Affected models · Confidence · Notes / sources.
Confidence key: Established = well-documented, consistently reproduced by multiple reputable sources; Community-reported = repeatedly reported by repair techs but variable / model-dependent; Uncertain = plausible mapping, frequently ambiguous or with multiple competing causes — verify before acting.
| Panic string / key token | Likely subsystem | Commonly reported failing component / sensor | Typical board-level repair | Affected models | Confidence | Notes / sources |
|---|---|---|---|---|---|---|
| Template:Code / Template:Code / Template:Code | NAND storage controller (Apple NAND Storage) | NAND flash or its rails/PCIe link to the SoC | Reflow/reball or replace NAND; check NAND power rails; PCIe line continuity | 11 and newer | Established | Storage-subsystem panic. If the NAND itself is failing, user data is at risk; do not run repeated boot cycles before imaging. |
| Template:Code / Template:Code | NAND / memory over PCIe | NAND flash or NAND-relative power rails | Check NAND rails first; reflow/reball NAND; verify PCIe bus | 11 and newer | Established | Frequently a rail or joint problem rather than a dead die — measure before removing NAND. |
| Template:Code / Template:Code / Template:Code | NAND over PCIe bus | NAND controller / PCIe link / NAND rails | Rework NAND / PCIe path; rail check | 11 and newer | Community-reported | Storage/PCIe-path family. Prioritize a data image if the customer wants files. |
| Template:Code / Template:Code / Template:Code / SEP panic | Secure Enclave Processor | SEP-related silicon / SEP boot ROM / SEP↔AP link; often correlates with CPU/PMIC damage | Often not economically repairable; investigate CPU/PMIC rails and reflow, but manage expectations | 11 and newer | Established | SEP data is device-unique. If the SEP or its keys are truly damaged, encrypted user data is permanently unrecoverable — this is by design, not a tooling gap. See limitations below. |
| Template:Code / Template:Code / Template:Code | SMC (integrated into PMU/SoC on modern models) | A required sensor the SMC lost contact with — very often a thermal sensor on a screen, battery, or charge-port flex disturbed during repair | Reseat/replace the offending flex; repair the sensor line; confirm required sensors present for that iOS version | 11 and newer | Established | Classic post-repair reboot. The SMC reboots when it stops getting expected sensor data (e.g., thermal). Identify the named sensor token, then map it to the flex it lives on. |
| Template:Code / Template:Code / gas-gauge tokens | Thermal / battery gauge (SMC) | Battery / battery gauge / fuel-gauge line; charge-control IC on the charge path | Verify battery + gauge communication; repair charge-control / gauge line | 11 and newer | Established | Template:Code/Template:Code are battery-area thermal/gauge sensors. Common after battery swaps or when the pack/gauge isn't authenticated or seen. |
| Template:Code / Template:Code / Template:Code | AOP (Always-On Processor) sensor pipeline | A sensor on the always-on path — barometer, ambient-light, proximity, or a microphone feeding the AOP | Repair/replace the named sensor's flex; check its bus line | 11 and newer | Community-reported | AOP handles sensors without waking the main cores. The specific token after AOP (e.g. Template:Code, Template:Code) tells you which sensor — read it, don't assume. |
| Template:Code / Template:Code | AOP / barometric pressure | Barometer, typically on the lower / charge-port flex assembly near the mic | Replace/repair lower flex or charge-port assembly carrying the barometer | 11 and newer (placement varies) | Community-reported | Barometer location varies by model — verify which flex carries it before ordering parts. |
| Template:Code / Template:Code | Audio / thermal sensing | A specific microphone (each mic maps to a different flex: bottom, top, front/camera, etc.) | Repair/replace the flex carrying the named mic; check charge-port flex for bottom mics | 11 and newer | Community-reported | Mic-number → physical location mapping differs by model; confirm against service docs rather than assuming a fixed order. |
| Template:Code / Template:Code / Template:Code | Wi-Fi (WLAN) | Wi-Fi/BT module, its rails, or antenna path | Reflow/replace WLAN IC; check WLAN rails and PCIe/antenna path | 11 and newer | Established | "WLAN" in a panic almost always = Wi-Fi subsystem. Correlate with actual Wi-Fi symptoms (greyed-out toggle, no scan). |
| Template:Code / Bluetooth tokens | Bluetooth | BT portion of the combo module / its link | Rework combo IC / link | 11 and newer | Community-reported | Often shares silicon with Wi-Fi; check both. |
| Template:Code / Template:Code | Power/sleep path (multi-cause) | Wi-Fi, audio codec/amplifier, or another peripheral hanging the sleep/wake transition | Isolate by subsystem; check codec/amp and Wi-Fi first | 11 and newer | Uncertain | Genuinely ambiguous — a symptom of "something didn't wake," not a specific part. Correlate with other panics/logs. |
| Template:Code / Template:Code tokens | Power management (PMU/PMIC) | PMIC, a power rail, buck coil, or shorted downstream load | Find the shorted/out-of-spec rail; repair PMIC/coil/load | 11 and newer | Community-reported | Power-domain fault. Measure rails and current draw; a downstream short often triggers this. |
| Template:Code / Template:Code | CPU / SoC memory access | SoC solder/joint issue, buck coils, or a rail feeding the CPU; possible board flex/BGA damage | Reflow/reball SoC path; inspect for pad/joint damage; rail check | 11 and newer | Uncertain | Broad CPU-side fault. Can also be software in rare cases — correlate across multiple logs before condemning the SoC. |
| Template:Code / Template:Code / Template:Code / GPU tokens | GPU (integrated in SoC) | SoC/GPU block, GPU rail, or joint damage | Rail check; reflow SoC path | 11 and newer | Uncertain | GPU is on-die with the SoC on these models; a "GPU" panic usually implicates the SoC/rails, not a discrete part. (Note: on some legacy logs Template:Code tokens were misattributed to gyro/accel — that mapping is unreliable; treat as GPU.) |
| Template:Code / Template:Code display/camera tokens | Display or camera IOMMU (DART) | Named peripheral — camera or display — behind the DART/SMMU | Reseat/replace the named module's flex; check its bus | 11 and newer | Uncertain | Template:Code vs a camera DART names different peripherals — read the exact token. Frequently a disturbed flex after screen/camera work. |
| Template:Code / Template:Code / baseband watchdog | Cellular baseband | Baseband processor, baseband PMIC, or transceiver/RF path | Rework baseband/BB-PMIC; check RF rails | 11 and newer | Community-reported | Correlate with cellular symptoms (No Service, searching). Baseband work is model-specific and often not economical. |
| Template:Code / Template:Code / watchdogd | Userspace watchdog (multi-cause) | A required daemon stopped checking in — often thermal/sensor service starved by a missing sensor; sometimes software/iOS bug | Investigate for missing/failed sensors first; consider clean restore to rule out software | 11 and newer (reported behavior changed on 13+) | Uncertain | Very ambiguous. Can be a hardware sensor fault or an OS-level issue. Reported reboot intervals (e.g. ~180 s) and behavior have changed across iOS versions. Rule out software before board work. |
| Template:Code / firmware-assert tokens | Firmware / driver assertion | Often software or a peripheral firmware fault rather than a dead part | Restore/DFU to rule out software; then investigate named peripheral | 11 and newer | Uncertain | Don't jump to soldering — reproduce after a clean restore first. |
| Charge-controller / USB tokens (e.g. legacy Template:Code/Template:Code names) | USB/charge control (Lightning/USB-C) | Charge-control IC and its data/BM lines; charge-port flex | Rework/replace charge-control IC; repair port flex | 11+ (codenames differ by generation) | Uncertain | Codename caution: Template:Code/Template:Code are older-generation Apple codenames; the parts and names differ on iPhone 11+. Map to the actual charge-control IC for the specific model via boardview — do not assume the legacy designator applies. |
Have a verified signature this table is missing, or a correction for a mapping? Please add a row or note it on the talk page — this database is meant to be maintained by the community. Include the exact panic string, the model + board revision, iOS version, and how you confirmed the root cause.
Reading the panic string within the .ips file
The mapping table is only useful once you've correctly extracted the panic string. Modern Template:Code files begin with a small JSON header line, followed by a larger JSON body. Key fields:
- Template:Code — the human-readable panic text. This is the single most important field; the tokens in the table above appear here.
- Template:Code, Template:Code, Template:Code — context (e.g. Template:Code Template:Code is a kernel panic).
- Template:Code / build — record this; required-sensor behavior is version-dependent.
- Register dumps / backtraces / "caller" — advanced; can hint at the driver that faulted, but the Template:Code token is usually sufficient for board-level triage.
Practical workflow:
- Retrieve the log: Settings → Privacy & Security → Analytics & Improvements → Analytics Data, scroll to Template:Code (or pull from Template:Code on a device you are authorized to access at the filesystem level).
- Read the Template:Code and note every token — especially anything after Template:Code, Template:Code, Template:Code, or Template:Code.
- Record model, board revision, iOS version, and repair history (was the screen/battery/camera recently replaced?).
- Collect multiple logs, not one. Patterns across several panics are far more reliable than a single string.
How to use this reference
- Extract the panic string from the Template:Code file as above and identify the key token(s).
- Find the token in the database. Sort the table by the first column (it is a Template:Code wikitable) to jump to it.
- Read the Confidence column honestly. An Established row is a strong lead; a Community-reported or Uncertain row is a hypothesis to test, not a verdict.
- Weigh repair history heavily. If the device was recently opened, suspect a disturbed/mismatched sensor or flex (SMC/AOP/thermal/gas-gauge rows) before condemning the SoC or NAND.
- Verify before removing anything. Cross-reference any component/designator against a boardview and schematic for the exact model + revision. Measure rails in diode mode, check current draw, and thermal-image for shorts. Where practical, swap a known-good flex/sensor to confirm.
- Protect data first. For NAND/ANS/Ememory/nvme and SEP panics, stop boot-looping the device and image the storage before invasive work if the customer needs data — repeated failed boots can make matters worse, and a genuine SEP failure means the data is gone for good.
- Confirm the fix by clearing/observing new logs: a repaired device should stop generating the same panic string across normal use.
Limitations and honesty about what is unrecoverable:
- SEP failure = permanent data loss. If the Secure Enclave or its device-unique keys are physically damaged, encrypted user data cannot be recovered by any tool or technique. This is the intended security design (FBE-class protection on modern iPhones), not a limitation you can engineer around. Set customer expectations accordingly.
- A panic string never proves a single root cause. Identical strings arise from different faults; shorts cascade across subsystems.
- No test-point coordinates or pinouts are given here because they are board- and revision-specific. Fabricated coordinates cause damage — use verified boardview/service documentation for the exact device.
- Anti-theft / Activation Lock are out of scope. This reference is for diagnosing and repairing hardware faults on devices you are authorized to service. It does not cover, and must not be used to attempt, defeating Activation Lock or other anti-theft protection.
Related articles
- Reading iPhone .ips Panic Files: Fields and Structure
- iPhone SMC Panic and Thermal Sensor Faults
- Secure Enclave (SEP) Failures and Data Recovery Limits
- NAND Failure Diagnosis and Data Imaging on iPhone
- Post-Repair Reboot Loops: Sensor and Flex Mismatch
- iPhone Power Rail and PMIC Short Diagnosis
- Using Boardview and Schematics for iPhone Micro-Soldering
- iPhone AOP Sensor Pipeline and Barometer Faults
Sources
- iFixit — iPhone Kernel Panics (reading logs, WLAN/SEP/AOP/SMC/ANS token overview)
- iFixit — iPhone SMC Panic Assertion Failed (thermal sensor / post-repair reboots)
- VCC Board Repairs — Panic Log Error List
- REWA Technology — iPhone Restart / Panic Log Analysis
- 8kSec — Analyzing iOS Kernel Panic Logs (.ips structure, panicString)
- iPad Rehab — Troubleshooting iPhone Reboot Problems (missing thermal sensor reboots)
- Elektroda — Understanding Panic Full Log in iPhone/iPad (SEP/AOP/SMC discussion)
- Apple Community — Kernel panic userspace watchdog timeout
PhoneRepair.biz is a free community knowledge base. Data recovery and board-level repair carry a real risk of permanent data loss — when the data matters, back up any raw dump before modifying a device and consider a professional lab. Only work on devices you own or have documented authorization to service. See PhoneRepair:Legal notice.