Como corrigir o erro “Failed to load hostfxr.dll (HRESULT: 0x80070057)” ao instalar .NET Core no Windows Server 2008 R2 SP1

Ao instalar ou arrancar um app .NET Core no Windows Server 2008 R2 SP1 (ex.: RVAgent.exe em C:\Program Files (x86)\Alert Logic\bin\), o Visualizador de Eventos mostra “The library hostfxr.dll was found, but loading it failed (HRESULT: 0x80070057)”? Siga este guia para resolver de forma objetiva.

Índice

Contexto e mensagem do erro

Em servidores antigos, especialmente o Windows Server 2008 R2 SP1, é comum ver no Event Viewer uma entrada semelhante a:

A .NET Core application failed...
The library hostfxr.dll was found, but loading it failed (HRESULT: 0x80070057).

Este erro surge no arranque de aplicações .NET Core/ASP.NET Core framework-dependent (que precisam do runtime instalado no sistema) quando algo impede o carregamento correto da hostfxr.dll, o primeiro componente nativo do host .NET.

O que o código 0x80070057 quer dizer

O HRESULT 0x80070057 mapeia, de forma genérica, para “parâmetro inválido” no contexto de APIs do Windows. No ecossistema .NET Core, ele aparece quando:

Há incompatibilidade de arquitetura (processo x86 a tentar carregar biblioteca x64 ou vice‑versa).
O runtime ou framework exigido pelo app não está instalado ou é de versão/linha diferente.
Faltam dependências nativas (ex.: Universal CRT / Visual C++ Redistributable) exigidas pelas DLLs do host (hostfxr.dll / hostpolicy.dll).
Alguma política ou segurança impede o load (AppLocker, antivírus/EDR, ACLs).
Corrupção de ficheiro ou PATH/variáveis de ambiente mal definidas.

Sintomas típicos observados

O executável inicia e termina instantaneamente, registando apenas o evento acima.
Instalar “várias versões do .NET” não resolve, sobretudo quando todas são x64 e o app é x86.
Em alguns casos, o log detalhado (ver adiante) acusa falta de api-ms-win-*.dll (indício de UCRT ausente no 2008 R2).

Causas prováveis e como confirmar

Causa	Indícios	Como confirmar	Resolução
Arquitetura trocada	App em `Program Files (x86)`; apenas runtime x64 instalado	Listar runtimes x86/x64 (ver comandos abaixo); ativar `COREHOST_TRACE`	Instalar runtime x86 correspondente; alinhar `DOTNET_ROOT(x86)`
Versão de runtime errada	App pede 2.1/3.1/5.0 e só há 6/7/8 instalados	Ler `.runtimeconfig.json` do app; `dotnet --list-runtimes`	Instalar a linha exata exigida (ou superior compatível dentro da mesma linha)
Dependências nativas em falta	Erros com `vcruntime140.dll` / `api-ms-win-*.dll`	Log do host; `procmon` (se disponível)	Instalar Microsoft Visual C++ 2015–2022 Redistributable x86 e atualizações UCRT
Variáveis de ambiente incorretas	`DOTNET_ROOT` aponta para x64 num processo x86	`set` / `echo %DOTNET_ROOT(x86)%`	Ajustar/remover; garantir PATH a `C:\Program Files (x86)\dotnet`
Segurança/bloqueio	Antivírus/EDR ou AppLocker	Eventos de segurança; tentativas de carga bloqueadas	Exceções temporárias e validação com equipa de segurança

Checklist rápido para corrigir

Verifique a versão e arquitetura que o app exige (.runtimeconfig.json) e os runtimes instalados (x86/x64).
Instale o .NET Runtime x86 apropriado; se for app web, instale também o ASP.NET Core Hosting Bundle x86.
Instale o Microsoft Visual C++ 2015–2022 Redistributable x86 e as atualizações do sistema que trazem a UCRT ao 2008 R2.
Ajuste PATH e DOTNET_ROOT(x86).
Desative temporariamente o antivírus/AppLocker (ou crie exceções) e limpe temporários.
Ative o COREHOST_TRACE para confirmar a causa exata.

Passo a passo detalhado

Identificar a versão e a arquitetura exigidas pelo app

