Kernel Panic e Reinicializações Aleatórias no macOS Tahoe 26.5: Leia o Log de Pânico e Resolva o Problema

macOSTahoe ·
Kernel Panic e Reinicializações Aleatórias no macOS Tahoe 26.5: Leia o Log de Pânico e Resolva o Problema

Mac com kernel panic ou reinicializando no macOS Tahoe 26.5? Leia o log de pânico e corrija causas relacionadas a taxa de atualização, extensões de kernel, sleep/wake e periféricos.

Você está no meio de uma frase em um documento, renderizando uma linha do tempo, ou simplesmente lendo uma página da web, e a tela fica preta. Alguns segundos depois, seu Mac está na janela de login com um diálogo que diz "Seu computador foi reiniciado por causa de um problema." Isso é um kernel panic, e no macOS Tahoe 26.5 ele se tornou uma das reclamações mais relatadas — "a máquina inteira simplesmente morreu" — em fóruns de suporte e threads de desenvolvedores. Um kernel panic não é um app travando — é o núcleo do sistema operacional decidindo que continuar seria inseguro, então ele para tudo e reinicia.

A boa notícia é que um kernel panic no Mac quase sempre deixa uma impressão digital: um relatório de pânico. Enterrado nesse relatório está um panicString, um backtrace e uma lista de extensões de kernel que estavam na memória quando a falha aconteceu. Quando você consegue ler essas três coisas, você para de adivinhar e começa a diagnosticar. Este guia foi construído em torno dessa habilidade. Vamos ler um relatório de pânico real linha por linha e, em seguida, percorrer uma árvore de decisão que mapeia o que você encontra para os gatilhos mais comuns do Tahoe 26.5 — altas taxas de atualização em monitores externos, extensões de kernel e de sistema, falhas de sleep/wake com periféricos, os itens de hardware que a própria Apple reconheceu na versão 26.5 e estado corrompido do sistema.

O macOS Tahoe 26.5 foi lançado em 2026-05-11 e, como qualquer atualização de ponto, corrigiu alguns problemas e revelou outros. As notas de lançamento enterprise da Apple reconheceram correções de reinicialização afetando os modelos M5 MacBook Air e M5 Pro/Max, extensões de rede de filtro de conteúdo causando reinicializações e uma condição de tela preta após a atualização. Esse contexto importa porque diz que a Apple sabe que existem regressões de estabilidade no nível do kernel nessa geração. Mas nem todo pânico é um bug da Apple para corrigir — muitos são causados por um monitor de terceiros rodando rápido demais, um kext de VPN antigo ou um hub Thunderbolt com problemas. O log de pânico é como você distingue um do outro.

Pontos Principais

  • Um kernel panic é uma reinicialização de todo o sistema disparada pelo núcleo do SO, não um crash de app — e sempre grava um relatório de pânico em /Library/Logs/DiagnosticReports/ que nomeia a causa provável.
  • Leia três campos primeiro: o panicString (o motivo legível por humanos), o backtrace (qual processo/driver estava rodando) e "Kernel Extensions in backtrace" (drivers de terceiros implicados).
  • A correção mais limpa e confirmada pela comunidade para o Tahoe 26.5 é reduzir um monitor externo de terceiros de 120/144/240 Hz para 60 Hz — pânicos de GPU/display por alta taxa de atualização no Mac Studio e Mac mini são generalizados e se resolvem imediatamente quando a taxa é reduzida.
  • Audite extensões de kernel e de sistema com kmutil showloaded e systemextensionsctl list, depois inicialize no Safe Mode para provar se uma extensão de terceiros é o gatilho; ferramentas de VPN, antivírus e virtualização são os suspeitos habituais.
  • A Apple reconheceu correções de reinicialização no 26.5 para M5 MacBook Air / M5 Pro e Max, extensões de filtragem de conteúdo e tela preta após atualização; pânicos restantes são relatados pela comunidade com soluções alternativas, portanto atualize completamente e isole metodicamente antes de presumir falha de hardware.

Kernel Panic vs. Crash de App vs. Travamento: Saiba o que Você Está Vendo

Antes de abrir um único log, entenda a terminologia corretamente, porque o caminho de correção é completamente diferente para cada caso.

Um kernel panic é uma falha dentro do kernel XNU — a camada mais baixa do macOS que fala diretamente com a CPU, GPU, controlador de memória e drivers. Quando o kernel chega a um estado do qual não consegue se recuperar com segurança (um acesso de memória inválido em um driver, uma falha de hardware, um deadlock em um caminho crítico), ele intencionalmente para todo o sistema e reinicia. O sinal inconfundível é o diálogo pós-reinicialização: "Seu computador foi reiniciado por causa de um problema. Pressione uma tecla ou aguarde alguns segundos para continuar iniciando." Em Macs mais antigos ou Intel, você pode ver brevemente uma tela escurecida com "Você precisa reiniciar seu computador. Mantenha pressionado o botão Liga/Desliga..." em vários idiomas. De qualquer forma, a máquina inteira caiu, não apenas um app.

Um crash de app é um único processo encerrando inesperadamente. O restante do macOS continua rodando, você recebe um diálogo "[App] encerrou inesperadamente" com botões Reabrir/Relatar, e pode continuar usando tudo mais. Crashes de app também gravam relatórios .crash ou .ips, mas estão limitados a um processo. Se suas abas do Safari morrem, mas o Dock, o Finder e outros apps continuam funcionando, isso é um crash de app, não um pânico — e é coberto pelo nosso guia separado sobre crashes de abas do Safari no macOS Tahoe 26.5.

