PowerShell fecha imediatamente no Windows Server 2019: erro 0x80070005 no CLR, correção com .NET 4.8 e alternativa com PowerShell 7

Se, ao abrir o Windows PowerShell 5.1 no Windows Server 2019 Datacenter, a janela pisca e some, e o CMD mostra “Starting the CLR failed with HRESULT 0x80070005”, este guia mostra como restaurar o CLR com .NET 4.8 e, se necessário, adotar o PowerShell 7 para normalizar a operação.

Índice

Cenário e sintomas

Ambiente típico: Windows Server 2019 Datacenter (build 17763.5576), Windows PowerShell 5.1. Ao iniciar o powershell.exe, a sessão encerra quase instantaneamente, sem eventos úteis no Event Viewer. Quando executado a partir do cmd.exe, surge a mensagem: Starting the CLR failed with HRESULT 0x80070005.

  • Sem eventos de erro: a falha acontece cedo, antes que o registro de logs consiga ser inicializado pelo host.
  • Código 0x80070005: normalmente significa “Acesso negado” durante a carga do CLR — na prática, costuma indicar permissões/ACLs corrompidas ou arquivos do .NET Framework danificados.
  • Tentativas comuns sem efeito: SFC, DISM, reinstalar o recurso do PowerShell e aplicar patches cumulativos nem sempre reparam uma instalação do .NET danificada.

Principais causas prováveis

HipóteseComo reconhecerImpacto no host
Arquivos do .NET Framework corrompidosFalha instantânea do host gerenciado (powershell.exe) e de outros apps .NET.CLR não inicializa; sem logs de .NET Runtime.
Permissões alteradas nas pastas do .NET0x80070005 ao carregar assemblies; serviços .NET também falham.“Access Denied” ao CLR; GAC inacessível.
Bloqueio por AppLocker ou WDACPolítica nega powershell.exe ou mscoree.dll.Fechamento imediato sem diálogo.
Interferência de antivírus/EDRDrivers de segurança injetam/impedem carregamento do CLR.Comportamento intermitente; falha em processos gerenciados.

Correção rápida e objetiva

Se precisa de um plano direto ao ponto, use a sequência abaixo. Ela foi desenhada para ambientes de produção e minimiza tempo de indisponibilidade.

PassoAção recomendadaObjetivo
PreparaçãoAgende janela, crie backup/snapshot e baixe previamente os instaladores do .NET 4.8 e do PowerShell 7 (MSI).Garantir reversão rápida e operação offline.
Remoção do .NET corrompidoDesinstale o .NET atual (quando possível) e limpe vestígios. Se necessário, use a ferramenta oficial de limpeza do .NET.Eliminar arquivos/ACLs inconsistentes que impedem o CLR.
ReinstalaçãoInstale o .NET Framework 4.8 (runtime suportado para o sistema) e reinicie o servidor.Restaurar o CLR de forma íntegra e suportada.
Alternativa seguraInstale o PowerShell 7 via MSI (ou winget se disponível).PowerShell 7 é baseado em .NET moderno e independe do .NET Framework do sistema, coexistindo com a 5.1.
ValidaçãoConfirme versões e integridade com SFC e DISM.Assegurar que não restaram inconsistências.

Antes de começar

  • Tenha janela de manutenção aprovada e backup funcional (ou snapshot de VM).
  • Execute como Administrador local; confirme whoami /groups contendo Administrators.
  • Guarde instaladores offline do .NET 4.8 e do PowerShell 7 em uma pasta local como C:\Instaladores.
  • Se o servidor roda cargas críticas, comunique times impactados e monitore serviços dependentes de .NET.

Procedimento detalhado de recuperação

Identificar o estado do .NET no sistema

Rode a partir do cmd.exe elevado:

reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release
dism /online /Get-Features /Format:Table | findstr /i "NetFx WCF"
where powershell

Se a consulta Release retornar um valor numérico ausente ou menor que a série do .NET 4.8 (por exemplo, ≥ 528040), é um forte indício de instalação incompleta ou corrompida.

