L’échec systématique de la mise à jour cumulative KB5058411 (et des correctifs suivants) sous Windows 11 24H2 touche de nombreux postes passés sur la build 26100.1742 : voici un guide complet pour diagnostiquer la cause, appliquer les solutions de contournement les plus sûres et préparer votre parc à la publication du correctif officiel.
Contexte et symptômes
Depuis octobre 2024, plusieurs administrateurs et utilisateurs avancés signalent un blocage récurrent lors de l’installation des mises à jour cumulatives mensuelles pour Windows 11 24H2. Le phénomène se manifeste surtout sur les machines mises à niveau via l’ISO publique 26100.1742 ; il persiste même après une réinstallation propre et concerne les patchs publiés jusqu’au Patch Tuesday de juillet 2025 inclus.
- Codes d’erreur typiques :
0x800f081f(Windows Update),0x800f0838(Windows Update Standalone Installer). - Progression bloquée à 53 % environ, puis redémarrage et nouvelle tentative en boucle.
- Les mises à jour Defender, .NET ou pilotes s’installent sans problème.
Le résultat est frustrant : non seulement la machine reste en retard de correctifs de sécurité, mais le CPU et la bande passante réseau sont régulièrement monopolisés par les tentatives d’installation en boucle.
Machines concernées
Les retours terrain montrent une corrélation forte avec les postes :
- Installés ou réinstallés entre octobre 2024 et avril 2025 à partir de l’ISO publique Windows 11 24H2 (build de base 26100.1742).
- Déployés en masse via MECM/ConfigMgr, Intune ou script PowerShell non interactif.
- Sur lesquels aucune mise à jour de fonctionnalités n’a été appliquée après la clean install — uniquement des cumulatives.
Les machines passées à 24H2 par Windows Update (FU) ou via une ISO plus récente (Sept 2024) semblent quant à elles épargnées.
Analyse des causes techniques
| Élément suspect | Détails synthétiques |
|---|---|
| Magasin de composants (WinSxS) corrompu | DISM remonte des packages « deeply superseded » introuvables :Microsoft‑Windows‑FodMetadataServicing‑Desktop‑Metadata‑Package et PackageforRollupFix (build 26100.1742).Impossible de les récupérer depuis Windows Update ou un support hors ligne. |
| BITS ou dépendances .NET | Les logs CBS montrent des échecs lors du téléchargement différentiel suivi d’une charge incomplète des assemblies .NET. Plusieurs succès terrain proviennent d’une réparation BITS et de l’installation manuelle du runtime .NET 9.0.5. |
| Bug confirmé par Microsoft | Les équipes d’ingénierie Windows Update ont reconnu l’anomalie. Au 09 juillet 2025 aucun correctif n’est publié, mais un patch est « en validation finale » selon le canal Windows Release Health. |
Pourquoi 53 % ?
Cette valeur n’est pas aléatoire : elle correspond à la phase d’application des Differential Updates tout de suite après l’expansion des component baseline packages. Si l’un des packages déclarés comme dépendance est absent ou marqué « deeply superseded » sans substitut valide, le moteur CBS stoppe net.
Méthodes de résolution et contournements testés
| Méthode | Résultat observé | Contexte recommandé |
|---|---|---|
| Réparation standard Windows Update (dépanneur, nettoyage SoftwareDistribution) | Sans effet notable dans la majorité des cas : les dépendances manquantes ne sont ni re‑téléchargées ni régénérées. | N/A : inutile si les erreurs 0x800f081f/0838 sont confirmées. |
DISM /RestoreHealth isolé | Peut rester bloqué ; si le magasin contient des packages orphelins, la réparation échoue. | Étape de diagnostic pour constater l’étendue de la corruption. |
| Réinstallation in‑place ou clean install ISO récente | Poste sain jusqu’au Patch Tuesday suivant, puis retour du problème : non viable à long terme. | Dernier recours sur machine critique, juste avant un gel de production. |
| Task Sequence ConfigMgr : ISO Sept 2024 + cycle dism /disable-feature:.NET3.5 puis /enable-feature | Résout durablement le cycle, validé par Microsoft Premier ; requiert toutefois un redéploiement semi-automatisé. | Environnements d’entreprise disposant de MECM ou Intune. |
| Réparation BITS + installation manuelle ASP.NET Core 9.0.5 et .NET 9.0.5 | Permet la réussite de KB5058411 sur plusieurs HP EliteBook G9 ; succès reproduit sur Dell Latitude. | Postes isolés ou petit parc sans SCCM. |
DISM /StartComponentCleanup /ResetBase + reboot | Sur un échantillon réduit, le nettoyage du magasin (30–45 min) a rétabli les mises à jour suivantes. | Étape « légère » avant de planifier un re‑déploiement complet. |
| Attente du correctif Microsoft | Position officielle : « Pas de réinstallation tant que la machine reste opérationnelle». | Quand la production n’est pas bloquante et que des sauvegardes existent. |
Étapes détaillées pour deux correctifs maison
1. Nettoyage DISM /ResetBase
- Ouvrez un PowerShell élevé.
- Analysez le magasin :
DISM /Online /Cleanup-Image /AnalyzeComponentStore - Si des packages sont listés comme « non réparables », lancez :
DISM /Online /Cleanup-Image /StartComponentCleanup /ResetBase - Redémarrez, puis relancez Windows Update.
Avantages : rapide, pas de perte d’applications. Inconvénient : succès non garanti si le package FodMetadata est totalement absent.
2. Réparation BITS + installation .NET 9.0.5
- Réenregistrez BITS :
sc.exe stop bits sc.exe start bits bitsadmin /reset /allusers - Téléchargez et installez manuellement les deux fichiers :
dotnet-runtime-9.0.5-win-x64.exe et aspnetcore-runtime-9.0.5-win-x64.exe. - Relancez l’installation du KB (WU ou .msu).
Cette approche fonctionne car la cumulative KB5058411 attend des bibliothèques .NET 9 que certains supports 24H2 précoces n’ont pas.
Bonnes pratiques immédiates
- Sauvegardez vos images disques ou au minimum les répertoires utilisateurs avant toute opération lourde.
- Surveillez le tableau Windows Release Health afin de déployer le patch dès sa mise à disposition.
- Évitez la réinstallation en boucle : elle fait perdre temps et données sans résoudre la racine du problème.
- Contrôlez régulièrement le magasin de composants :
DISM /Online /Cleanup-Image /AnalyzeComponentStore - En entreprise, préparez un CMG ou un plan de restauration à partir de l’ISO Sept 2024 pour rétablir rapidement la conformité sécurité.
Plan d’action pour les administrateurs
Étape 1 : Qualifier le parc. Segmentez les machines par build d’origine ; limitez les tests aux postes 26100.1742.
Étape 2 : Déployer le script de diagnostic DISM. Un script MECM/Intune qui exporte DISM /Online /Cleanup-Image /ScanHealth vers un share réseau permet d’estimer la corruption réelle.
Étape 3 : Appliquer le correctif le plus doux. Démarrez par /StartComponentCleanup /ResetBase. Sur échec, passez au re‑provisionnement via ISO Sept 2024.
Étape 4 : Documenter les exceptions. Consignez les machines ayant besoin d’une clean install, afin de suivre la réapparition éventuelle du bug le mois suivant.
Questions fréquentes (FAQ)
Pourquoi l’erreur mentionne-t-elle parfois « Manifest from file: .NET_CORE » ?
Parce que KB5058411 remplace aussi des assemblies ASP.NET Core livrés initialement en version preview sur l’ISO d’octobre 2024. Si ces assemblies manquent, CBS les recherche sans succès, d’où l’erreur.
Un sfc /scannow suffit-il ?
SFC corrige les fichiers système présents, mais pas la base de composants. Il peut donc boucler indéfiniment sans trouver le package absent. Utilisez plutôt DISM comme décrit ci‑dessus.
Puis-je désinstaller la mise à jour problématique ?
Dans ce cas précis, la cumulative ne s’est jamais installée : il n’y a donc rien à désinstaller. Le seul moyen est d’empêcher Windows Update d’insister ou de corriger le magasin pour que l’installation aboutisse.
Conclusion et recommandations
Le blocage de KB5058411 sur Windows 11 24H2 est lié à un jeu spécifique de packages manquants dans la build 26100.1742. Les symptômes — arrêt à 53 %, erreurs 0x800f081f/0x800f0838 — pointent vers une corruption du magasin WinSxS que DISM ne parvient pas toujours à réparer.
En attendant le correctif officiel promis par Microsoft :
- Privilégiez d’abord le nettoyage DISM /ResetBase, peu intrusif et souvent efficace.
- Sur postes isolés, réparez BITS et installez .NET 9.0.5 manuellement.
- Dans les grands parcs, utilisez une task sequence ConfigMgr basée sur l’ISO Sept 2024 avec cycle d’activation/désactivation .NET 3.5.
- Ne réinstallez pas Windows à chaque Patch Tuesday : vous reviendriez à la case départ un mois plus tard.
Suivez ces recommandations pour sécuriser vos systèmes tout en limitant l’impact utilisateur jusqu’à la disponibilité d’un patch robuste.
—
Dernière mise à jour : 09 juillet 2025