Um travamento ou hang é quando o sistema para de responder, mas não reinicia. O cursor pode virar um beachball giratório, a tela fica congelada e nada reage — mas não há reinicialização automática. Um hang pode às vezes preceder um pânico (o kernel trava, então dispara um watchdog que força uma reinicialização), mas um hang puro você precisa forçar o desligamento manualmente. O diagnóstico para hangs é diferente — spindump, "sample process" do Activity Monitor e log show para o período antes do hang.

Aqui está a decisão rápida:

  • Máquina toda reiniciou sozinha + diálogo "reiniciado por causa de um problema" → kernel panic. Leia o relatório de pânico. Isso é este guia.
  • Um app encerrou, restante do sistema ok → crash de app. Veja o relatório .ips daquele app.
  • Sistema congelado, sem reinicialização, você teve que forçar o desligamento → hang. Conjunto de ferramentas diferente.

Acertar isso economiza horas. Pessoas passam dias reinstalando apps para corrigir um "crash" que era na verdade um kernel panic causado por um monitor de 240 Hz.

Como Encontrar e Ler o Relatório de Pânico

Todo kernel panic no macOS grava um relatório de diagnóstico. Há duas formas de acessá-lo: Console.app (gráfico) e o sistema de arquivos / Terminal (mais rápido e programável).

Onde ficam os logs de pânico

Os relatórios de pânico são armazenados aqui:

# Relatórios de diagnóstico por máquina (kernel panics ficam aqui)
ls -lt /Library/Logs/DiagnosticReports/ | head -20

Você está procurando arquivos nomeados como Kernel-2026-05-22-143012.panic ou panic-full-2026-05-22-143012.ips. Os mais recentes ficam no topo por causa do -lt (ordenar por tempo). No Apple silicon, versões recentes do macOS gravam um relatório panic-full mais rico; em sistemas mais antigos você pode ver arquivos de texto .panic. Há também uma pasta no nível do usuário, mas kernel panics são do sistema todo e vão em /Library/Logs/DiagnosticReports/.

Para listar apenas relatórios relacionados a pânico:

ls -lt /Library/Logs/DiagnosticReports/ | grep -iE 'panic|kernel'

Abrindo um relatório de pânico no Console.app

Se preferir uma interface gráfica:

  1. Abra o Console (Aplicativos → Utilitários → Console, ou Spotlight "Console").
  2. Na barra lateral esquerda em Relatórios, clique em Crash Reports (macOS mais antigo) ou System Reports.
  3. Role para encontrar entradas que começam com Kernel ou contêm panic no nome. Clique em uma.
  4. O relatório completo aparece à direita. Use Cmd+F para ir para panicString.

O Console é conveniente, mas ler o arquivo bruto geralmente é mais rápido porque você pode pesquisar imediatamente e copiar tudo.

O log unificado ao vivo

O arquivo de pânico é gravado no momento da falha. Você também pode extrair mensagens relacionadas a pânico do log unificado, o que é útil quando você quer ver o que aconteceu nos segundos antes da reinicialização:

# Mostrar mensagens relacionadas a pânico do último dia
log show --predicate 'eventMessage contains "panic"' --last 1d
# Restringir ao processo kernel e às últimas 6 horas, mais útil logo após um pânico
log show --predicate 'process == "kernel"' --last 6h | grep -i panic

O log unificado não contém o backtrace completo da forma como o arquivo .panic contém, mas fornece contexto de tempo — o que o sistema estava fazendo antes do evento.

Anatomia de um relatório de pânico: um exemplo anotado

Esta é a parte que transforma você de um adivinhador em um diagnosticador. Um relatório de pânico tem uma estrutura previsível. Aqui está uma panicString representativa (sanitizada e ilustrativa) do Apple silicon do tipo que as pessoas veem com problemas de display de alta taxa de atualização:

panic(cpu 4 caller 0xfffffff0291a7c40): userspace watchdog timeout:
no successful checkins from com.apple.WindowServer in 120 seconds
service: com.apple.logd, total successful checkins since load
(831 seconds ago): 83, last successful checkin: 0 seconds ago
service: com.apple.WindowServer, total successful checkins since
load (831 seconds ago): 8, last successful checkin: 120 seconds ago

Panic occurred in process WindowServer

Backtrace (CPU 4), panicked thread: 0xfffffff...
...
AppleH13CamIn ... AGXG16X ... IOMobileFramebuffer ...

Kernel Extensions in backtrace:
   com.apple.iokit.IOMobileFramebufferFamily
   com.apple.AGXG16X

