Errore “Failed to load dll from hostfxr.dll” (0x80070057) su Windows Server 2008 R2: cause reali e guida alla soluzione

Durante l’installazione di RVAgent.exe su Windows Server 2008 R2 SP1 può comparire l’errore “Failed to load dll from … hostfxr.dll” (HRESULT 0x80070057). In questa guida trovi cause reali, diagnostica e una procedura risolutiva completa per riportare l’installazione a buon fine.

Indice

Che cosa succede

L’installazione o l’esecuzione dell’agente termina prematuramente e nel Visualizzatore eventi (Event Viewer > Windows Logs > Application) compare un messaggio simile:

Failed to load dll from [C:\Program Files\dotnet\host\fxr\3.1.x\hostfxr.dll], HRESULT: 0x80070057
The library hostfxr.dll was found but could not be loaded.

Il codice 0x80070057 indica, in generale, un parametro non valido o un file inutilizzabile. In pratica, il loader .NET trova hostfxr.dll ma non riesce a inizializzarlo o a risolverne le dipendenze.

Cos’è `hostfxr.dll` e perché è centrale

hostfxr.dll è la libreria del .NET Core hosting layer che si occupa di:

determinare versione e posizione del runtime .NET richiesto;
selezionare l’implementazione corretta in base a architettura (x64/x86) e policy;
avviare l’applicazione caricando hostpolicy.dll e il CoreCLR.

Se hostfxr.dll non può essere caricato o inizializzato, qualunque app .NET Core/.NET che si affidi al runtime di sistema smette di avviarsi.

Perché accade su Windows Server 2008 R2 SP1

Runtime .NET mancante o incompatibile. L’app (RVAgent.exe) richiede un .NET Core 3.1.x, che è l’ultima famiglia supportata su 2008 R2. Versioni successive (.NET 5/6/7/8) non sono supportate su questo sistema.
Mismatch di architettura. Eseguibile a 32 bit che trova solo un runtime a 64 bit (o viceversa). 2008 R2 è solo x64, ma può eseguire app a 32 bit via WoW64: ciò implica che potresti aver bisogno di entrambi i runtime (x64 e x86).
File danneggiato o bloccato. DLL corrotta, parzialmente copiata, o bloccata da antivirus, AppLocker/Software Restriction Policies, o permessi NTFS insufficienti.
Problemi di storage. Disco quasi pieno, errori NTFS o incoerenze che invalidano la DLL durante il caricamento.
Variabili d’ambiente/PATH inconsistenti. La ricerca della libreria punta a una copia errata (per esempio in C:\Program Files (x86)\dotnet prima della versione x64) o a residui di installazioni precedenti.
Prerequisiti di sistema non aggiornati. Mancanza del Visual C++ 2015–2022 Redistributable (Universal CRT), aggiornamenti SHA-2 e certificati radice aggiornati può impedire la risoluzione delle dipendenze di hostfxr.dll.

Checklist rapida (5 minuti)

Apri un prompt con diritti elevati (Run as Administrator).
Controlla spazio su disco: wmic logicaldisk get caption,freespace,size.
Verifica la presenza del runtime: "C:\Program Files\dotnet\dotnet.exe" --list-runtimes "C:\Program Files (x86)\dotnet\dotnet.exe" --list-runtimes
Controlla l’ordine del PATH: echo %PATH% Assicurati che C:\Program Files\dotnet preceda C:\Program Files (x86)\dotnet per app x64.
Se RVAgent è in Program Files (x86), installa anche il runtime x86.
Disattiva temporaneamente AV/Applocker o crea un’esclusione per RVAgent.exe e cartelle dotnet.

Soluzione passo‑passo

