Uma mudança interna no gerenciamento de memória do Windows Server 2025 está provocando falhas em determinadas aplicações que utilizam Address Windowing Extensions (AWE), mecanismo criado para permitir que aplicações de 32 bits acessem mais de 4 GB de memória física.
O alerta foi divulgado pela Microsoft que afimou que aplicações afetadas podem apresentar access violations, corrupção de memória ou encerramento inesperado.
O problema é relevante para ambientes que executam SQL Server com a política Windows “Lock Pages in Memory” (LPIM) habilitada, configuração utilizada para impedir que páginas de memória do SQL Server sejam paginadas para disco e, consequentemente, melhorar a previsibilidade do desempenho.
A questão mostra um dos riscos menos visíveis de uma atualização de infraestrutura: uma mudança feita para modernizar ou corrigir o sistema operacional pode alterar pressupostos de software construídos sobre comportamentos de versões anteriores.
AWE: uma tecnologia antiga que ainda pode ser crítica
O Address Windowing Extensions é uma interface de programação do Windows que permite a determinadas aplicações gerenciar grandes quantidades de memória física mesmo quando trabalham dentro de um espaço de endereçamento virtual de 32 bits.
Em termos simplificados, a aplicação não mantém toda a memória física mapeada em seu espaço virtual. Ela utiliza uma espécie de “janela” para acessar diferentes regiões da memória física. Essa arquitetura foi importante em uma época em que aplicações de 32 bits encontravam a limitação de aproximadamente 4 GB de espaço de endereçamento.
Embora o cenário tecnológico tenha mudado radicalmente com aplicações de 64 bits, mecanismos legados como AWE ainda aparecem em determinados ambientes corporativos.
É justamente aí que surge o problema: a Microsoft informa que uma mudança no comportamento do gerenciamento de memória do Windows Server 2025 pode afetar aplicações que utilizam AWE e dependem de comportamentos presentes em versões anteriores do Windows Server.
O caso mais sensível: SQL Server.
O SQL Server é o exemplo mais importante porque gerenciamento de memória é parte fundamental de seu desempenho. Quando o Lock Pages in Memory está habilitado, o sistema impede que determinadas páginas utilizadas pelo processo do banco de dados sejam paginadas para disco.
Isso pode ser desejável em servidores de banco de dados porque reduz interferências do gerenciamento de memória do sistema operacional e ajuda a manter o comportamento de desempenho mais previsível.
O problema identificado no Windows Server 2025 pode provocar corrupção de memória; exceções 0xC0000005 de acesso inválido; falhas em operações de manutenção de banco de dados; geração de crash dumps;
interrupção ou reinicialização inesperada do serviço SQL Server; e mensagens relacionadas a páginas bloqueadas no gerenciador de memória.
Uma operação importante que pode ser afetada é o DBCC CHECKDB, utilizado para verificar a integridade lógica e física das estruturas de banco de dados. Ou seja: não estamos diante de um simples aplicativo de desktop que fecha inesperadamente. Em determinados ambientes, uma falha desse tipo pode atingir diretamente bancos de dados que sustentam aplicações corporativas críticas.
O mecanismo por trás da falha
A característica mais interessante do caso é que a Microsoft não está descrevendo simplesmente “um bug do SQL Server”. O problema está na interação entre três camadas: Windows Server 2025, gerenciamento de memória e aplicação que utiliza AWE/LPIM.
Essa distinção é importante.
Uma aplicação pode funcionar corretamente durante anos em uma versão anterior do Windows Server porque seu código depende, direta ou indiretamente, de determinado comportamento do sistema operacional. Quando esse comportamento muda, a aplicação pode passar a operar em uma condição que seus desenvolvedores não haviam previsto.
A documentação da Microsoft sobre o Windows Server 2025 mostra que a versão introduziu mudanças importantes em segurança, desempenho, armazenamento, Hyper-V, redes e integração híbrida.
Quanto mais profundo é o processo de modernização do sistema operacional, maior a necessidade de testar não apenas se uma aplicação “instala”, mas se continua funcionando corretamente sob suas cargas reais de trabalho.
A recomendação temporária: desabilitar LPIM
Enquanto uma correção permanente não está disponível, a Microsoft recomenda como solução temporária avaliar a desativação da política Lock Pages in Memory para a conta utilizada pelo SQL Server.
Mas há uma ressalva: não é uma mudança neutra.
A própria Microsoft alerta que desabilitar LPIM pode alterar o comportamento de gerenciamento de memória e afetar o desempenho do SQL Server. Para outras aplicações, a orientação é verificar se o AWE pode ser desabilitado.
Portanto, a solução não deveria ser aplicada indiscriminadamente.
Em um ambiente de produção, o procedimento correto é comparar pelo menos: LPIM habilitado → comportamento atual versus LPIM desabilitado → consumo de memória, paginação, latência e desempenho da aplicação.
O objetivo é evitar transformar um problema de estabilidade em um problema de desempenho.
Porque ainda não existe correção definitiva. Segundo a Microsoft, uma correção permanente está sendo desenvolvida para uma atualização futura do Windows Server 2025. Até lá, os administradores precisam avaliar o workaround de acordo com a configuração de cada ambiente.
A página oficial da Microsoft mantém o acompanhamento dos problemas conhecidos do Windows Server 2025, incluindo histórico, status e orientações de resolução.
Esse tipo de acompanhamento deveria fazer parte da rotina de qualquer equipe responsável por infraestrutura crítica.
Não basta acompanhar o Patch Tuesday
É necessário acompanhar também o que a atualização modificou e quais aplicações podem depender de comportamentos que deixaram de existir.
O problema maior é que atualizar também é uma mudança de arquitetura. E o caso do Windows Server 2025 mostra uma questão que costuma ser subestimada em projetos de migração: uma atualização de sistema operacional não é necessariamente uma operação de “troca de versão”.
Ela pode modificar gerenciamento de memória; mecanismos de segurança; APIs; drivers; políticas de autenticação; protocolos; componentes de rede; comportamento do kernel; mecanismos de virtualização; interfaces utilizadas por aplicações legadas.
A própria Microsoft mantém uma relação de recursos removidos ou descontinuados do Windows Server, justamente porque aplicações que dependem deles podem deixar de funcionar em versões futuras.
Isso significa que a compatibilidade precisa ser tratada como um processo de engenharia, não apenas como uma etapa administrativa de atualização.
O impacto para ambientes industriais
Servidores Windows aparecem em uma quantidade enorme de sistemas de supervisão, historiadores, aplicações MES, bancos de dados, sistemas de engenharia, plataformas de gestão de ativos e componentes de infraestrutura OT/IT. Uma mudança de comportamento do sistema operacional pode não derrubar diretamente um controlador de processo, mas pode interromper uma camada de software que fornece dados, histórico, diagnóstico ou interface operacional para o processo.
Em ambientes industriais, portanto, a pergunta antes de uma migração é:
“Quais mecanismos do sistema operacional essa aplicação utiliza e quais deles mudaram entre as versões?” Essa diferença é fundamental e o incidente também reforça uma tendência importante na gestão de infraestrutura: dependências de software precisam ser tratadas como parte do ativo tecnológico.
