Como ler panic log do iPhone (guia prático pra técnico de bancada)

Se você abre o iPhone do cliente e ele "liga, dá Apple e reinicia em loop", boa chance de você estar diante de um kernel panic. A boa notícia é que o iPhone deixa um arquivo de log com pistas suficientes pra você localizar o CI culpado — desde que saiba onde procurar e como ler.

Este guia é o passo a passo que usamos na bancada.

O que é um panic log

Quando o sistema operacional do iPhone (iOS) encontra um erro crítico que não consegue contornar, ele trava o kernel e grava um arquivo de texto com o estado da máquina naquele instante: que processo causou, qual subsistema, e — em muitos casos — qual componente de hardware estava envolvido.

Esse arquivo é o panic log. Eles ficam em:

Configurações → Privacidade → Análise → Dados de Análise

Filtrando por nomes que começam com panic-full- ou panic-base-.

Tipos de panic relevantes

Nem todo panic vem do hardware. Os 3 tipos que interessam pro técnico:

Se você ver muito stacks, o aparelho provavelmente vai melhorar com restauração. Se for panic-full ou panic-base repetindo, é hora de abrir.

O que procurar no log

Abra o panic full num editor de texto. Use o atalho Ctrl+F (ou Cmd+F no Mac) e procure por essas palavras-chave, em ordem:

1. "reason":

Mostra o motivo geral do panic. Exemplos comuns:

• Kernel data abort — acesso de memória inválido. Pode ser RAM/NAND ou CPU.
• WDT timeout — watchdog timer. Algum subsistema travou.
• SOC: ... — falha de algum block do System-on-Chip.

2. "panicString":

Esse é o ouro. Geralmente tem o subsistema que falhou:

• AppleS5L8960XIO → CPU/iBoot
• AppleSPMI → barramento de PMIC
• AppleARMNandLayer → NAND
• AppleBasebandPCIeSS → baseband (modem)
• AppleSEPManager → SEP (Secure Enclave)
• AppleM68Audio → CODEC de áudio

3. "otherString":

Detalhes adicionais. Às vezes traz o nome do registrador ou pad que falhou.

4. Endereços e códigos hex

Códigos como 0x803BEBCDE ajudam a casar com bases de panic conhecidas. É aqui que ferramentas como o iPANICS brilham — fazemos esse cruzamento por você em segundos.

Mapeando subsistema → CI

Identificou o subsistema? Agora é casar com o CI físico no esquemático. Atalho mental:

Cada modelo de iPhone tem números diferentes — não decora. Use o BoardView pra confirmar.

Exemplo real

Cliente trouxe um iPhone 11 Pro com restart loop. O panic full tinha:

"reason": "Kernel data abort",
"panicString": "AppleARMNandLayer kext failed to read block",

Subsistema: NAND. Caminho de investigação:

1. Conferi consumo na fonte de bancada: 90mA constante (alto pra esse modelo)
2. Verifiquei alimentação da NAND nos pads: OK
3. Medi diodo dos pads do Tristar (U6300) → curto pra terra em um deles
4. Substituí o Tristar → aparelho voltou a iniciar

Esse caso levou 40 minutos. Sem o panic log, teria sido 2 horas de "chutômetro".

Atalho: análise automática com iPANICS

Toda essa interpretação manual é o que o iPANICS faz em segundos:

1. Você cola o panic full no painel
2. A IA identifica subsistema, mapeia pro CI correspondente do modelo correto
3. Você recebe: causa provável, CI culpado, checklist de medições, próximos passos

E pelo robô do WhatsApp dá pra mandar até foto do panic em print — a gente extrai e analisa.

Testa grátis por 7 dias →

Erros comuns na hora de ler panic

• Achar que panic = hardware sempre. Stacks panic geralmente é app/iOS.
• Esquecer de pegar o panic mais recente. O iPhone guarda vários — pegue o do dia.
• Ignorar o "reason". O texto curto no topo já te dá 70% da pista.
• Trocar CI sem medir antes. Panic indica subsistema. Confirme com fonte/diodo antes de aquecer.

Conclusão

Panic log é a melhor pista que o cliente vai te entregar de graça. Em 5 minutos de leitura você corta horas de tentativa e erro. Se quiser pular essa etapa de leitura manual e ir direto pro componente culpado, a gente tá aqui.

Quer aprofundar? Veja também:

• iPhone 11 reinicia sozinho: panic codes mais comuns
• Fórum: casos reais de panic resolvidos