Durante seis meses o meu desktop foi mal-assombrado. Reinícios aleatórios, às vezes voltando direto pra tela da BIOS como se nada tivesse acontecido. Telas azuis com semanas de intervalo, cada uma com um stop code diferente. Refiz minha teoria sobre a máquina umas cinco vezes: é a RAM, não, pera, é o SSD, não, é driver, vai ver a fonte tá fraquejando. Em certo momento eu já estava, sinceramente, orçando um PC novo — porque caçar um fantasma que não se deixa reproduzir é o tipo mais desmoralizante de debugging que existe.
Até que numa tarde eu parei de chutar e fui ler o que a máquina estava me dizendo o tempo todo. No fim das contas, meu i9-14900K estava morrendo, em silêncio, um núcleo de cada vez. E o Windows tinha anotado tudo.
A fase de suspeitar de tudo, menos da verdade
O contexto: um i9-14900K numa Gigabyte Z790 AORUS ELITE AX, 64 GB de DDR5, Windows 11 24H2. Sem overclock, sem nem XMP ativado, tudo no padrão da placa. O tipo de máquina que não tem o menor direito de ser instável.
A primeira tela azul veio em fevereiro, enquanto o clangd indexava um projeto: KMODE_EXCEPTION_NOT_HANDLED. Chato, mas ok, coisa pontual. Depois um KERNEL_SECURITY_CHECK_FAILURE no mesmo mês. Março: PAGE_FAULT_IN_NONPAGED_AREA. Abril: SYSTEM_SERVICE_EXCEPTION. Agosto: um HYPERVISOR_ERROR — que eu nem sabia que existia — com o Discord aberto.
Cinco crashes, cinco stop codes diferentes, cinco processos diferentes. Quem já dançou essa dança conhece o roteiro: rodar memtest (passou), atualizar driver (nada), vigiar temperatura (normal), questionar as próprias escolhas de vida (em andamento). Bug de software é bicho de hábito — quebra no mesmo lugar, do mesmo jeito, toda vez. Esses crashes não tinham hábito nenhum. Eu só ainda não tinha entendido o que isso realmente significava.
Em meados de agosto a máquina já reiniciava sozinha sem nem se dar ao trabalho de mostrar tela azul antes. Foi a semana em que eu quase desisti dela.
Lendo o que a máquina estava dizendo de verdade
A virada foi de uma simplicidade constrangedora: abri o Visualizador de Eventos e, em vez de olhar os crashes, olhei o que acontecia em volta deles. Enterradas no log de Sistema havia entradas de uma fonte que eu nunca tinha dado bola: WHEA-Logger, Event ID 19 — “A corrected hardware error has occurred” (um erro de hardware corrigido ocorreu).
WHEA é a Windows Hardware Error Architecture. O evento 19 significa que o próprio processador detectou um erro interno, corrigiu na hora e registrou a ocorrência. A máquina não trava — você nunca ficaria sabendo. Puxar todos eles é um comando de PowerShell:
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-WHEA-Logger'
Id = 19
} | Format-List TimeCreated, MessageEram 27. Vinte e um diziam internal parity error, seis diziam Translation Lookaside Buffer error, todos reportados pelo componente “Processor Core”. E cada um dos eventos, sem exceção, carregava um de dois números nos detalhes: APIC ID 32 ou APIC ID 33.
Vinte e sete erros. Dois APIC IDs. Nada mais, em lugar nenhum, em meses de log.
Esse padrão é a história inteira, e o motivo é este: tudo que eu vinha culpando — fonte, RAM, placa-mãe, refrigeração — é infraestrutura compartilhada. Se a alimentação estivesse ruim, os erros cairiam em núcleos aleatórios. Se a RAM estivesse ruim, a corrupção seguiria qualquer núcleo que tocasse o endereço defeituoso. Uma falha que só atinge os mesmos dois processadores lógicos, enquanto os outros 30 permanecem impecáveis, não vem de fora do chip. É defeito num pedaço específico do silício.
Dois APIC IDs, um núcleo só
Próxima pergunta: qual núcleo físico é dono dos APIC IDs 32 e 33? Não dá pra assumir o mapeamento — número de CPU lógica, APIC ID e núcleo físico são três numerações diferentes nos Intel híbridos. Então perguntei direto ao processador: um programinha de console que percorre os 32 processadores lógicos, se prende a cada um com SetThreadAffinityMask e executa CPUID — leaf 0x0B pro x2APIC ID, leaf 0x1A pro tipo de núcleo. A saída:
CPU Lógica x2APIC Tipo
0 0 P-core <- P-core 0
1 1 P-core
2 8 P-core <- P-core 1
3 9 P-core
4 16 P-core <- P-core 2
5 17 P-core
6 24 P-core <- P-core 3
7 25 P-core
8 32 P-core <- P-core 4 *** aqui ***
9 33 P-core *** e aqui ***
10 40 P-core <- P-core 5
...
16 64 E-core
...Os APIC 32 e 33 são as duas threads de hyperthreading do mesmo P-core físico — o quinto. Todos os 27 erros de machine check, os dois tipos de erro, ao longo de meses, num único núcleo entre vinte e quatro. Os outros 23 núcleos: zero erros. Não é “menos erros”. É zero.
O registro bruto de machine check do pior dia deixa tudo ainda mais específico:
ApicId = 33
MCABank = 0 (Instruction Fetch Unit)
MciStat = 0x8000004000050005Decodificando o registrador de status: registro válido, erro corrigido, código de erro MCA 0x0005 = internal parity error, reportado pelo Bank 0 — a unidade de busca de instruções (IFU). A parte do núcleo que lê instruções da memória antes de executá-las estava, de vez em quando, lendo errado. Guarde esse detalhe; ele volta já, já.
Os dumps de crash diziam a mesma coisa o tempo todo
Com uma teoria na mão, voltei aos cinco minidumps com o WinDbg (!analyze -v, símbolos públicos da Microsoft). Agora os “cinco stop codes diferentes” deixaram de ser ruído e viraram a assinatura. Três desses dumps são pequenas obras-primas de perícia forense de falha de hardware.
Prova número um: um único bit invertido. O crash de março foi um page fault em Ntfs!NtfsContinueIndexEnumeration. Compare o endereço que o código tentou acessar com o endereço que ele deveria ter usado:
endereço referenciado : fffff802 aed92e50
endereço correto : fffff802 2ed92e50
^
XOR = 0x0000000080000000 -> exatamente 1 bit (bit 31)Um bit, invertido, num endereço de kernel calculado. Software não faz isso. Bug de software produz off-by-one, use-after-free, dereferência de nulo — padrões com uma lógica por trás. Um bit único invertido num endereço é aritmética dando errado dentro do processador.
Prova número dois: um breakpoint fantasma. O crash de abril foi STATUS_BREAKPOINT — uma instrução INT 3 executada dentro de código de kernel do NTFS, assinado pela Microsoft. Não existe breakpoint compilado em código de kernel de produção. Ou seja: os bytes que o processador executou não eram os bytes que estavam na memória — o fluxo de instruções foi corrompido em algum ponto entre a busca e a execução. Corrompido onde? Na unidade de busca de instruções. Exatamente a unidade contra a qual o MCA Bank 0 vinha registrando erros de paridade. Quando duas fontes de evidência completamente independentes apontam pro mesmo bloco funcional, dá pra parar de chamar aquilo de teoria.
Prova número três: um núcleo que parou de atender o telefone. A stack do crash de agosto mostra o processador 29 enviando uma interrupção entre processadores (IPI) e esperando pra sempre em KiIpiStallOnPacketTargetsPrcb pela confirmação de um núcleo de destino. Que nunca veio. O watchdog de NMI disparou e derrubou o sistema. Um núcleo que fica surdo a IPIs é um núcleo que travou em nível de hardware.
Matando a última explicação alternativa
Uma ponta solta me incomodava: dois dos cinco crashes aconteceram na mesma função do NTFS. Essa repetição admitia uma explicação sem graça — um Ntfs.sys corrompido no disco, ou um SSD morrendo. Então testei. chkdsk /scan: sistema de arquivos limpo, zero setores defeituosos em três milhões de registros de arquivo. sfc /scannow: encontrou exatamente um arquivo irreparável no sistema inteiro — um ícone PNG do tema de alto contraste. E o Ntfs.sys? Íntegro, verificado, sem uma única menção no log do CBS.
E repare na causalidade: essa máquina tinha acumulado uma sequência de desligamentos sujos. Se fosse pra algo estar corrompido, crashes causam corrupção de disco — não o contrário. Nem isso aconteceu. Hipótese alternativa: enterrada.
Dando nome ao vilão
Se você acompanhou as notícias de hardware em 2024, já sabe onde isso vai dar. Os processadores Intel Core de 13ª e 14ª geração têm um modo de falha por degradação reconhecido publicamente — a Vmin Shift Instability — em que tensão elevada sustentada envelhece fisicamente o silício até que a tensão mínima estável dos núcleos mais rápidos saia da especificação. O i9-14900K é o SKU mais afetado. A Intel lançou mitigações via microcode e estendeu a garantia dos chips afetados para cinco anos.
Minha placa já rodava o microcode 0x12F — o mais recente, com todas as mitigações aplicadas. Os erros continuaram vindo mesmo assim, porque as mitigações evitam dano futuro; elas não curam silício que já degradou. E a linha de tendência era exatamente a cara de uma degradação: um erro corrigido no começo de julho, onze num único dia em meados de julho, dezesseis num único dia em agosto — incluindo uma rajada de onze erros de paridade dentro de um segundo. O núcleo não estava só falhando. Estava falhando mais rápido a cada semana.
Também bate o fato de a vítima ser um P-core. A Vmin Shift atinge os núcleos de performance de alta frequência — os que sofrem boost mais agressivo. O quinto P-core do meu chip simplesmente tirou o palito mais curto.
O RMA, ou: evidência organizada é um superpoder
Juntei tudo num relatório: a linha do tempo dos eventos WHEA, o mapeamento APIC → núcleo, os registradores de machine check decodificados, as análises dos dumps, os testes de disco descartando a alternativa. Aí abri um chamado de garantia na Intel e colei um resumo que começava pelo fato matador: 27 erros de machine check, 100% deles nas duas threads SMT de um único P-core físico, com o microcode atual.
Eu tinha me preparado pro roteiro clássico do suporte de primeiro nível — reseta a BIOS, testa a RAM, reinstala o Windows. Ele nunca veio. A Intel analisou o material e confirmou o processador como defeituoso no dia seguinte. RMA aprovado; o chip substituto está a caminho enquanto escrevo isto.
Não acho que tive sorte. Acho que engenheiro de suporte, como qualquer um de nós, anda rápido quando alguém entrega um caso já resolvido e mostrando o raciocínio.
O que eu diria pro eu do passado
Crashes que nunca se repetem do mesmo jeito não são ruído — a própria inconsistência é informação. Software falha com padrão; hardware falha em todo lugar ao mesmo tempo. E antes de culpar componentes que você não consegue enxergar por dentro, verifique se o processador anda registrando denúncias contra si mesmo: WHEA-Logger, Event ID 19, log de Sistema. Machine checks corrigidos são silenciosos — sem crash, sem aviso — e costumam ser o alerta mais precoce que você vai ter de que um silício está morrendo. O meu passou seis semanas documentando o próprio declínio em silêncio enquanto eu acusava a RAM.
A máquina sabia. Geralmente é só uma questão de perguntar.