MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Erreur « Failed to load dll from …\hostfxr.dll » (HRESULT 0x80070057) sur Windows Server 2008 R2 SP1 : diagnostic et correctifs .NET/x86/x64

Erreur « Failed to load dll from …\hostfxr.dll » (HRESULT 0x80070057) sur Windows Server 2008 R2 SP1 : diagnostic et correctifs .NET/x86/x64

Windows Server

Sur Windows Server 2008 R2 SP1, l’installation d’une appli .NET échoue avec « Failed to load dll from …\hostfxr.dll » (0x80070057) ? Ce guide pas‑à‑pas explique la cause, comment diagnostiquer précisément et les correctifs fiables à appliquer, même sur un OS ancien.

Sommaire

Vue d’ensemble de la question

Lors de l’installation ou du lancement d’une application .NET (ex. RVAgent.exe) sur Windows Server 2008 R2 SP1, l’Observateur d’événements enregistre :

  • A .NET Core application failed
  • Failed to load the dll from …\hostfxr.dll avec HRESULT: 0x80070057

Plusieurs runtimes .NET installés ne changent rien : l’appli refuse de démarrer.

Ce que signifie l’erreur

  • hostfxr.dll est le chargeur/démarreur des applis .NET (Core/5/6/7/8).
  • 0x80070057 correspond à « paramètre incorrect ». En pratique, cela survient surtout quand le runtime résolu est incompatible (version, architecture, OS), ou quand la DLL ne peut pas se charger (corruption, dépendance native manquante, blocage sécurité).

Pourquoi c’est fréquent sur Windows Server 2008 R2 SP1

Windows Server 2008 R2 SP1 est en fin de vie et ne prend plus en charge la plupart des versions récentes de .NET. Les runtimes modernes (.NET 5, 6, 7, 8) ne ciblent plus 2008 R2 ; au mieux, des versions historiques comme .NET Core 2.x/3.1 pouvaient fonctionner avec des prérequis système. Résultat : si l’appli a été compilée pour un runtime non supporté par l’OS, hostfxr.dll échouera très tôt avec ce code d’erreur.

Signaux forts et causes probables

  • Incompatibilité OS / version .NET : l’appli demande un runtime que 2008 R2 ne supporte pas.
  • Incohérence d’architecture : appli 32 bits (Program Files (x86)) qui tente d’utiliser un runtime 64 bits (ou l’inverse).
  • Runtime manquant ou version différente : la version précise exigée par .runtimeconfig.json n’est pas installée.
  • DLL corrompue/doublons : hostfxr.dll locale ou endommagée, conflit dans PATH.
  • Blocage sécurité : AppLocker/SRP, EDR/antivirus ou ACL NTFS empêchent le chargement.

Diagnostic express

  1. Identifier la cible .NET et l’archi : ouvrir <Appli>.runtimeconfig.json et noter framework.name/version et si l’appli est x86 (installée sous Program Files (x86)).
  2. Interroger le runtime installé : "C:\Program Files (x86)\dotnet\dotnet.exe" --list-runtimes "C:\Program Files (x86)\dotnet\dotnet.exe" --info Vérifier que la même version existe en x86 si l’appli est x86.
  3. Stabiliser la résolution avec les variables d’environnement : DOTNET_ROOT=C:\Program Files\dotnet DOTNET_ROOT(x86)=C:\Program Files (x86)\dotnet Placer C:\Program Files (x86)\dotnet\ avant C:\Program Files\dotnet\ dans PATH pour une appli x86.
  4. Installer la version manquante (exacte) et l’édition ASP.NET Core Hosting Bundle si appli web.
  5. Écarter les doublons : renommer une éventuelle hostfxr.dll dans le dossier de l’appli.
  6. Tracer le chargeur si ça bloque encore : setx COREHOST_TRACE 1 /M setx COREHOST_TRACEFILE "C:\Temp\corehost_load.log" /M Relancer l’appli et analyser le journal.

Mapping rapide symptômes → causes → correctifs

SymptômeCause la plus probableCorrectif recommandé
0x80070057 dès le démarrageRuntime non supporté par 2008 R2Exiger une build ciblant un runtime supporté par 2008 R2 ou migrer l’hôte
Appli x86 sous Program Files (x86)Résolution vers runtime x64Forcer DOTNET_ROOT(x86), réordonner PATH, installer le runtime x86
Fonctionne sur un autre serveurDépendance native manquante / DLL corrompueRéinstaller/repair du runtime, VC++ Redistributable, SHA‑2, UCRT
Échec après durcissement sécuritéAppLocker/EDR bloque dotnet.exe ou hostfxr.dllCréer des règles d’autorisation et exclure les dossiers dotnet et de l’appli
Présence d’une hostfxr.dll dans le dossier de l’appliConflit de DLLSupprimer/renommer la DLL locale pour laisser le runtime officiel s’appliquer

Procédure détaillée pas‑à‑pas

Identifier la version et l’architecture requises