Leia de cima para baixo:

  • panic(cpu 4 caller 0x...) — qual núcleo de CPU entrou em pânico e o endereço do código que chamou o pânico. Os endereços hexadecimais não são para você; as palavras depois deles são.
  • userspace watchdog timeout: no successful checkins from com.apple.WindowServer in 120 seconds — esta é a panicString, a linha mais importante. Ela diz por quê. Aqui, o WindowServer (o processo de exibição/composição) parou de responder ao watchdog, o que forçou uma reinicialização. Um WindowServer travado é clássico para problemas de display/GPU — frequentemente uma taxa de atualização muito alta.
  • Panic occurred in process WindowServer — o "processo no backtrace." Este é o processo que estava na CPU. WindowServer = gráficos. Um daemon de rede = rede/filtro de conteúdo. kernel_task apenas = geralmente hardware ou uma falha profunda de driver.
  • Símbolos do backtrace — nomes de função que estavam na pilha. Ver AGXG16X, IOMobileFramebuffer, AppleH13... aponta para a pilha de GPU/display da Apple.
  • Kernel Extensions in backtrace: — esta é a prova concreta para drivers de terceiros. Se você vê algo como com.yourvpn.tun ou com.thirdparty.av aqui, um kext está implicado. Se você vê apenas extensões com.apple.*, a falha está no próprio código da Apple ou é impulsionada por hardware/configuração em vez de um kext de terceiros.

Outros padrões de panicString e o que geralmente significam:

  • Sleep Wake failure in EFI ou Previous Sleep Wake failure — um pânico de sleep/wake. Quase sempre um periférico, hub ou monitor externo que se comporta mal durante o wake. (CAUSA 3 abaixo.)
  • Kernel data abort / DAR ... com um kext de terceiros no backtrace — um driver referenciou memória inválida. Suspeite desse kext.
  • KP / machine check, ECC ou pânicos sem kext de terceiros e processos inconsistentes — aponta para hardware (RAM, temperatura). (CAUSA 5.)
  • watchdog timeout ... WindowServer repetidamente, apenas quando um monitor específico está conectado — display/taxa de atualização. (CAUSA 1.)

A disciplina única que importa: leia a panicString primeiro, depois verifique se algum kext não-Apple aparece em "Kernel Extensions in backtrace." Esses dois dados pontos encaminham você para a causa certa em mais de 80% das vezes.

A Árvore de Decisão de Diagnóstico

Use este fluxo sempre. Ele evita reinstalações aleatórias.

  1. Reproduza ou anote o padrão. O pânico acontece apenas quando um monitor externo está conectado? Apenas ao acordar do sleep? Apenas quando um app ou VPN específico está rodando? Aleatoriamente, sem nada em comum? O padrão é metade do diagnóstico. Anote.
  2. Leia o relatório de pânico mais recente. Obtenha a panicString e a lista "Kernel Extensions in backtrace" (veja acima).
  3. Há um kext de terceiros no backtrace?
    • Sim → vá para CAUSA 2 (extensões). Identifique o fornecedor, atualize ou remova-o, teste novamente no Safe Mode.
    • Não → continue.
  4. A panicString menciona WindowServer / framebuffer / GPU, e isso só acontece com um monitor conectado? → CAUSA 1 (taxa de atualização). Reduza o monitor externo para 60 Hz primeiro.
  5. A panicString menciona Sleep Wake failure, ou isso só acontece no wake? → CAUSA 3 (sleep/wake + periféricos). Desconecte tudo e teste.
  6. Você está em um M5 MacBook Air / M5 Pro/Max, ou usa uma extensão de rede de filtro de conteúdo, ou viu tela preta após atualizar? → CAUSA 4 (itens 26.5 reconhecidos pela Apple). Certifique-se de estar totalmente atualizado.
  7. Sem kext de terceiros, sem padrão de display/sleep, pânicos são aleatórios e o relatório varia a cada vez? → CAUSA 5 (hardware). Execute o Apple Diagnostics, verifique RAM/eGPU/temperatura.
  8. Ainda não resolvido após o acima? → CAUSA 6 (estado corrompido do sistema): redefina NVRAM, redefina SMC (Intel), reinstale o macOS no lugar.

Agora as causas em detalhes.

CAUSA 1: Alta Taxa de Atualização do Monitor Externo (120 / 144 / 240 Hz)

Este é o problema de destaque do Tahoe 26.5 e, felizmente, o que tem a correção mais limpa. Uma grande parte dos relatos de "reinicialização aleatória" no Mac Studio e Mac mini acaba sendo pânicos de watchdog de GPU/display acionados quando um monitor de alta taxa de atualização de terceiros é conduzido a 120 Hz, 144 Hz ou 240 Hz. O relatório de pânico mostra um timeout de watchdog do WindowServer com a pilha de GPU/framebuffer da Apple (AGX..., IOMobileFramebuffer) no backtrace, exatamente como no exemplo anotado acima.

Por que isso acontece

Em altas taxas de atualização, o driver de GPU e o controlador de display trocam informações de temporização, modo e sincronização de forma muito mais agressiva do que a 60 Hz. As atualizações de ponto do macOS periodicamente alteram o pipeline de display (tratamento de HDR, negociação de taxa variável / ProMotion, dithering, multi-stream sobre DisplayPort/Thunderbolt). Quando o firmware de um monitor de terceiros anuncia um modo que o driver atual não negocia bem — ou quando o cabo/link DSC é marginal a 240 Hz — o lado da GPU pode travar. O WindowServer para de fazer check-ins, o watchdog dispara na marca de 120 segundos e todo o sistema reinicia. Parece aleatório porque depende do que está na tela, mas está vinculado ao display.

