Cómo leer un panic full de iPhone
Actualizado el 2026-10-14
Para leer un panic full, identifica el modelo en product (por ejemplo iPhone16,2), luego busca el panicString. Si dice sensor array, convierte el número a hexadecimal (4194304 = 0x400000) y búscalo en la tabla de ese modelo. Si dice Missing sensor(s), anota el nombre del sensor; si dice watchdog, el proceso bloqueado.
¿Cómo está organizado un archivo panic full?
Un archivo panic-full-….ips empieza con una línea de encabezado en formato JSON, seguida del cuerpo del informe. Los campos útiles para un técnico son pocos:
| Campo | Ejemplo | Para qué sirve |
|---|---|---|
bug_type |
210 |
Tipo de informe. 210 = pánico del kernel |
product |
iPhone16,2 |
Modelo interno exacto (aquí iPhone 15 Pro Max) |
os_version |
iPhone OS 18.x |
Versión de iOS en el momento del pánico |
panicString |
panic(cpu 0 caller …): … |
La causa del pánico: es lo que hay que leer |
El campo product es indispensable. El modelo comercial («iPhone 15 Pro Max») no aparece tal cual: hay que traducir el identificador interno. iPhone16,1 es el iPhone 15 Pro, iPhone16,2 el 15 Pro Max. Si el log no lo contiene (solo pegaste el panicString), indica el modelo a mano en tool.
¿Dónde está la causa del pánico?
En el panicString, que casi siempre empieza por una línea de este tipo:
panic(cpu 0 caller 0xfffffff0…): …
cpu 0indica en qué núcleo se produjo el pánico: no sirve para el diagnóstico.calleres una dirección de memoria: tampoco sirve.- Lo que sigue a los dos puntos es el mensaje que hay que interpretar.
Este mensaje pertenece a una familia (SMC, missing sensor, watchdog, AOP, NAND, SEP, I2C…). Cada familia se lee de forma distinta.
¿Cómo leer un pánico «SMC PANIC … sensor array»?
Es la familia más frecuente en los iPhone recientes que se reinician solos. Se parece a esto (extracto simplificado):
SMC PANIC - ASSERT … BSC failure … sensor array 0 - 4 is 0, 4194304 …
El número final es una máscara de bits: cada bit corresponde a un sensor obligatorio que el SMC espera. Si un sensor no responde, su bit se activa.
¿Decimal o hexadecimal?
El log puede mostrar el valor en decimal. Las tablas de técnicos lo expresan casi siempre en hexadecimal. Hay que convertir:
| Decimal | Hexadecimal |
|---|---|
| 2048 | 0x800 |
| 4096 | 0x1000 |
| 524288 | 0x80000 |
| 1048576 | 0x100000 |
| 2097152 | 0x200000 |
| 4194304 | 0x400000 |
Así, 4194304 = 0x400000. La calculadora de la Mac o de Windows en modo programador hace la conversión; el analizador lo hace automáticamente.
¿Qué pasa si faltan varios sensores?
El valor es entonces la suma (OR lógico) de varios bits. Ejemplos de nuestra base:
- iPhone 13:
0x1800=0x800(flex del puerto de carga) +0x1000(flex de sensores frontales). - iPhone 14:
0x300000=0x100000(puerto de carga) +0x200000(proximidad). - iPhone 14:
0x700000= los tres sensores obligatorios a la vez. Una falla simultánea de tres piezas apunta más bien a una oxidación o a un defecto común de la placa.
¿Por qué el mismo código cambia de sentido según el modelo?
Porque cada generación asigna los bits a su manera. Algunos ejemplos documentados:
0x100000= puerto de carga en un iPhone 14 y en un iPhone 15 Pro, pero sensores frontales en un iPhone 15 y flex del botón de encendido en un iPhone 14 Pro.0x200000= proximidad en un iPhone 15 Pro, bobina inalámbrica en un iPhone 15 o 16.0x600000= bobina + proximidad en un iPhone 14 y 15 Pro, pero puerto de carga en un iPhone 17 Pro (fuente única).
Nunca apliques una tabla de un modelo a otro. Encontrarás todas las correspondencias en table.
¿Cómo leer «Missing sensor(s)»?
Otra familia muy común, sobre todo en iPhone XS, XR, 11, 12 y SE 2020:
… thermalmonitord … Missing sensor(s): mic2
Aquí no hay código que convertir: el nombre del sensor basta. thermalmonitord ya no recibe mediciones de ese sensor y, al cabo de unos 3 minutos, iOS reinicia el iPhone. Algunos nombres frecuentes:
| Sensor | Pieza probable |
|---|---|
mic1 |
Flex del puerto de carga (micrófono inferior) |
mic2 |
Flex del botón de encendido (micrófono secundario, junto al flash) |
prs0 |
Flex del puerto de carga (barómetro) |
TG0B, TG0V |
Batería (datos del medidor) |
Ojo: en estos casos no se puede diagnosticar desconectando el flex sospechoso, porque sin él el teléfono se reinicia de todos modos. Hay que probar con una pieza que se sepa que funciona.
¿Cómo leer un «userspace watchdog timeout»?
userspace watchdog timeout: no successful checkins from wifid
Un proceso del sistema (aquí wifid, el demonio Wi-Fi) no se reportó al watchdog dentro del plazo y iOS reinició el equipo. El nombre que sigue a «checkins from» es el único implicado: los demás servicios listados debajo suelen estar sanos.
Las fuentes atribuyen estos pánicos primero al software, sobre todo en las primeras versiones de iOS 16. Actualiza o restaura iOS antes de pedir una pieza. Excepción: si el proceso es thermalmonitord y el log cita un «Missing sensor(s)», vuelve a la sección anterior.
Ejemplo real: iPhone 15 Pro Max que se reinicia cada 3 minutos
Un log recibido en taller:
product:iPhone16,2→ iPhone 15 Pro Max.panicString:SMC PANIC … sensor array … 4194304.- Conversión: 4194304 = 0x400000.
- En la tabla del iPhone 15 Pro / 15 Pro Max, 0x400000 = bobina de carga inalámbrica (flex de la tapa trasera). El estudio DFRWS 2025 reprodujo este código en un iPhone 15 Pro desconectando la bobina.
Prueba antes de reparar: revisar el flex de la bobina y su conector (encaje, dobleces, oxidación), luego probar con una tapa/bobina del mismo modelo que se sepa que funciona.
Trampa: el sensor de la bobina está emparejado con la placa. Una tapa trasera no Apple puede reproducir exactamente el mismo pánico. Usa una pieza Apple con System Configuration o, en iOS 18+, el Asistente de reparación.
¿Qué partes del log se pueden ignorar?
La mayor parte del archivo es información de depuración para los ingenieros de Apple: listas de procesos, direcciones de memoria, estados de los núcleos, módulos del kernel cargados. Para un diagnóstico de taller, puedes ignorarlas. Concéntrate en product, os_version y en las primeras líneas del panicString. Si comparas varios logs del mismo equipo, compara solo esas líneas: si son idénticas, la causa es la misma.
¿Y si no reconozco la familia?
Algunos pánicos son poco específicos (Kernel data abort, undefined kernel instruction) y se resuelven más a menudo con una restauración que con una pieza. Otros apuntan a la placa (NAND, SEP, SoC). Suelta tu log en tool: si la firma no está en la base, el analizador te lo dice en lugar de inventar una respuesta. Para el contexto general, lee Qué es un panic full de iPhone y qué significa.