Passo	Azione	Dettagli utili
1	Controlla disco e file system	Verifica spazio libero (almeno 2–3 GB): `wmic logicaldisk get caption,freespace,size` Esegui controlli: `chkdsk C: /f` (richiederà un riavvio) e poi: `sfc /scannow`
2	Pulisci cartelle temporanee	Elimina contenuti temporanei e residui di installazioni fallite: `rmdir /s /q "C:\Program Files (x86)\Alert Logic\bin" del /q /f /s "%TEMP%\." rmdir /s /q "%USERPROFILE%\.dotnet"` Cancella anche `C:\Windows\Temp` se voluminoso (con cautela): `del /q /f /s "C:\Windows\Temp\."`
3	Installa il runtime corretto	Su Windows Server 2008 R2 l’ultima generazione supportata è .NET Core 3.1.x. Installa nell’ordine: Microsoft Visual C++ 2015–2022 Redistributable (x64 e, se necessario, x86). .NET Core 3.1 Runtime corrispondente all’architettura dell’app (x64 per app a 64 bit; aggiungi x86 se l’app è a 32 bit). Opzionale: Hosting Bundle se usi anche app ASP.NET Core su IIS. Riavvia il server dopo l’installazione per sbloccare file in uso.
4	Verifica la presenza del runtime	Esegui: `"C:\Program Files\dotnet\dotnet.exe" --list-runtimes` Atteso: una riga tipo `Microsoft.NETCore.App 3.1.x`. Se l’app è 32 bit, verifica anche: `"C:\Program Files (x86)\dotnet\dotnet.exe" --list-runtimes`
5	Allinea architettura	Se l’eseguibile è in `Program Files (x86)`, considera l’app come x86 e installa/valida dotnet‑runtime‑3.1‑x86 oltre al pacchetto x64. Imposta facoltativamente: `setx DOTNET_ROOT "C:\Program Files\dotnet" /M setx "DOTNET_ROOT(x86)" "C:\Program Files (x86)\dotnet" /M`
6	Escludi blocchi di sicurezza	Aggiungi `RVAgent.exe` e le cartelle `C:\Program Files\dotnet` e/o `C:\Program Files (x86)\dotnet` alle eccezioni antivirus. Verifica AppLocker/SRP: secpol.msc > Criteri di controllo applicazioni > AppLocker. Consenti esplicitamente l’EXE o disattiva temporaneamente le regole per test. Controlla i permessi NTFS della cartella dell’agente e di `C:\Program Files\dotnet` (lettura ed esecuzione per Users, pieno controllo per Administrators).
7	Riprova l’installazione	Esegui il setup come Administrator. Se il problema persiste, attiva un tracing dettagliato e usa Process Monitor: `setx COREHOST_TRACE 1 setx COREHOST_TRACEFILE "C:\corehost.log"` Avvia di nuovo l’installazione e poi analizza `C:\corehost.log` per capire quale percorso o libreria fallisce. Con ProcMon, filtra per `Process Name = RVAgent.exe` e cerca esiti ACCESS DENIED, NAME NOT FOUND o PATH NOT FOUND su `hostfxr.dll` e directory `\dotnet\host\fxr`.

Approfondimento: riconoscere rapidamente il mismatch x86/x64

Dove vive l’EXE? In Program Files = quasi certamente x64; in Program Files (x86) = x86.
PATH in conflitto: se C:\Program Files (x86)\dotnet precede il path x64, un’app a 64 bit potrebbe cercare il runtime a 32 bit causando il fallimento del caricamento di hostfxr.dll.
Variabili d’ambiente consigliate (oltre al PATH): setx DOTNET_ROOT "C:\Program Files\dotnet" /M setx "DOTNET_ROOT(x86)" "C:\Program Files (x86)\dotnet" /M

Diagnostica mirata dell’errore 0x80070057

Il codice 0x80070057 in questo scenario è spesso la conseguenza di:

DLL trovata ma con dipendenze non risolte (manca la Universal CRT del Visual C++ 2015–2022).
Versione di runtime non supportata dal sistema: il loader rifiuta l’inizializzazione.
Bitness incompatibile: processo x64 che tenta di caricare hostfxr.dll x86 (o viceversa).
File corrotto o segnaposto residuo dopo un’installazione interrotta.

Per discriminare i casi:

Controlla i binari presenti: dir "C:\Program Files\dotnet\host\fxr" /ad dir "C:\Program Files (x86)\dotnet\host\fxr" /ad Dentro troverai le sottocartelle con le versioni disponibili (es. 3.1.32).
Verifica visual C++ installato: wmic product where "Name like '%%Visual C++%%2015-2022%%'" get Name,Version In alternativa, controlla in “Programmi e funzionalità” la presenza delle voci x64/x86.
Traccia del loader: setx COREHOST_TRACE 1 setx COREHOST_TRACEFILE "C:\corehost.log" Il file di log mostra la sequenza di risoluzione del runtime e l’errore puntuale.

Risoluzione dei prerequisiti su 2008 R2

Perché hostfxr.dll carichi correttamente su Windows Server 2008 R2 SP1, assicurati che il server disponga di:

Universal CRT: inclusa nei Visual C++ 2015–2022 Redistributable.
Supporto SHA‑2 per gli aggiornamenti più recenti: installa gli aggiornamenti cumulativi che abilitano le firme SHA‑2 sul sistema (fondamentale se stai distribuendo pacchetti firmati moderni).
Certificati radice aggiornati: il server deve riconoscere le CA moderne per convalidare firme e TLS.
TLS 1.2 abilitato (consigliato) su Schannel per download/installer che negoziano protocolli sicuri. Valuta di abilitare TLS 1.2 su Client e Server via registro (testato in laboratorio, richiede riavvio del servizio).