Sinais que apontam para a taxa de atualização:

  • Os pânicos nunca acontecem somente na tela integrada (laptops) ou sem o monitor externo conectado (usuários de Mac mini/Studio que também têm uma pequena tela secundária podem testar).
  • A panicString menciona watchdog do WindowServer e o backtrace lista apenas kexts de GPU/framebuffer da Apple (sem kext de terceiros).
  • É pior durante trabalhos pesados de GPU, vídeo, conteúdo HDR ou ao acordar do sleep do display.
  • Um monitor ou cabo específico de alta taxa de atualização está envolvido; trocar de volta para uma tela de 60 Hz faz o problema desaparecer.

A correção limpa: reduza a taxa de atualização

Esta é uma solução alternativa robusta e confirmada pela comunidade. Reduzir a taxa de atualização elimina completamente o caminho de temporização marginal.

  1. Abra Configurações do Sistema → Monitores.
  2. Selecione o monitor externo.
  3. Encontre o menu suspenso Taxa de Atualização. Mude de 240 Hz → 120 Hz, ou para mais estabilidade, → 60 Hz.
  4. Se você vir um botão de alternância ProMotion / Taxa de atualização variável, defina-o para uma taxa fixa em vez de variável durante os testes.
  5. Use o display por um dia. Se os pânicos pararem, a taxa de atualização era a causa.

Seletor de taxa de atualização nas configurações de monitores do macOS Tahoe

Se o painel de Monitores do macOS não expõe a taxa que você quer, ou oculta etapas intermediárias, o SwitchResX (um utilitário de display de terceiros antigo) permite definir temporização exata e bloquear uma taxa de atualização. Defina um modo limpo de 60 Hz ou 120 Hz e salve-o como padrão para esse display.

Outros recursos que ajudam com a estabilidade de alta taxa de atualização:

  • Use um cabo certificado. A 144/240 Hz você precisa de um cabo DisplayPort ou Thunderbolt 4 / USB4 genuinamente de alta largura de banda. Um cabo marginal que "funciona" a 60 Hz falhará intermitentemente a 240 Hz. Troque o cabo antes de culpar o software.
  • Conecte diretamente, não por um dock, durante os testes. Docks e hubs DisplayPort MST adicionam uma camada de negociação que pode ser o elo fraco.
  • Desative o HDR no monitor externo temporariamente; o pipeline HDR adiciona complexidade de temporização.
  • Atualize o firmware do monitor se o fabricante oferecer isso. Fornecedores de displays enviam correções para bugs de negociação com o Mac.

Como a correção é tão limpa, tente isso primeiro sempre que um pânico ocorrer apenas com um monitor externo conectado. Se reduzir para 60 Hz parar os pânicos, você tem sua resposta e pode decidir se fica em uma taxa segura, tenta 120 Hz ou aguarda uma atualização futura de macOS/firmware. Para o conjunto mais amplo de problemas de display externo no Tahoe, consulte nosso guia de diagnóstico de display externo não detectado.

CAUSA 2: Extensões de Kernel e Sistema Defeituosas ou Desatualizadas

Se um kext de terceiros aparecer em "Kernel Extensions in backtrace," você encontrou sua categoria de culpado. Os ofensores habituais no Tahoe são clientes VPN, agentes de antivírus / segurança de endpoint, ferramentas de virtualização, drivers de interface de áudio e utilitários de disco/RAID — qualquer coisa que instale uma extensão de kernel (kext) ou uma extensão de sistema para se conectar profundamente ao SO.

A Apple tem impulsionado os desenvolvedores a migrar dos kexts antigos para extensões de sistema no espaço do usuário há anos, e cada versão do macOS restringe o que os kexts legados podem fazer. Um kext construído para um sistema mais antigo pode referenciar memória de uma forma que o novo kernel não espera, e o resultado é um pânico Kernel data abort nomeando aquele kext.

Etapa 1: Faça um inventário do que está carregado

Liste as extensões de kernel atualmente na memória:

# Mostrar todas as extensões de kernel carregadas
kmutil showloaded
# Filtrar as extensões da Apple para ver apenas as de terceiros
kmutil showloaded | grep -v com.apple

Qualquer coisa nessa lista filtrada é um driver de terceiros rodando em seu kernel agora. Compare com os IDs de bundle na lista "Kernel Extensions in backtrace" do seu relatório de pânico — uma correspondência é seu principal suspeito.

Agora liste as extensões de sistema (o equivalente moderno no espaço do usuário usado por VPNs, filtros de conteúdo e segurança de endpoint):

# Listar extensões de sistema instaladas e seu estado (activated/enabled)
systemextensionsctl list

Terminal listando extensões de kernel carregadas

Isso mostra cada extensão de sistema, seu identificador de equipe e se está activated enabled. VPNs e filtros de conteúdo instalam extensões de rede aqui — e como observado na CAUSA 4, extensões de rede de filtro de conteúdo foram especificamente mencionadas nas correções de reinicialização do 26.5 da Apple.

Etapa 2: Prove com o Safe Mode

O Safe Mode inicializa o macOS com kexts de terceiros e muitos itens de inicialização desativados. Se os pânicos pararem no Safe Mode, a causa é quase certamente algo que o Safe Mode desativou — muito provavelmente uma extensão de terceiros.

Apple silicon (M1/M2/M3/M4/M5):

  1. Desligue completamente.
  2. Pressione e segure o botão de energia até que "Carregando opções de inicialização" apareça.
  3. Selecione seu disco de inicialização, depois segure Shift e clique em Continuar no Safe Mode.
  4. Faça login. Você deve ver "Safe Boot" na barra de menus (verifique na janela de login ou em Configurações do Sistema).