Remover instalações corrompidas do .NET

No Windows Server 2019, parte do .NET faz parte do sistema. Ainda assim, é possível desabilitar componentes opcionais e, em cenários de corrupção, usar as rotinas de limpeza antes da reinstalação:

REM Desabilite componentes opcionais (se listados)
dism /online /Disable-Feature /FeatureName:WCF-Services45 /NoRestart
dism /online /Disable-Feature /FeatureName:WCF-TCP-PortSharing45 /NoRestart
dism /online /Disable-Feature /FeatureName:NetFx4-AdvSrvs /NoRestart

REM Verifique o estado após desabilitar
dism /online /Get-Features /Format\:Table | findstr /i "NetFx WCF" 

Caso a remoção padrão não seja suficiente, utilize a ferramenta oficial de limpeza do .NET Framework para forçar a desinstalação de versões/atualizações inconsistentes. Use-a com cautela, durante janela de manutenção, e reinicie ao término.

Reparar permissões do .NET e do cache de assemblies

O erro 0x80070005 sugere permissões incorretas. Restaure ACLs das pastas do .NET e do GAC antes de reinstalar:

REM Restaure ACLs básicas (use com cautela em produção)
icacls "%windir%\Microsoft.NET" /reset /T /C
icacls "%windir%\Microsoft.NET" /grant:r "NT SERVICE\TrustedInstaller:(F)" "NT AUTHORITY\SYSTEM:(F)" "BUILTIN\Administrators:(F)" "Users:(RX)" /T /C

REM Limpe o cache do NGEN (após a reinstalação do .NET)
"%windir%\Microsoft.NET\Framework64\v4.0.30319\ngen.exe" update
"%windir%\Microsoft.NET\Framework64\v4.0.30319\ngen.exe" executeQueuedItems 

Dica: se políticas de segurança gerenciam ACLs (CIS, STIG, GPOs), revise as regras para não sobrepor o ajuste acima na reinicialização.

Instalar o .NET Framework 4.8

Com o ambiente limpo, instale o runtime suportado. Exemplo de instalação silenciosa via CMD:

cd /d C:\Instaladores
NDP48-x86-x64-AllOS.exe /q /norestart

Reinicie o servidor e valide a instalação:

shutdown /r /t 0
REM Após reiniciar:
reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release

Reinstalar componentes opcionais do .NET

dism /online /Enable-Feature /FeatureName:NetFx4-AdvSrvs /All /NoRestart
dism /online /Enable-Feature /FeatureName:WCF-Services45 /All /NoRestart
dism /online /Enable-Feature /FeatureName:WCF-TCP-PortSharing45 /All /NoRestart

Instalar o PowerShell moderno como alternativa ou reforço

O PowerShell 7 (pwsh.exe) é empacotado com runtime moderno e não depende do .NET Framework presente no sistema, podendo coexistir com a 5.1. Em servidores, o método mais confiável é o MSI. Exemplo:

cd /d C:\Instaladores
msiexec /i PowerShell-7-x64.msi /qn /norestart

Se a ferramenta winget estiver disponível, a instalação também pode ser feita por linha de comando:

winget install --id Microsoft.PowerShell --accept-package-agreements --accept-source-agreements

Valide a execução do PowerShell 7 a partir do CMD:

"C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -Command "$PSVersionTable"

Observação: se a 5.1 permanecer indisponível por restrições do .NET do sistema, manter apenas o PowerShell 7 é suportado em servidores e recebe atualizações de segurança com maior cadência.

Validação pós‑correção

REM Integridade do SO
sfc /scannow
dism /online /Cleanup-Image /RestoreHealth

REM Sanidade do PowerShell 5.1 (se já abrir)
powershell -NoLogo -NoProfile -ExecutionPolicy Bypass -Command "\$PSVersionTable"

REM Sanidade do PowerShell 7
"C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -Command "\$PSVersionTable" 

Fluxo de decisão para ambientes críticos

