Where do the rules come from?

From public, citable sources: iFixit wikis and Answers threads, the DFRWS APAC 2025 study, Repair Wiki, iPad Rehab, REWA and repair forums. A rule without a source is not added to the database.

What does a disputed code mean?

Sources disagree on the part for that code and model. Both readings are shown so you can test them in order, with a known-good part.

Does the tool use AI to diagnose?

The diagnosis comes from the sourced rules. When a rule is only a reasoned hypothesis without a repair source yet, it is clearly marked “AI, unconfirmed” and given low confidence until a source or a field case confirms it.

Can I contribute a repair case?

Yes. Field cases improve the database for everyone. Tell us what you found and what fixed it.

Our methodology

Updated 2026-10-14

Check Panic Full matches the signature of a panic-full log against 111 rules. Every rule cites at least one source: iFixit wikis and Answers, the DFRWS APAC 2025 module-disconnection study, Repair Wiki and repair forums. Each rule has a confidence level, disputed codes show both readings, and the result is always a probable part to confirm.

How does the analysis work?

When you drop a panic-full file, the analyzer:

Reads the header to get the model identifier (product) and the iOS version.
Extracts the signature from the panicString: the panic family, then the code, the missing sensor, the process or the bus device.
Matches it against the database for that exact model.
Shows the probable part in 3D, with an explanation, the next test to run and the repair pitfalls.

The key of a rule is the model + the panic type + the normalised code. That matters because the same code points to different parts on different models: 0x200000 is the proximity sensor on an iPhone 14 and the wireless coil on an iPhone 15.

When several logs from the same device are analyzed together, the result shows the trend across them. A repeated signature is a much stronger clue than a single panic.

Where do the 111 rules come from?

Every rule cites at least one source. No diagnosis is written "from memory". The main sources are:

iFixit: wikis (including the SMC panic table and its sensor reference) and Answers threads with resolved cases.
DFRWS APAC 2025: Song, Yang, Lee et al., A study on the recovery of damaged iPhone hardware exhibiting panic full phenomena. The authors disconnected modules one by one on several iPhones and recorded the resulting codes. These controlled tests are the most reliable source for sensor array values.
Repair Wiki and iPad Rehab: model-specific guides written by repairers.
REWA and repair forums (Apple Community, Apple Developer Forums, Elektroda and others) for families such as AOP, NAND, i2c and watchdog timeouts.

The sources are listed on every code page.

What do the confidence levels mean?

Level	Meaning
High	Several concordant sources, or a controlled test (DFRWS) confirmed by another source
Medium	One good source, or several sources with nuances
Low	Isolated case, single source, extrapolation from a close model or a recent model with little data

Each rule also has a status:

Verified source: the rule comes directly from a cited source.
Disputed: sources disagree.
AI, unconfirmed: suggested by an AI analysis, waiting for confirmation.
Confirmed in the field: backed by repair cases reported by technicians.

How are disputed codes handled?

Some codes are read differently by different sources. Rather than pick one silently, the tool shows both readings and says which source supports which. A few examples:

On an iPhone 14, 0x500000 is charging port + wireless coil according to the DFRWS disconnection test, but the battery according to iFixit and iPad Rehab.
On the iPhone 13 series, the iFixit table gives 0x10000 for the front sensors, while Repair Wiki, iPad Rehab and iFixit's own multi-fault example give 0x1000. The extra zero is probably a typo.
On an iPhone 14 Pro, iPad Rehab gives 0x10000 for the power button flex where other sources give 0x100000.

In those cases, test the parts in the suggested order, each with a known-good part.

What are field cases?

A field case is a repair reported by a technician: the log, the part replaced, and whether the panics stopped. Field cases confirm or contradict a rule over time. When you repair a device diagnosed by the tool, telling us what worked improves the database for everyone.

What happens to the logs?

Before a log is stored, device identifiers are removed: the crashReporterKey, the incident / report number and other identifiers. What remains is the technical content needed to improve the rules. Details are in the Privacy Policy | Check Panic Full policy.

What are the limits?

A log guides the repair, it doesn't replace it. The tool gives a probable part. Always confirm with a known-good part before ordering.
Coverage is incomplete. Recent models have less data; some families are not documented yet. An unknown signature is reported as such rather than guessed.
Codes don't carry over between generations. A rule for one model is not applied to another unless a source says so.
Several causes can share one signature. A corroded connector or a board trace can produce the same code as a dead flex.
Software panics exist. A watchdog on a software process often needs a restore, not a part.

To browse the rules directly, see the codes hub or the full table.