Na pasta do executável (...Alert Logic\bin), procure um ficheiro <nome>.runtimeconfig.json. Abra-o e anote a linha/versão do framework:

{
  "runtimeOptions": {
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "3.1.32"
    }
  }
}

Depois, verifique os runtimes disponíveis nas duas arquiteturas (execute em cmd com privilégios de administrador):

"C:\Program Files\dotnet\dotnet.exe" --list-runtimes
"C:\Program Files (x86)\dotnet\dotnet.exe" --list-runtimes

Se a app estiver em Program Files (x86), é muito provável que seja x86; portanto, precisa do runtime x86 correspondente. Ter apenas o runtime x64 não chega.

Instalar o runtime correto e, se aplicável, o Hosting Bundle

Instale a mesma linha de runtime que aparece no .runtimeconfig.json (por exemplo, 3.1.x se o ficheiro exigir 3.1).
Instale a arquitetura certa: x86 para apps x86. Em ambientes mistos, pode ser útil ter ambos, mas a app usam aquele compatível com o seu processo.
Para apps web/serviços no IIS, instale também o ASP.NET Core Hosting Bundle x86 da mesma linha do runtime, para garantir os módulos do IIS e a integração correta.

Após instalar, reinicie o servidor (especialmente em 2008 R2, onde atualizações de runtimes e redistribuíveis podem precisar de reinicialização para registar corretamente os componentes nativos).

Instalar dependências nativas (VC++ Redistributable e UCRT)

Em Windows Server 2008 R2 SP1, a pilha nativa do host .NET exige componentes do Universal CRT (UCRT). Instale estes pacotes, sempre na arquitetura do processo:

Microsoft Visual C++ 2015–2022 Redistributable (x86)
Atualizações do Windows que trazem a UCRT ao 2008 R2 (se usa WSUS, verifique se foram aprovadas).

Sem estes componentes, é comum ver falhas relacionadas a vcruntime140.dll, api-ms-win-core-*.dll ou simplesmente o hostfxr.dll falhar a carregar com 0x80070057.

Garantir correspondência de arquitetura e caminhos do .NET

Confirme que o PATH e as variáveis de ambiente apontam para os diretórios corretos. Exemplos úteis:

where dotnet
set DOTNET_ROOT
set "DOTNET_ROOT(x86)"
echo %PROCESSOR_ARCHITECTURE%

Caso necessário, defina explicitamente o diretório do runtime x86:

setx "DOTNET_ROOT(x86)" "C:\Program Files (x86)\dotnet"

Evite manter uma hostfxr.dll “solta” junto ao executável (copiada à mão ou de outra instalação). Prefira utilizar a que vem do runtime instalado ou uma distribuição self‑contained fornecida pelo fabricante.

Eliminar bloqueios e corrupções

Antivírus/EDR: crie exceção para a pasta do app e para C:\Program Files (x86)\dotnet\. Teste desativando temporariamente, se a política permitir.
AppLocker: verifique as regras de execução; apps .NET Core podem carregar DLLs nativas de subpastas.
Espaço em disco: garanta espaço no sistema e em %TEMP% (o host pode extrair componentes temporários). Limpeza rápida:

del /s /q "%LOCALAPPDATA%\Temp\*"
del /s /q "%WINDIR%\Temp\*"

Integridade do volume: verifique numa janela de manutenção.

chkdsk C: /f
sfc /scannow

Ativar diagnóstico detalhado do host (.NET Host Tracing)

O host do .NET tem um trace nativo que revela, com precisão, porque falhou o carregamento:

set COREHOST_TRACE=1
set COREHOSTTRACEFILE=C:\Temp\corehosttrace.txt
"C:\Program Files (x86)\Alert Logic\bin\RVAgent.exe"
notepad C:\Temp\corehost_trace.txt

No ficheiro de trace, procure por pistas como:

Failed to load [path]\hostpolicy.dll → geralmente falta do runtime certo ou UCRT.
Specified architecture was x86 but found x64 → arquitetura trocada.
Framework 'Microsoft.NETCore.App', version X.Y.Z was not found → instale a linha correta.

Quando nenhuma medida resolve