Intel:

  1. Desligue.
  2. Ligue e imediatamente segure Shift até que a janela de login apareça, depois solte.

Use o Mac no Safe Mode da forma que normalmente desencadeia pânicos (conecte o monitor, execute a rede da VPN — note que algumas extensões de rede não vão carregar no Safe Mode, o que é em si informativo). Sem pânicos no Safe Mode → software de terceiros é a causa. Reinicie normalmente para confirmar que eles retornam.

Etapa 3: Remova ou atualize a extensão problemática

Uma vez identificado o suspeito:

  1. Atualize-o primeiro. O fornecedor pode já ter lançado uma versão compatível com o Tahoe. Atualizar é menos disruptivo do que remover.
  2. Se a atualização não ajudar, desinstale-o usando o desinstalador oficial do fornecedor (não arrastando para a Lixeira — kexts e extensões de sistema precisam de remoção adequada para se desregistrarem corretamente).
  3. Após remover uma extensão de sistema, pode ser necessário reaprovação ou remoção completa em Configurações do Sistema → Privacidade e Segurança, onde o macOS lista extensões aguardando permissão ou pendentes de remoção. Aprove as que você confia; remova as que não confia.
  4. Reinicie e teste novamente por um dia.

Categorias comuns a examinar, em ordem aproximada de frequência com que causam pânicos no Tahoe: clientes VPN (especialmente kexts de túnel mais antigos), agentes de antivírus/EDR, virtualização (kexts de hypervisor mais antigos), drivers de interface de áudio e utilitários de disco/criptografia de terceiros. Se você executar vários, remova-os um por vez para aprender qual era o responsável em vez de eliminar toda a sua pilha de uma vez.

CAUSA 3: Pânicos de Sleep / Wake com Periféricos e Hubs

Se o pânico acontece ao acordar do sleep — você abre a tampa ou move o mouse, a tela pisca e a máquina reinicia em vez de acordar — e especialmente se a panicString diz "Sleep Wake failure," o gatilho é quase sempre algo conectado ao Mac que não negocia a transição de sleep/wake corretamente. Docks Thunderbolt, hubs USB, drives externos, interfaces de áudio, leitores de cartão e certos displays são os infratores recorrentes.

Confirme que é um pânico de sleep/wake

Duas verificações:

# Veja o histórico de sleep/wake; entradas "Failure" indicam problemas de wake
pmset -g log | grep -iE 'failure|wake|sleep' | tail -40

pmset -g log é o log de eventos de gerenciamento de energia. Procure eventos Wake seguidos de Failure, ou notas "Previous Sleep Wake failure". Compare isso com o timestamp do relatório de pânico — se o horário do pânico coincidir com um evento de wake, você tem um pânico de sleep/wake.

# Ver quais asserções e dispositivos estão envolvidos nas transições de energia
pmset -g assertions

Corrija

  1. Desconecte tudo e teste a máquina por conta própria. Desplugue todos os hubs, docks, drives e periféricos não essenciais. Deixe o Mac dormir e acordar repetidamente por um dia. Se os pânicos pararem, um periférico é a causa.
  2. Reconecte um dispositivo por vez, aguardando um dia entre cada um, até que o pânico retorne. O último que você adicionou é o culpado.
  3. Alimente o hub/dock externamente. Hubs alimentados pelo barramento que dependem do Mac são uma fonte frequente de pânicos no wake. Um hub autoalimentado (alimentado pela rede elétrica) frequentemente resolve o problema.
  4. Atualize o firmware do dock/hub e o Mac para o build 26.5 mais recente. Correções de firmware Thunderbolt são reais.
  5. Tente uma porta diferente ou uma conexão direta. Mova o dispositivo problemático de uma cadeia daisy-chain.
  6. Como solução alternativa, ajuste o comportamento de sleep enquanto isola o dispositivo — por exemplo, impeça que o display adormeça os discos, ou use pmset para ajustar wake-on-network se um dispositivo de rede estiver acordando o Mac em um estado inválido. Faça isso apenas para ganhar tempo; a correção real é identificar o periférico.

Pânicos de sleep/wake são tediosos de diagnosticar com precisão porque requerem esperar entre os testes, mas o método de desconectar e reconectar é confiável. Resista à tentação de reinstalar o macOS para um pânico de sleep/wake — é um problema de negociação de periférico com muito mais frequência do que um problema de corrupção do SO.

CAUSA 4: Os Itens de Hardware e Enterprise Reconhecidos pela Apple no 26.5

O macOS Tahoe 26.5, lançado em 2026-05-11, incluiu correções de estabilidade que a Apple documentou em suas notas de lançamento enterprise. Conhecer esses itens ajuda a separar "já corrigido se eu atualizar" de "ainda aberto, precisa de solução alternativa."