[Falha ao abrir PowerShell 5.1]
          |
          v
  Verifique Release do .NET -> ausente ou < 4.8?
          |
          +-- Sim --> Desabilite componentes opcionais (DISM) --> Limpe/repáre .NET --> Instale .NET 4.8 --> Reinicie
          |                                                                                                   |
          |                                                                                                   v
          |                                                                                      Valide 5.1 e sistema
          |
          +-- Não --> Suspeite de ACLs/segurança --> Restaure ACLs e revise AppLocker/WDAC --> Teste novamente
          |
          +-- Em paralelo --> Instale PowerShell 7 (MSI) para continuidade operacional

Diagnóstico aprofundado quando o erro persiste

Coletar logs de ligação de assemblies do CLR

Ative o log de Fusion para capturar problemas de binding (desative após análise):

mkdir C:\FusionLogs

REM Vista 64 bits
reg add "HKLM\SOFTWARE\Microsoft\Fusion" /v ForceLog /t REG\_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Fusion" /v LogFailures /t REG\_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Fusion" /v LogResourceBinds /t REG\_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Fusion" /v LogPath /t REG\_SZ /d "C:\FusionLogs" /f

REM Vista 32 bits em SO 64 bits
reg add "HKLM\SOFTWARE\WOW6432Node\Microsoft\Fusion" /v ForceLog /t REG\_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\WOW6432Node\Microsoft\Fusion" /v LogFailures /t REG\_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\WOW6432Node\Microsoft\Fusion" /v LogResourceBinds /t REG\_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\WOW6432Node\Microsoft\Fusion" /v LogPath /t REG\_SZ /d "C:\FusionLogs" /f 

Habilitar captura de crash dumps para o host

Configure o Windows Error Reporting para gravar o dump de powershell.exe:

mkdir C:\Dumps
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\powershell.exe" /v DumpType /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\powershell.exe" /v DumpFolder /t REGEXPANDSZ /d "C:\Dumps" /f

Reproduza o erro para gerar o arquivo. Analise-o com sua ferramenta de depuração preferida para verificar a falha ao carregar o CLR.

Revisar políticas de execução

AppLocker/WDAC podem bloquear a inicialização silenciosamente. Verifique políticas aplicadas e auditoria:

wevtutil qe "Microsoft-Windows-AppLocker/MSI and Script" /f:text /c:50
wevtutil qe "Microsoft-Windows-AppLocker/EXE and DLL" /f:text /c:50

Checar interferência de antivírus ou EDR

Provisoriamente, aplique exclusões temporárias para powershell.exe, pwsh.exe, mscorsvw.exe, ngen.exe e pastas %windir%\Microsoft.NET e %ProgramFiles%\PowerShell. Se o problema desaparecer, refine as políticas de proteção.

Integridade do sistema e reanálise

sfc /scannow
dism /online /Cleanup-Image /ScanHealth
dism /online /Cleanup-Image /RestoreHealth

Comandos úteis de validação

REM Versão do PowerShell 5.1 (se ativo)
powershell -NoProfile -Command "$PSVersionTable"

REM Versão do PowerShell 7
"C:\Program Files\PowerShell\7\pwsh.exe" -NoProfile -Command "\$PSVersionTable"

REM Descobrir qual executável está no PATH
where powershell
where pwsh

REM Verificar variáveis de ambiente relevantes
set DOTNET 

Boas práticas para ambientes de produção

  • Mantenha o .NET 4.8 padronizado em todos os servidores do Windows Server 2019.
  • Implemente o PowerShell 7 lado a lado para administração diária, mantendo a 5.1 apenas para compatibilidade de scripts legados.
  • Controle mudanças em ACLs de %windir%\Microsoft.NET e monitore alterações por GPOs/endereços de segurança.
  • Automatize verificações periódicas de integridade (SFC/DISM) fora do horário de pico.
  • Inclua instaladores offline de emergência no repositório de software da sua organização.

Perguntas frequentes

Preciso desinstalar completamente o .NET antes de instalar o 4.8?