Reinstale na arquitetura certa: se existir instalador x86 da aplicação (ex.: RVAgent), preferir esse em servidores que executem o processo em 32 bits.
Confirme com o fornecedor se há build compatível com o Windows Server 2008 R2 SP1 ou versão self‑contained (que não exige runtime global).
Atualize o sistema operativo: muitas versões recentes do .NET não suportam oficialmente o 2008 R2, e a manutenção torna‑se progressivamente inviável.

Exemplos práticos de correção

App x86 a arrancar com runtime x64

Sintoma: app em Program Files (x86); apenas C:\Program Files\dotnet existe; erro 0x80070057.

Correção: instalar .NET Runtime x86 da mesma linha pedida no .runtimeconfig.json, ajustar DOTNET_ROOT(x86) e garantir que o PATH contém C:\Program Files (x86)\dotnet.

Falta de UCRT no Windows Server 2008 R2

Sintoma: trace aponta api-ms-win-core-* ausente; Event Viewer só mostra a falha genérica.

Correção: aplicar as atualizações do sistema (WSUS/Windows Update) que instalam a Universal CRT e instalar o VC++ 2015–2022 Redistributable x86. Reiniciar e testar.

Conflito devido a hostfxr.dll copiada manualmente

Sintoma: existe uma hostfxr.dll “local” ao lado do executável, de versão antiga. O trace mostra mistura de versões.

Correção: remover a DLL deslocada; usar o runtime global correto ou converter o deployment para self‑contained fornecido pelo fabricante.

Tabela de verificação e comandos úteis

Objetivo	Comando	Interpretação
Listar runtimes x64	`"C:\Program Files\dotnet\dotnet.exe" --list-runtimes`	Confirma versões instaladas em 64 bits
Listar runtimes x86	`"C:\Program Files (x86)\dotnet\dotnet.exe" --list-runtimes`	Confirma versões instaladas em 32 bits
Ver arquitetura do processo	`echo %PROCESSOR_ARCHITECTURE%`	Indica ambiente do CMD atual; apps em `(x86)` tendem a ser 32 bits
Ver PATH efetivo	`where dotnet`	Confirma prioridade de `dotnet.exe` no PATH
Definir DOTNET_ROOT(x86)	`setx "DOTNET_ROOT(x86)" "C:\Program Files (x86)\dotnet"`	Aponta resolução do host para o runtime x86
Ativar tracing	`set COREHOST_TRACE=1`	Produz `corehost_trace.txt` com detalhes da falha
Limpar temporários	`del /s /q "%LOCALAPPDATA%\Temp\*"`	Liberta espaço e evita interferências de cache

Perguntas frequentes

Instalar apenas o .NET Runtime x64 resolve?

Não, se a aplicação for x86. Um processo 32 bits não carrega DLLs 64 bits. Instale explicitamente o runtime x86 correspondente e garanta que o dotnet.exe x86 está acessível.

Preciso do ASP.NET Core Hosting Bundle?

Se a aplicação corre no IIS ou usa módulos de hospedagem do ASP.NET Core, sim. Instale o Hosting Bundle da mesma linha do runtime e na mesma arquitetura do processo (x86, no cenário em causa).

Posso usar uma versão mais recente do .NET do que a pedida?

Dentro da mesma linha principal (por exemplo, 3.1.x), normalmente pode usar uma versão patch mais recente. Mas mudar de 3.1 para 6/7/8 não é um “upgrade automático” — são linhas diferentes, e o app pode não arrancar.

Como confirmar se a app é x86?

Localização: estar em Program Files (x86) é um forte indício.
Gestor de Tarefas: no 2008 R2, processos 32 bits costumam aparecer marcados (ex.: *32).
TRACE do host: mensagens claras sobre arquitetura trocada.

É obrigatório reiniciar após instalar runtimes/VC++?

Nem sempre, mas no 2008 R2 é altamente recomendado, pois vários componentes nativos e registos de sistema só ficam consistentes após reinício.

O que é uma distribuição “self‑contained”?

É um deployment onde o fornecedor embala o runtime e as DLLs necessárias junto com a app, evitando depender do runtime do sistema. Em servidores legados, isto reduz atrito, mas não elimina a necessidade das dependências nativas do Windows (UCRT/VC++).