O que a Apple reconheceu e abordou no 26.5:

  • Problemas de reinicialização nos modelos M5 MacBook Air e M5 Pro / Max. A Apple enviou correções para reinicializações inesperadas afetando essas máquinas com Apple silicon mais recentes. Se você está em um desses modelos e estava tendo pânicos em um build anterior, certificar-se de que está na versão completa 26.5 (ou posterior) é o primeiro passo.
  • Reinicializações causadas por extensões de rede de filtro de conteúdo. Reinicializações vinculadas a extensões de rede de filtro de conteúdo — comuns em ambientes gerenciados/enterprise e em algumas ferramentas de VPN/controle parental para consumidores — foram tratadas. Isso se sobrepõe com a CAUSA 2: se seu systemextensionsctl list mostra uma extensão de rede de filtro de conteúdo e você está tendo pânicos, atualize tanto o macOS quanto o app do fornecedor dessa extensão.
  • Tela preta após atualização. Uma condição em que alguns Macs exibiam uma tela preta após a atualização foi tratada.

O enquadramento honesto: a Apple corrigir uma classe de reinicializações não significa que toda instância sumiu. Alguns usuários em hardware afetado, ou rodando extensões específicas, continuam relatando reinicializações após a atualização — essas são relatadas pela comunidade e tratadas com as soluções alternativas neste guia (atualização completa, reduzir taxa de atualização, auditar extensões, isolar periféricos), não com um patch garantido da Apple. Portanto:

  1. Atualize completamente. Configurações do Sistema → Geral → Atualização de Software. Instale o 26.5 completamente (e qualquer suplemento 26.5.x que se seguir).
  2. Então teste novamente. Uma parcela significativa dos pânicos em hardware M5 e configurações de filtro de conteúdo simplesmente desaparece após a atualização completa.
  3. Se persistirem, trate o relatório de pânico como a fonte da verdade e direcione para CAUSA 1/2/3/5 com base no que ele diz.

Para o quadro completo do que foi lançado nesta versão, incluindo as correções de segurança, consulte nosso guia completo de atualização do macOS Tahoe 26.5. Se você chegou aqui de uma versão anterior, os padrões em nosso guia de correção de bugs e crashes do 26.3 e o guia de solução de problemas do 26.2 fornecem contexto histórico útil sobre como esses problemas de estabilidade evoluíram ao longo do ciclo do Tahoe.

CAUSA 5: Hardware — RAM, eGPU / Thunderbolt e Temperatura

Quando os relatórios de pânico variam a cada vez, não nomeiam nenhum kext de terceiros, não mostram padrão de display/sleep e sobrevivem a uma reinstalação limpa, você está provavelmente olhando para hardware. Pânicos de hardware tendem a ser inconsistentes precisamente porque dependem de condições físicas — temperatura, uma célula de memória marginal, um conector com problemas.

Execute o Apple Diagnostics

O teste de hardware integrado da Apple é o primeiro passo:

Apple silicon:

  1. Desligue.
  2. Pressione e segure o botão de energia até que "Carregando opções de inicialização" apareça, depois solte.
  3. Pressione Cmd+D para executar o Diagnóstico.

Intel:

  1. Desligue.
  2. Ligue e imediatamente segure a tecla D (ou Option+D para testar pela internet) até que uma barra de progresso ou seletor de idioma apareça.

O Diagnóstico é executado e retorna códigos de referência. Códigos começando com PPM estão relacionados à energia; PPT à bateria; NDC/VFD à câmera/display; e vários códigos relacionados à memória apontam para a RAM. Anote qualquer código que ele fornecer — é a linguagem que o suporte da Apple vai usar.

RAM (Intel / Mac Pro com memória atualizável pelo usuário)

Em máquinas onde você pode trocar a RAM:

  • Se você adicionou RAM de terceiros recentemente e os pânicos começaram, reencaixe ou remova-a. Memória inválida ou incompatível é uma fonte clássica de pânico.
  • Teste com um módulo / um banco por vez para isolar um módulo com falha.
  • Macs com Apple silicon têm memória unificada soldada — você não pode trocá-la, então uma falha de memória confirmada significa uma visita de serviço.

eGPU e Thunderbolt

  • GPUs externas (principalmente configurações da era Intel) adicionam um driver complexo e um caminho de energia. Se você usa uma eGPU e vê pânicos na pilha de GPU, desconecte-a e teste. O suporte a driver de eGPU se estreitou nas versões recentes do macOS.
  • Links Thunderbolt marginais — um cabo ruim, um barramento sobrecarregado — podem produzir pânicos que parecem aleatórios. Simplifique a cadeia Thunderbolt e use cabos comprovadamente bons (isso se sobrepõe com a CAUSA 3).

Temperatura

  • Um Mac que entra em pânico sob carga pesada sustentada (renderizações longas, jogos, compilação) e fica quente pode estar atingindo uma falha relacionada à temperatura. Certifique-se de que as aberturas de ventilação estão desobstruídas, que a máquina está em uma superfície dura e que a temperatura ambiente é razoável.
  • Pânicos térmicos repetidos em uma máquina com pasta térmica envelhecida ou um ventilador com falha são um item de serviço.

Se um pânico só acontece quando seu Mac também está lento e superaquecendo sob carga, o guia para corrigir um Mac lento cobre a redução de carga em segundo plano e o gerenciamento de pressão de recursos, o que pode diminuir o teto térmico que você está atingindo.

CAUSA 6: Estado Corrompido do Sistema — NVRAM, SMC e Reinstalação no Lugar

Quando você descartou displays, extensões, periféricos e hardware, a última categoria é o estado de baixo nível corrompido ou uma instalação do macOS danificada.

Redefinir NVRAM (principalmente Intel)

NVRAM/PRAM armazena pequenas configurações — display, disco de inicialização, alguns valores de energia. Em Macs Intel, redefini-la pode limpar um valor corrompido causando pânicos. Há dois caminhos:

# De um Mac Intel com sessão iniciada, limpe a NVRAM e reinicie
sudo nvram -c

Ou na inicialização em Intel: desligue, ligue e imediatamente segure Option+Cmd+P+R por cerca de 20 segundos, depois solte. Macs com Apple silicon gerenciam a NVRAM automaticamente e não têm uma combinação de teclas de redefinição manual — uma reinicialização normal redefine o estado relevante, então a combinação de teclas não se aplica.

Redefinir SMC (somente Intel)

O System Management Controller lida com energia, temperatura e algum comportamento de hardware em Macs Intel. Um estado SMC corrompido pode causar pânicos relacionados à energia e ao wake. A sequência exata de teclas depende do modelo (T2 vs. não-T2, desktop vs. laptop) — siga as etapas de redefinição de SMC específicas do modelo da Apple. Macs com Apple silicon não têm SMC para redefinir; um desligamento completo (deixe desligado por ~30 segundos) e reinicialização realiza o equivalente.

Reinstalar o macOS no lugar

Se os pânicos persistem sem uma causa clara, reinstalar o macOS sobre seu sistema existente substitui os arquivos de sistema sem apagar seus dados:

  1. Faça backup primeiro com o Time Machine (sempre, antes de qualquer reinstalação).
  2. Inicialize na Recuperação: no Apple silicon, segure o botão de energia até "Carregando opções de inicialização," depois escolha Opções → Continuar; no Intel, segure Cmd+R na inicialização.
  3. Escolha Reinstalar o macOS Tahoe e siga as instruções. Esta é uma reinstalação no lugar — seus arquivos, apps e configurações permanecem.
  4. Se os pânicos ainda ocorrerem após uma reinstalação limpa em estado de fábrica, as evidências apontam fortemente de volta para hardware (CAUSA 5) ou uma única extensão reinstalada (CAUSA 2) — nesse ponto, uma visita ao Genius Bar é justificada.

Uma reinstalação é um passo pesado. Não pule para ela primeiro; chegue até ela somente depois que o relatório de pânico e a árvore de decisão realmente falharam em identificar uma causa.

Quando Levar ao Apple

Alguns pânicos não são seus para corrigir. Leve o Mac ao Apple (ou a um Apple Authorized Service Provider) quando:

  • O Apple Diagnostics retornar um código de referência de hardware. Isso é um problema de componente confirmado.
  • Os pânicos persistem após uma reinstalação limpa no lugar em uma configuração de outra forma padrão — o software foi descartado.
  • O relatório de pânico nomeia consistentemente uma falha de hardware (machine check, erros de ECC/memória) sem nenhum kext de terceiros.
  • Você está em um M5 MacBook Air / M5 Pro/Max, totalmente atualizado para o 26.5 ou posterior, e ainda está tendo pânicos — a Apple reconheceu problemas de reinicialização nesses modelos, então seu caso é dado relevante para eles e pode ser coberto.
  • O Mac não fica inicializado tempo suficiente para diagnosticar (loop de pânico) mesmo após as etapas de recuperação abaixo.

Antes de ir, colete as evidências: copie os relatórios de pânico mais recentes de /Library/Logs/DiagnosticReports/, anote seu código do Apple Diagnostics e escreva o padrão (quando acontece, o que está conectado). Um relatório claro e um padrão reproduzível aceleram dramaticamente uma visita de suporte. Os Macs com Apple silicon ainda estão na garantia para a geração M5, e problemas de reinicialização reconhecidos são exatamente o tipo de coisa que as equipes de serviço querem ver documentada.

Solução de Problemas Comuns

Problema: Meu Mac só entra em pânico quando acorda do sleep

Solução: Este é um pânico de sleep/wake, quase sempre causado por um periférico. Execute pmset -g log | grep -iE 'failure|wake' para confirmar que as falhas de wake correspondem aos horários de pânico. Desconecte todos os hubs, docks e drives externos, depois deixe o Mac dormir e acordar repetidamente por um dia. Se estiver estável, reconecte dispositivos um por vez até que o pânico retorne — aquele dispositivo (ou seu cabo/energia do hub) é a causa. Alimente seu hub externamente e atualize seu firmware; hubs alimentados pelo barramento são o gatilho mais comum.

Problema: Meu Mac só entra em pânico quando meu monitor externo está conectado

Solução: Este é um pânico de display/GPU, e a correção geralmente é simples. Abra Configurações do Sistema → Monitores, selecione o monitor externo e reduza a Taxa de Atualização de 240/144/120 Hz para 60 Hz. Use por um dia. Se os pânicos pararem, a alta taxa de atualização era a causa — você pode então tentar subir para 120 Hz, trocar para um cabo certificado de alta largura de banda, conectar diretamente em vez de pelo dock e desativar o HDR. O SwitchResX pode bloquear um modo seguro exato se o painel de Monitores ocultar a taxa que você precisa.

Problema: Meu Mac entra em pânico aleatoriamente sem padrão óbvio

Solução: Deixe o relatório de pânico decidir. Abra o arquivo mais recente em /Library/Logs/DiagnosticReports/, leia a panicString e verifique "Kernel Extensions in backtrace". Um kext de terceiros ali → atualize ou remova aquele software e teste no Safe Mode. Sem kext de terceiros e os relatórios diferem a cada vez → execute o Apple Diagnostics (Cmd+D na inicialização no Apple silicon) para um código de hardware. Pânicos aleatórios geralmente são ou uma extensão com mau funcionamento ou hardware marginal — o relatório diz qual.