Não necessariamente. Em muitos casos, instalar o .NET 4.8 por cima corrige a corrupção. Porém, quando há erro 0x80070005 no CLR, a limpeza prévia evita que permissões e arquivos quebrados persistam. Se a remoção padrão falhar, use a ferramenta de limpeza do .NET e reinicie. O PowerShell 7 substitui a 5.1?

Não. Ele instala lado a lado. Scripts antigos feitos para 5.1 continuam executando nessa versão; recomenda-se migrá-los gradualmente para o 7, que recebe novidades e correções com mais rapidez.winget não está disponível no servidor. E agora?

No Windows Server 2019, o método mais confiável é o MSI do PowerShell 7. Use msiexec em modo silencioso para automação e implemente via sua ferramenta de gestão (SCCM/Intune/WSUS). Por que não há logs no Event Viewer?

O host do PowerShell é um processo .NET. Se o CLR não inicia, o processo termina antes de acionar provedores de log do .NET Runtime e do próprio PowerShell, resultando em “silêncio” nos logs. Posso ficar somente com o PowerShell 7?

Sim. Vários ambientes operam exclusivamente com o PowerShell 7 em servidores, desde que os scripts e módulos críticos sejam compatíveis. Isso reduz a dependência do .NET Framework legada.

Resumo e próximos passos

O sintoma “PowerShell abre e fecha” com o erro 0x80070005 aponta para problema ao inicializar o CLR, quase sempre ligado a corrupção ou permissões no .NET Framework. A estratégia vencedora é: limpar o estado atual, instalar o .NET 4.8, reiniciar e validar. Paralelamente, implante o PowerShell 7 para garantir continuidade operacional e acelerar atualizações de segurança. Após estabilizar, rode SFC/DISM, revise políticas de segurança (AppLocker/WDAC) e normalize ACLs do .NET para evitar recorrências.

Apêndice de comandos prontos

Copie e cole no cmd.exe elevado conforme necessário, ajustando caminhos:

REM 1) Inventário inicial
reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release
dism /online /Get-Features /Format:Table | findstr /i "NetFx WCF"

REM 2) Desabilitar componentes opcionais .NET
dism /online /Disable-Feature /FeatureName\:WCF-Services45 /NoRestart
dism /online /Disable-Feature /FeatureName\:WCF-TCP-PortSharing45 /NoRestart
dism /online /Disable-Feature /FeatureName\:NetFx4-AdvSrvs /NoRestart

REM 3) Reparar permissões (opcional, mas útil para 0x80070005)
icacls "%windir%\Microsoft.NET" /reset /T /C
icacls "%windir%\Microsoft.NET" /grant\:r "NT SERVICE\TrustedInstaller:(F)" "NT AUTHORITY\SYSTEM:(F)" "BUILTIN\Administrators:(F)" "Users:(RX)" /T /C

REM 4) Instalar .NET 4.8 (silencioso)
cd /d C:\Instaladores
NDP48-x86-x64-AllOS.exe /q /norestart

REM 5) Reiniciar
shutdown /r /t 0

REM 6) Reabilitar recursos opcionais .NET (após reboot)
dism /online /Enable-Feature /FeatureName\:NetFx4-AdvSrvs /All /NoRestart
dism /online /Enable-Feature /FeatureName\:WCF-Services45 /All /NoRestart
dism /online /Enable-Feature /FeatureName\:WCF-TCP-PortSharing45 /All /NoRestart

REM 7) Instalar PowerShell 7
msiexec /i C:\Instaladores\PowerShell-7-x64.msi /qn /norestart

REM 8) Validação final
reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release
"C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -Command "\$PSVersionTable"
sfc /scannow
dism /online /Cleanup-Image /RestoreHealth 

Notas importantes

  • Em ambientes com hardening avançado, alinhe o plano com o time de segurança para evitar que GPOs revertam ACLs ou bloqueiem o instalador.
  • Replique a correção em servidores idênticos para padronizar o parque, preferindo pacotes silenciosos e automação.
  • Documente as versões pós‑mudança (release do .NET e versão do PowerShell) no CMDB.
Índice