Dans le dossier de l’application, ouvrez <NomAppli>.runtimeconfig.json. Recherchez :

{
  "runtimeOptions": {
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "X.Y.Z"
    },
    "rollForward": "LatestMinor"
  }
}

Notez :

  • La version exacte de Microsoft.NETCore.App (et Microsoft.AspNetCore.App si présent).
  • Le type de déploiement : framework-dependent (dépend d’un runtime installé) ou self-contained (runtime embarqué).
  • Le contexte d’architecture : si l’appli s’installe sous Program Files (x86), elle est x86.

Vérifier ce que l’OS voit réellement

Sur un OS 64 bits, on peut coexister avec deux runtimes :

  • x64 : C:\Program Files\dotnet\
  • x86 : C:\Program Files (x86)\dotnet\

Interrogez le bon exécutable :

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

Si la version X.Y.Z est absente en x86, installez-la. Ne comptez pas sur une version x64 pour une appli x86.

Stabiliser la résolution de runtime

Définissez systématiquement :

VariableValeur conseilléePourquoi
DOTNET_ROOTC:\Program Files\dotnetIndique l’emplacement du runtime x64
DOTNET_ROOT(x86)C:\Program Files (x86)\dotnetIndique l’emplacement du runtime x86
PATHMettre …(x86)\dotnet\ avant …\dotnet\ si appli x86Évite qu’un dotnet.exe x64 soit pris par erreur

Installer la version manquante et correspondante

  • Installez la même version que celle demandée, dans la bonne architecture (x86 pour appli x86).
  • Pour une appli web, ajoutez le Hosting Bundle ASP.NET Core correspondant.
  • Évitez de « sauter » de version en espérant que le roll-forward réglera le problème : sur 2008 R2, la compatibilité OS prime.

Nettoyer les doublons et DLL locales

La présence d’une hostfxr.dll dans le dossier de l’application peut détourner la résolution. Renommez-la provisoirement (_hostfxr.dll.bak) et relancez.

Traçage détaillé du chargeur

Activez le traçage pour savoir quelle DLL est tentée et pourquoi elle échoue :

setx COREHOST_TRACE 1 /M
setx COREHOST_TRACEFILE "C:\Temp\corehost_load.log" /M

Exemple de fragments utiles dans le journal :

Tracing enabled
--- Invoked dotnet hostfxr resolve ---
App: C:\Program Files (x86)\Vendor\App\RVAgent.exe
Searching for hostfxr.dll...
Probed: C:\Program Files\dotnet\host\fxr\...
Probed: C:\Program Files (x86)\dotnet\host\fxr\...
Failure: incompatible RID or unsupported OS
HRESULT: 0x80070057

Scénarios concrets et solutions

Appli 32 bits qui résout un runtime 64 bits

Symptômes : l’exécutable est sous Program Files (x86) mais --info montre seulement des runtimes x64. Le journal hostfxr indique d’abord C:\Program Files\dotnet\....

Correctifs :

  • Installer le runtime x86 exact.
  • Définir DOTNET_ROOT(x86) et prioriser …(x86)\dotnet\ dans le PATH.

Appli construite pour .NET 6/7 sur 2008 R2

Symptômes : impossible d’exécuter, 0x80070057 systématique, même en self‑contained.

Raison : le runtime moderne ne prend plus en charge 2008 R2. Le déploiement self‑contained n’outrepasse pas les limites de l’OS : si le runtime ne sait pas démarrer sur 2008 R2, l’exécutable échoue tout de même.

Correctifs :

  • Demander à l’éditeur une build ciblant un runtime supporté par 2008 R2 (par ex. .NET Core 3.1) ou migrer l’application vers un OS supporté.

DLL locales ou corruption

Symptômes : une hostfxr.dll est livrée à côté de l’appli ; après suppression, l’erreur change ou l’appli démarre.

Correctifs :

  • Supprimer la DLL locale pour laisser la résolution standard s’opérer.
  • Réparer/réinstaller le runtime .NET concerné.

Pré-requis système importants sur 2008 R2

Certains composants système sont indispensables au chargement des dépendances natives :

Composant / mise à jourUtilitéRemarques
Support SHA‑2 (ex. KB4474419) + SSU (ex. KB4490628)Valider la signature des binaires récentsObligatoire pour installer/mettre à jour des runtimes modernes
Visual C++ Redistributable 2015–2022Fournit UCRT et CRT requis par le runtimeInstallez les éditions x86 et x64 sur OS 64 bits
Correctifs cumulés récentsAPI système et sécuritéRéduit les risques d’échec de chargement
Activation TLS 1.2Téléchargements et mises à jour sécurisésRecommandé pour référentiels internes/externes

Sécurité : AppLocker, SRP, antivirus/EDR