Correggere conflitti PATH e installazioni orfane

Se sono state eseguite più installazioni nel tempo, può restare un PATH ambiguo o directory “orfane”. Procedi così:

Normalizza il PATH: porta C:\Program Files\dotnet in cima rispetto a C:\Program Files (x86)\dotnet per ambienti prevalentemente x64.
Rimuovi versioni incoerenti: disinstalla da “Programmi e funzionalità” i runtime .NET duplicati o non necessari.
Pulisci manualmente cartelle rimaste dopo la disinstallazione (se presenti): rmdir /s /q "C:\Program Files\dotnet\host\fxr\3.1.-preview" rmdir /s /q "C:\Program Files (x86)\dotnet\host\fxr\3.1.-preview"
Reinstalla il runtime 3.1.x stabile più recente disponibile per 2008 R2 (x64 e, se serve, x86).

Sicurezza: antivirus, AppLocker e permessi

Blocchi di sicurezza sono una causa frequente di caricamento fallito:

Antivirus/EDR: crea esclusioni per RVAgent.exe, la sua directory di installazione e le cartelle dotnet. Evita la scansione in tempo reale durante l’installazione.
AppLocker: se attivo, verifica regole Executable rules. In caso di dubbi, imposta temporaneamente la modalità Audit only e osserva gli eventi corrispondenti.
Permessi: verifica che l’account che esegue l’installazione sia Administrator locale; controlla eredità e ACL sulle cartelle interessate.

Storage e integrità del file system

Errore durante il caricamento di una DLL può derivare da settori difettosi o file troncati:

Esegui chkdsk /f e riavvia.
Esegui sfc /scannow per ripristinare componenti di sistema.
Valuta l’uso del System Update Readiness Tool (CheckSUR) per riparare il servicing store se gli aggiornamenti non si installano.

Diagnostica avanzata con Process Monitor

Avvia Process Monitor (Sysinternals) come Administrator.
Imposta filtri: Process Name is RVAgent.exe | Path contains hostfxr.dll.
Cattura finché non compare l’errore, poi ferma il tracing.
Cerca le operazioni con esito ACCESS DENIED, NAME NOT FOUND, PATH NOT FOUND, SHARING VIOLATION. Questi indizi ti diranno se il problema è di permessi, percorso o lock.

Tabella “errore → causa → rimedio”

Messaggio/Segnale	Probabile causa	Rimedio
hostfxr.dll found but could not be loaded	Manca Universal CRT (VC++), file corrotto	Installa/repara Visual C++ 2015–2022; reinstalla .NET Core 3.1; riavvia
Log `COREHOST_TRACE` che punta a `Program Files (x86)` ma l’app è x64	PATH errato / DOTNET_ROOT(x86) prioritario	Correggi ordine PATH; imposta `DOTNET_ROOT`; rimuovi runtime x86 se inutile
ProcMon: ACCESS DENIED su `\dotnet\host\fxr\...`	Antivirus/Applocker/ACL	Esclusione AV, regola AppLocker, concedi Read & Execute agli utenti di servizio
ProcMon: NAME NOT FOUND per la versione richiesta	Runtime non installato o versione sbagliata	Installa `Microsoft.NETCore.App 3.1.x` corrispondente all’architettura
Eventi WER durante l’installazione	File system danneggiato o file lock	`chkdsk /f`, `sfc /scannow`, riavvio e nuova installazione

Extra suggerimenti e buone pratiche

Fine del supporto: .NET Core 3.1 è fuori supporto. Se possibile, valuta l’upgrade del server (ad es. 2012 R2/2016) per usare .NET 6/8 LTS e migliorare sicurezza e supportabilità.
Distribuzione self‑contained: se hai accesso al progetto, pubblica l’app così: dotnet publish -r win7-x64 -c Release --self-contained true (usa win7-x86 per app a 32 bit). In questo modo l’app include il proprio runtime e riduce la dipendenza dal sistema.
Prerequisiti di sistema: assicurati che il server disponga di Universal CRT, supporto SHA‑2 e certificati radice aggiornati. Evita server isolati e senza patch: il caricamento delle DLL moderne può fallire.
PowerShell più recente (opzionale): installare Windows Management Framework 5.1 semplifica la diagnostica (Get-ChildItem, Get-FileHash, ecc.).