Problema: Meu Mac está preso em um loop de pânico e não termina de inicializar

Solução: Inicialize no Safe Mode primeiro (Apple silicon: segure o botão de energia → selecione disco → segure Shift → Continuar no Safe Mode; Intel: segure Shift na inicialização). O Safe Mode desativa extensões de terceiros, então se ele inicializar normalmente, um kext é a causa — remova-o a partir daí. Se o Safe Mode também fizer um loop, inicialize na Recuperação (Apple silicon: segure o botão de energia → Opções; Intel: Cmd+R), execute o Disk Utility First Aid e, se necessário, reinstale o macOS no lugar. Loop persistente mesmo de uma reinstalação limpa aponta para hardware — leve ao Apple.

App Console mostrando um relatório de pânico do macOS

Perguntas Frequentes

Um kernel panic é o mesmo que meu Mac travando?

Não exatamente. Um kernel panic é o sistema inteiro parando e reiniciando porque o núcleo do SO chegou a um estado inseguro — você recebe um diálogo "Seu computador foi reiniciado por causa de um problema". Um crash de app é um único programa encerrando enquanto o restante do macOS continua rodando. Eles gravam relatórios diferentes e têm correções diferentes, então identifique qual você está vendo antes de solucionar problemas.

Onde exatamente o log de pânico é armazenado no macOS Tahoe?

Relatórios de kernel panic ficam em /Library/Logs/DiagnosticReports/, nomeados como Kernel-2026-05-22-143012.panic ou um arquivo panic-full-...ips mais rico no Apple silicon. Você também pode abri-los no Console.app em Crash Reports / System Reports. Execute ls -lt /Library/Logs/DiagnosticReports/ | grep -i panic no Terminal para listá-los do mais recente ao mais antigo.

Reduzir a taxa de atualização do meu monitor vai realmente parar as reinicializações?

Se seus pânicos só acontecem com aquele monitor conectado e o relatório mostra um timeout de watchdog do WindowServer/GPU, então sim — reduzir de 240/144/120 Hz para 60 Hz é uma solução alternativa robusta e confirmada pela comunidade que elimina o caminho de temporização marginal. É a primeira coisa a tentar para pânicos relacionados ao display. Você pode testar 120 Hz posteriormente com um cabo certificado assim que o sistema estiver estável.

A Apple corrigiu os bugs de reinicialização no macOS Tahoe 26.5?

As notas de lançamento enterprise do 26.5 da Apple reconheceram e abordaram correções de reinicialização para M5 MacBook Air e M5 Pro/Max, reinicializações causadas por extensões de rede de filtro de conteúdo e uma condição de tela preta após atualização. Isso cobre um conjunto significativo de casos, então atualize completamente primeiro. Mas alguns usuários ainda relatam pânicos depois — esses são relatados pela comunidade e precisam das soluções alternativas neste guia em vez de um patch garantido.

Como sei se um driver de terceiros causou meu pânico?

Abra o relatório de pânico e encontre a seção "Kernel Extensions in backtrace". Se você vir IDs de bundle que não são com.apple.* — o nome de um fornecedor de VPN, antivírus ou virtualização — aquela extensão está implicada. Confirme inicializando no Safe Mode (que desativa kexts de terceiros): se os pânicos pararem, software de terceiros é a causa. Então atualize ou desinstale aquela extensão.

Devo reinstalar o macOS para corrigir kernel panics?

Reinstalar é um último recurso, não um primeiro passo. Trabalhe a árvore de decisão primeiro — taxa de atualização, extensões, periféricos, os itens reconhecidos do 26.5, hardware. Somente após esses falharem você deve fazer uma reinstalação no lugar (que mantém seus dados). Sempre faça backup com o Time Machine primeiro. Se os pânicos continuarem mesmo após uma reinstalação limpa, a causa é quase certamente hardware, e é hora de ir ao Apple.

Conclusão

Kernel panics parecem catastróficos, mas no macOS Tahoe 26.5 geralmente são rastreáveis para uma lista curta de causas — e o relatório de pânico diz qual é. Leia a panicString e a lista "Kernel Extensions in backtrace" primeiro; esses dois campos direcionam a maioria dos pânicos para a correção certa. Para o gatilho mais comum do Tahoe 26.5, uma taxa de atualização do display externo muito alta, a correção é tão simples quanto reduzir para 60 Hz. Para pânicos relacionados a extensões, audite com kmutil showloaded e systemextensionsctl list, depois prove no Safe Mode. Para pânicos de sleep/wake, isole o periférico. Certifique-se de estar totalmente atualizado para que os itens que a Apple reconheceu no 26.5 já estejam tratados, e reserve testes de hardware e reinstalações para quando o relatório e a árvore de decisão realmente falharem em identificar uma causa.

Diagnostique, não adivinhe — e você resolverá a grande maioria dessas reinicializações sozinho. Para leitura relacionada, consulte nosso guia de atualização e segurança do macOS Tahoe 26.5, o guia de diagnóstico de display externo e a correção de crashes de abas do Safari caso seu problema seja no nível de app em vez de um kernel panic completo.