Les stratégies d’exécution peuvent bloquer dotnet.exe, hostfxr.dll ou l’exécutable de l’appli. Points à vérifier :

  • Journal AppLocker/SRP : événements de refus sur dotnet.exe, hostfxr.dll, RVAgent.exe.
  • Règles d’autorisation basées sur éditeur/chemin/hachage pour C:\Program Files\dotnet\, C:\Program Files (x86)\dotnet\ et le dossier de l’appli.
  • Exclusions EDR/AV sur les répertoires dotnet et l’arborescence de l’application.
  • Contrôle des ACL NTFS : lecture/exécution pour les comptes de service.

Vérifications et commandes utiles

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

Version PowerShell pour inventorier proprement :

powershell -NoProfile -Command ^
  "&amp; 'C:\Program Files (x86)\dotnet\dotnet.exe' --list-runtimes; ^
     &amp; 'C:\Program Files\dotnet\dotnet.exe' --list-runtimes"

Script PowerShell minimal pour vérifier les variables d’environnement et l’ordre du PATH :

powershell -NoProfile -Command ^
  "$env:DOTNET_ROOT; $env:('DOTNET_ROOT(x86)'); ^
   ($env:PATH -split ';' | Where-Object { $_ -match '\\dotnet\\' })"

Bonnes pratiques de packaging et de déploiement

  • Clarifier la cible (RID/architecture) au moment de la build.
  • Éviter d’embarquer hostfxr.dll aux côtés de l’appli, sauf scénario maîtrisé.
  • Documenter les versions minimales d’OS prises en charge et les prérequis.
  • Tester sur une VM 2008 R2 « miroir » avec les mêmes GPO/EDR avant déploiement.

Self‑contained vs framework‑dependent

Le déploiement self‑contained inclut le runtime, mais n’annule pas la dépendance à l’OS. Si le runtime inclus ne supporte pas 2008 R2, il échouera tout de même au chargement avec une erreur hostfxr. Pour 2008 R2, il faut aussi une version de runtime historiquement compatible.

Quand escalader ou changer d’hôte

  • Si l’appli exige .NET 5/6/7/8 sur 2008 R2, seule une mise à niveau d’OS (ou une build ciblant un runtime ancien) résout durablement.
  • Si l’éditeur fournit uniquement une build non compatible 2008 R2, planifier la migration du serveur.

Étude de cas rapide

Contexte : RVAgent.exe installé sous Program Files (x86). --list-runtimes : uniquement des runtimes x64. Erreur 0x80070057.

Actions :

  1. Installation du runtime .NET x86 à la version exacte.
  2. Définition de DOTNET_ROOT(x86) et priorité de …(x86)\dotnet\ dans le PATH.
  3. Renommage d’une hostfxr.dll locale trouvée dans le dossier de l’appli.
  4. Vérification AppLocker : règle d’autorisation sur dotnet.exe.

Résultat : l’agent démarre, plus d’événements « A .NET Core application failed ».

Checklist finale

  • La version Microsoft.NETCore.App exigée par .runtimeconfig.json est identifiée.
  • Le runtime est installé dans la bonne architecture (x86/x64) et visible via --list-runtimes.
  • DOTNET_ROOT et DOTNET_ROOT(x86) sont définies, PATH ordonné correctement.
  • Aucune hostfxr.dll parasite dans le dossier de l’appli.
  • AppLocker/EDR autorisent dotnet.exe, hostfxr.dll et l’exécutable de l’application.
  • Mises à jour critiques (SHA‑2, SSU), VC++ Redistributable et UCRT en place.
  • Si la cible runtime n’est pas supportée par 2008 R2 : migration d’OS ou nouvelle build demandée à l’éditeur.

FAQ

« J’ai installé plusieurs runtimes .NET, mais rien ne marche »
Sur 2008 R2, installer « plus récent » n’aide pas si le runtime requis n’est pas supporté par l’OS. Installez la version exacte demandée, dans la bonne architecture.

« Un déploiement self‑contained va régler le problème, non ? »
Non. Le runtime inclus reste dépendant des capacités de l’OS. S’il ne sait pas démarrer sur 2008 R2, l’exécutable échoue dès hostfxr.

« Est‑ce un problème d’espace disque ? »
Le code 0x80070057 signifie « paramètre incorrect », pas « disque plein ». Pensez d’abord compatibilité OS/archi/runtime.

« Comment être sûr de l’architecture réellement utilisée ? »
Interrogez explicitement le dotnet.exe de Program Files (x86) et regardez le journal COREHOST_TRACE : le chemin probé trahit l’archi.

Conclusion

L’erreur « Failed to load dll from …\hostfxr.dll » avec HRESULT 0x80070057 est presque toujours un problème de compatibilité : version .NET non supportée par Windows Server 2008 R2, mauvaise architecture x86/x64, ou résolution de runtime perturbée par PATH/DLL locale/politique de sécurité. En appliquant la méthode ci‑dessus — identification précise de la cible, vérification des runtimes installés, stabilisation de la résolution, nettoyage et, si besoin, mise à niveau de l’OS — vous rétablissez un lancement stable et documenté de l’application.

Windows Server
.NET Core Windows Server 2008 R2 0x80070057 hostfxr.dll x86 Runtime .NET
Sommaire