FAQ

Devo installare sia il runtime x64 che quello x86?

Su 2008 R2, il sistema è x64. Se qualche componente dell’app è a 32 bit (installato in Program Files (x86)), installa anche dotnet‑runtime‑3.1‑x86. In caso di dubbi, è sicuro avere entrambi i runtime.

Come capisco quale copia di `dotnet.exe` viene usata?

Esegui:

where dotnet

La prima voce è quella effettivamente in uso. Se punta a Program Files (x86) ma stai lanciando un processo x64, correggi l’ordine del PATH.

Posso aggiornare direttamente a .NET 6/8?

Non su Windows Server 2008 R2. Per usare .NET 6/8 occorre migrare il sistema a una versione di Windows Server supportata.

Il problema si ripresenta dopo un riavvio: cosa controllo?

Verifica che servizi AV non stiano ripristinando regole restrittive, che PATH e variabili DOTNET_ROOT non vengano sovrascritte da GPO, e che nessuno strumento di hardening stia imponendo blocchi a eseguibili non firmati.

Come verifico rapidamente la versione di `hostfxr` presente?

Elenca le versioni installate:

dir "C:\Program Files\dotnet\host\fxr" /ad
dir "C:\Program Files (x86)\dotnet\host\fxr" /ad

La cartella 3.1.x deve esistere almeno in una delle due posizioni in base all’app.

Script di verifica “tutto in uno” (facoltativo)

Esegui come Administrator per ottenere un quadro d’insieme dello stato del server.

@echo off
echo === Spazio su disco ===
wmic logicaldisk get caption,freespace,size

echo.
echo === Runtime .NET (x64) ===
if exist "C:\Program Files\dotnet\dotnet.exe" (
"C:\Program Files\dotnet\dotnet.exe" --list-runtimes
) else (
echo dotnet.exe x64 non trovato
)

echo.
echo === Runtime .NET (x86) ===
if exist "C:\Program Files (x86)\dotnet\dotnet.exe" (
"C:\Program Files (x86)\dotnet\dotnet.exe" --list-runtimes
) else (
echo dotnet.exe x86 non trovato
)

echo.
echo === Visual C++ 2015-2022 installato ===
wmic product where "Name like '%%Visual C%%2015%%'" get Name,Version
wmic product where "Name like '%%Visual C%%2022%%'" get Name,Version

echo.
echo === Percorsi hostfxr ===
dir "C:\Program Files\dotnet\host\fxr" /ad
dir "C:\Program Files (x86)\dotnet\host\fxr" /ad

echo.
echo === PATH (prime 3 voci) ===
for /f "tokens=1,2,3 delims=;" %%a in ("%PATH%") do (
echo 1: %%a
echo 2: %%b
echo 3: %%c
goto \:break
)
\:break
echo.
echo Verifica completata.

In sintesi

L’errore “Failed to load dll from … hostfxr.dll” (0x80070057) durante l’installazione di RVAgent su Windows Server 2008 R2 SP1 deriva quasi sempre da un runtime .NET Core incompatibile o assente, oppure da un mismatch di architettura. Segui la procedura:

Controllo di disco e integrità file di sistema (chkdsk, sfc);
Pulizia di temporanei e residui;
Installazione o riparazione di Visual C++ 2015–2022 e .NET Core 3.1.x (x64/x86 secondo necessità);
Verifica dei runtime installati e allineamento architettura;
Esclusione da AV/Applocker e correzione di permessi;
Nuova installazione con tracing (COREHOST_TRACE) e, se serve, analisi ProcMon.

Con queste azioni, l’installazione dell’agente dovrebbe completarsi senza più l’errore di caricamento di hostfxr.dll.

Appendice: comandi utili di riepilogo

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

\:: Conferma percorsi hostfxr
dir "C:\Program Files\dotnet\host\fxr" /ad
dir "C:\Program Files (x86)\dotnet\host\fxr" /ad

\:: Imposta variabili d'ambiente consigliate
setx DOTNET\_ROOT "C:\Program Files\dotnet" /M
setx "DOTNET\_ROOT(x86)" "C:\Program Files (x86)\dotnet" /M

\:: Tracing del loader
setx COREHOST\_TRACE 1
setx COREHOST\_TRACEFILE "C:\corehost.log"

\:: Ripristino sistema
chkdsk C: /f
sfc /scannow

Nota finale: poiché Windows Server 2008 R2 è a fine vita, considera una migrazione a una versione supportata per benefici in stabilità, sicurezza e compatibilità con le versioni più recenti di .NET.