O Misterioso Problema de Falha de SSD após Atualização do Windows
Há alegações de que uma atualização recente do Windows, especificamente a KB5063878, estaria causando falhas em unidades de estado sólido (SSDs) de alguns usuários. A Microsoft emitiu um comunicado afirmando não conseguir reproduzir o problema e que seus dados de telemetria não indicam um aumento nas falhas de unidade. No entanto, há argumentos fortes para sugerir que o problema é real e que a telemetria da Microsoft pode estar falhando em detectá-lo.
É importante notar, inclusive, que mesmo que haja um problema, a causa pode não ser da Microsoft; a atualização pode ter apenas exposto uma falha preexistente nos controladores dos SSDs.
A Evidência de Reprodução
Uma das razões mais convincentes para levar este problema a sério é que outro criador de conteúdo conseguiu demonstrar a falha ocorrendo em seu próprio computador e reproduzi-la de forma consistente. Muitos dos pontos levantados a seguir se baseiam nas demonstrações feitas por ele.
No conteúdo que demonstrou o problema, o criador de conteúdo conseguiu causar a falha da unidade de forma bastante consistente ao executar um *benchmark* específico. Um detalhe observado, que não foi mencionado na demonstração original, é que a falha da unidade ocorre durante a fase de carregamento do *benchmark*.
É relevante notar que o teste estava sendo realizado em um *test bench*, onde se busca manter o software o mais estático possível para testar o hardware de forma justa. Isso sugere que a única grande mudança de software foi a instalação da atualização do Windows.
Curiosamente, o criador do teste não conseguiu reverter totalmente o problema ao desinstalar a atualização, pois ela também instalou uma *servicing stack* junto. Isso levanta a possibilidade de que o problema não seja apenas da atualização de segurança, mas também da *servicing stack* associada.
O Papel da Leitura e Escrita
O criador do teste observou que a falha ocorria especificamente com aquele *benchmark*, enquanto outros testes de estresse de leitura e escrita, como copiar arquivos grandes ou rodar o CrystalDiskMark, não causavam o problema. Isso poderia levar à conclusão de que não se trata apenas de leitura e escrita pesada.
No entanto, o fato de o *crash* ocorrer durante a fase de carregamento do *benchmark* é crucial. Ao carregar arquivos para a memória, estamos lendo do disco. Além disso, o Windows utiliza um arquivo de paginação (page file), que move partes menos usadas da memória para o disco. Se muitas coisas novas estão sendo carregadas na memória, o Windows pode decidir mover dados existentes para o disco, resultando em escritas simultâneas à leitura.
Isso sugere fortemente que o problema pode estar relacionado a escritas pesadas no disco, mas de uma forma diferente da cópia de arquivos simples.
Uma forma de testar isso seria desabilitar o arquivo de paginação do Windows, reiniciar e verificar se a falha ainda ocorre durante o carregamento. Se o problema desaparecer, isso confirmaria que a teoria de que a falha está ligada à escrita pesada (neste caso, gerenciada pelo *page file*) ainda se sustenta, pelo menos em parte. É fundamental ressaltar que desabilitar o *page file* é apenas um método de teste para este cenário específico, e não uma recomendação geral.
Outro fator a ser investigado é a temperatura. Seria interessante monitorar as temperaturas dos SSDs durante o teste e verificar se a adição de um dissipador de calor resolveria o problema, sugerindo que o *throttling* térmico do SSD pode ter sido afetado negativamente pela atualização.
A Natureza da Falha: Não Necessariamente Bricking
Um ponto muito relevante discutido é o que acontece após a falha. Em testes, ao realizar uma reinicialização normal do Windows, a unidade permanece desaparecida. No entanto, apenas um ciclo completo de energia (desligar a fonte de alimentação e ligá-la novamente) faz com que a unidade retorne.
Isso gera uma hipótese importante: mesmo quando o problema ocorre, ele provavelmente não está “bricking” (inutilizando permanentemente) os SSDs. Mesmo que a unidade não volte após uma reinicialização do sistema, um ciclo completo de energia pode ser necessário para recuperá-la.
Diante disso, a recomendação geral é que os usuários continuem com as atualizações do Windows, pois:
1. O problema, mesmo real, parece ser raro.
2. Na maioria dos casos, o SSD é recuperável através de um ciclo completo de energia (desligar o sistema e também a fonte de alimentação antes de religar).
Hipótese 2: Leitura e Escrita Simultâneas
Uma segunda teoria é que o problema é desencadeado não apenas por escritas pesadas, mas pela combinação de escrita e leitura simultâneas.
Observando testes de um usuário no Twitter, a maior parte dos problemas ocorreu durante a compressão de arquivos no mesmo disco (leitura do arquivo original e escrita no arquivo compactado) e na extração desses arquivos (leitura do arquivo compactado e escrita do arquivo extraído). Apenas cópia simples (leitura de um disco e escrita em outro) causou menos falhas.
Isso se alinha com a observação sobre o *benchmark* de Jay: o carregamento de mapas na memória (leitura) e a escrita no arquivo de paginação simultaneamente (escrita) podem ser o fator desencadeante.
Portanto, se alguém planeja testar a reprodução do problema, deve focar em cenários que exijam leitura e escrita intensivas ao mesmo tempo.
Por Que a Telemetria da Microsoft Não Mostra Nada?
A Microsoft afirmou que sua telemetria não mostra aumento de falhas. Isso levanta a questão: por que isso estaria acontecendo se o problema é real?
A principal razão é técnica: se a falha ocorre no disco do sistema operacional principal, não há como o Windows enviar um relatório de erro.
O Windows utiliza o Windows Error Reporting (WER) para criar arquivos no disco contendo informações sobre falhas de aplicativos ou até mesmo um *dump file* em caso de *crash* do sistema (BSOD), enviando-os à Microsoft. Se o disco principal simplesmente “desaparece”, não há onde criar esse arquivo de relatório.
No exemplo de BSODs observados, a tela azul de erro desaparece quase instantaneamente (antes de atingir 0% de preparação do relatório). Isso ocorre porque o sistema não consegue criar o arquivo de *dump* necessário para o upload.
Mesmo que o Windows reinicie e perceba que o desligamento não foi limpo, ele não saberá o que causou a falha, pois os eventos ocorridos após o desaparecimento do disco não são registrados. O evento parecerá um corte abrupto de energia. Se o problema é uma falha instantânea do hardware do SSD, ele desaparece antes mesmo de notificar o sistema operacional.
Portanto, a ausência de telemetria sugere que o problema pode estar no nível do hardware do SSD, falhando de forma tão rápida que nem o Windows consegue registrar a causa.
Por Que Não Há Relatos de Usuários?
A Microsoft também alegou não ter recebido relatos significativos. Isso pode ser explicado por dois fatores principais:
1. **Baixo Incentivo para Reportar:** Se o SSD volta a funcionar após um ciclo completo de energia, a maioria dos usuários não o considerará uma falha permanente e não se dará ao trabalho de reportar o incidente à Microsoft.
2. **Mecanismos de Recuperação Automática:** Muitos usuários podem não perceber que isso aconteceu, pois suas placas-mãe podem executar um ciclo de energia automático em certos tipos de reinicialização, fazendo com que a unidade retorne sem que o usuário perceba a falha.
Para usuários comuns, a falha se manifesta como um *crash* rápido, e o procedimento usual de “desligar por 30 segundos e ligar novamente” resolveria o problema, levando o usuário a pensar que foi apenas uma falha temporária do sistema.
Em ambientes corporativos, onde os *workloads* geralmente não envolvem a escrita de arquivos gigantescos (como em planilhas), a incidência seria menor. Mesmo que ocorra, o procedimento de TI provavelmente envolveria o ciclo de energia, resolvendo o problema no nível do departamento de TI, sem escalar para a Microsoft como um problema de padrão.
Sobre a Reprodução Interna da Microsoft
A alegação da Microsoft de que não conseguiu reproduzir o erro internamente não é surpreendente. É altamente provável que os procedimentos de teste internos não incluam os passos específicos necessários para acionar essa falha, especialmente aquela combinação de leitura/escrita simultânea durante o carregamento de *benchmarks*.
Considerações Finais
Embora o risco de perda permanente de dados pareça baixo, dada a recuperabilidade via ciclo de energia, se usuários começarem a experimentar *BSODs* rápidos que não geram relatórios, isso deve ser notado e comunicado.
Pode ser que o problema tenha começado em uma atualização anterior, mas só está sendo notado agora devido aos padrões de uso atuais. O ponto principal é que a ausência de relatórios e telemetria não é uma prova conclusiva de que o problema não está ocorrendo.