Boas práticas para ambientes legados

Padronize a linha de runtime por aplicação e documente no CMDB (ex.: “App X → .NET Core 3.1 x86”).
Mantenha instaladores offline do runtime/Hosting Bundle/VC++ compatíveis com 2008 R2, numa partilha interna.
Automatize verificações com scripts que conferem arquitetura, PATH e presença de runtimes.
Coordene com segurança políticas de AppLocker/EDR para agentes e serviços .NET.
Planeie atualização de SO: 2008 R2 está fora de suporte alargado; minimizar risco operacional é crítico.

Script prático de diagnóstico

Guarde como DiagnosticoDotNet.cmd e execute como administrador.

@echo off
echo === Diagnostico .NET em Windows Server 2008 R2 ===
echo.

echo \[1] Arquitetura do sistema e CMD:
echo   PROCESSOR\ARCHITECTURE=%PROCESSOR\ARCHITECTURE%
echo.

echo \[2] DOTNET\_ROOT vars:
set DOTNET\_ROOT
set DOTNET\_ROOT(x86)
echo.

echo \[3] dotnet no PATH:
where dotnet
echo.

echo \[4] Runtimes x64:
if exist "C:\Program Files\dotnet\dotnet.exe" (
"C:\Program Files\dotnet\dotnet.exe" --list-runtimes
) else (
echo   Nao encontrado: C:\Program Files\dotnet\dotnet.exe
)
echo.

echo \[5] Runtimes x86:
if exist "C:\Program Files (x86)\dotnet\dotnet.exe" (
"C:\Program Files (x86)\dotnet\dotnet.exe" --list-runtimes
) else (
echo   Nao encontrado: C:\Program Files (x86)\dotnet\dotnet.exe
)
echo.

echo \[6] Ativar trace do host e arrancar a app:
set COREHOST\_TRACE=1
set COREHOST\TRACEFILE=%TEMP%\corehost\trace.txt
if exist "C:\Program Files (x86)\Alert Logic\bin\RVAgent.exe" (
"C:\Program Files (x86)\Alert Logic\bin\RVAgent.exe"
echo   Trace gravado em: %TEMP%\corehost\_trace.txt
) else (
echo   Nao encontrei o executavel da app no caminho esperado.
)
echo.
pause

Resumo direto ao ponto

O erro “Failed to load the dll from …\hostfxr.dll (HRESULT: 0x80070057)” é quase sempre mismatch de arquitetura ou runtime incorreto, agravado por dependências nativas em falta num SO antigo.
Verifique .runtimeconfig.json, instale o runtime x86 correto (e Hosting Bundle se for IIS), aplique o VC++ 2015–2022 x86 e a UCRT.
Ajuste DOTNETROOT(x86) e PATH, elimine bloqueios por antivírus/AppLocker, e confirme a causa com COREHOSTTRACE.
Se a app exigir uma linha do .NET sem suporte no 2008 R2, use build compatível ou atualize o SO.

Checklist imprimível

Abrir <app>.runtimeconfig.json e anotar framework.version.
Executar --list-runtimes nos dois caminhos do .NET (x86 e x64).
Instalar .NET Runtime x86 da mesma linha; para IIS, instalar também o Hosting Bundle x86.
Instalar VC++ 2015–2022 x86 e garantir a UCRT no 2008 R2 via Windows Update/WSUS.
Definir DOTNET_ROOT(x86) e validar where dotnet.
Desativar temporariamente antivírus/AppLocker ou criar exceções.
Ativar COREHOSTTRACE e ler o corehosttrace.txt para confirmar a causa.
Em último caso, pedir build self‑contained ao fornecedor ou atualizar o SO.

Conclusão

Resolver o erro da hostfxr.dll no Windows Server 2008 R2 SP1 passa por alinhar versão e arquitetura do runtime .NET com a aplicação, instalar as dependências nativas corretas e garantir que o ambiente do servidor não bloqueia a carga de DLLs. Com o passo a passo, o tracing do host e o checklist acima, a grande maioria dos incidentes é resolvida de forma rápida e reprodutível. Em ambientes corporativos, documente a linha de runtime por aplicação e planeie a modernização do SO para reduzir o risco operacional.