Windows Update s’arrête net avec le code 0x8024402C et un message qui parle de problèmes de connexion. Derrière ce code, Microsoft décrit une seule chose : le nom du serveur proxy ou du serveur visé n’a pas pu être résolu.
Points clés
- Signification officielle : WU_E_PT_WINHTTP_NAME_NOT_RESOLVED, équivalent de ERROR_WINHTTP_NAME_NOT_RESOLVED.
- Le problème est réseau, pas système : rien n’est corrompu dans Windows dans le cas standard.
- L’agent Windows Update passe par WinHTTP, dont les réglages de proxy sont indépendants de ceux du navigateur.
- Microsoft classe 0x8024402C avec trois autres codes liés au proxy : 0x80244021, 0x8024401B et 0x80240030.
- En entreprise, le suspect numéro un est le serveur WSUS injoignable ou déclaré sous un nom que le poste ne sait pas résoudre.
Ce que le code veut dire exactement
L’outil de recherche d’erreurs de Microsoft traduit 0x8024402C par WU_E_PT_WINHTTP_NAME_NOT_RESOLVED, décrit comme identique à ERROR_WINHTTP_NAME_NOT_RESOLVED : le nom du serveur proxy ou du serveur cible ne peut pas être résolu (article Microsoft sur l’erreur 0x8024402C). Autrement dit, la machine a bien tenté de contacter quelque chose, et la résolution de nom a échoué.
Cela oriente le dépannage vers deux scénarios distincts. Sur un poste relié directement au service Windows Update, l’échec vient du réseau local ou de la connexion internet. Sur un poste géré par un service intranet comme WSUS, l’échec est local : la machine n’arrive pas à joindre le serveur de mises à jour. Confondre les deux fait perdre du temps, parce que les corrections n’ont rien à voir.
La famille des erreurs de proxy
Microsoft regroupe explicitement quatre codes causés par des problèmes de proxy : 0x80244021, 0x8024401B, 0x80240030 et 0x8024402C. Dans le journal Windows Update, ils apparaissent avec des libellés parlants, erreur HTTP 502 pour le premier, HTTP 407 pour le deuxième, format de liste de proxy invalide pour le troisième (échecs d’analyse des mises à jour logicielles). Le point commun : l’agent Windows Update utilise WinHTTP pour interroger les serveurs, et WinHTTP a sa propre configuration de proxy.
C’est le piège classique. Le navigateur charge des pages sans difficulté, donc l’utilisateur conclut que le réseau va bien. Mais Internet Explorer, Edge et Chrome utilisent les paramètres de proxy de la session utilisateur, alors que le service Windows Update tourne en arrière-plan avec la configuration WinHTTP de la machine. Les deux peuvent parfaitement diverger.
Solution 1 : vérifier la résolution de noms
Commencez par le plus simple, en invite de commandes :
ping 8.8.8.8
nslookup windowsupdate.microsoft.com
nslookup update.microsoft.comSi le ping vers une adresse IP passe mais que les résolutions de noms échouent, le DNS est en cause. Vérifiez que la carte réseau reçoit bien des serveurs DNS valides, videz le cache avec ipconfig /flushdns, et testez temporairement un résolveur public pour comparer. Un VPN mal déconnecté ou un pilote de filtrage laissé par un ancien antivirus produisent exactement ce symptôme.
En entreprise, remplacez les noms Microsoft par le nom complet de votre serveur WSUS. S’il ne se résout pas, la question devient une question de DNS interne, pas de Windows Update.
Solution 2 : inspecter et corriger le proxy WinHTTP
Regardez ce que WinHTTP a réellement en mémoire :
netsh winhttp show proxySi un proxy obsolète apparaît, deux options. Pour repartir d’un accès direct :
netsh winhttp reset proxyPour aligner WinHTTP sur les réglages de la session utilisateur, quand ces derniers sont corrects :
netsh winhttp import proxy source=ieCes commandes s’exécutent dans une invite ouverte en administrateur (référence de la commande netsh). Relancez la recherche de mises à jour après chaque changement, sans en empiler plusieurs.
Solution 3 : le cas WSUS et les stratégies de groupe
Sur un poste d’entreprise, ouvrez l’éditeur de registre et regardez la clé HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. Les valeurs WUServer et WUStatusServer indiquent le serveur imposé par stratégie. Si elles pointent vers un nom court, une machine ancienne, ou un serveur déplacé, l’erreur est expliquée.
Trois vérifications s’imposent alors : le nom complet du serveur doit se résoudre depuis le poste, le port déclaré doit correspondre à celui du site WSUS, et le proxy ne doit pas être appliqué aux adresses locales. Microsoft rappelle qu’on peut en général contourner le proxy pour les adresses de l’intranet, puisque le serveur WSUS se trouve à l’intérieur du réseau. Une machine sortie du périmètre, en télétravail par exemple, a besoin d’un chemin réseau vers ce serveur ou d’un basculement vers Windows Update.
Un cas particulier vaut d’être connu : pour obtenir un composant facultatif depuis WSUS, la machine doit exécuter Windows 11 version 22H2 ou une version ultérieure, ou Windows Server 2025 ou plus récent. Sur les autres versions, un composant facultatif s’installe depuis un référentiel réseau, un support local ou une image ISO montée.
Solution 4 : lancer l’utilitaire de résolution des problèmes
Sous Windows 11, ouvrez Paramètres, puis Système, puis Résoudre les problèmes, puis Autres utilitaires de résolution des problèmes, et lancez celui de Windows Update. Sous Windows 10, le chemin passe par Mise à jour et sécurité, puis Résolution des problèmes (guide Microsoft de résolution des problèmes de mise à jour).
Sur un 0x8024402C d’origine réseau, l’utilitaire ne corrige pas grand-chose, mais il remet les services dans un état propre et écarte une partie des hypothèses. Notre article sur Windows Update bloqué détaille cette remise à zéro des services quand la mise à jour reste figée après coup.
Solution 5 : lire le journal Windows Update
Depuis Windows 10, le journal n’est plus un fichier texte lisible directement : il est écrit au format ETL et doit être reconstitué. En PowerShell administrateur :
Get-WindowsUpdateLogLa commande produit un fichier WindowsUpdate.log sur le bureau (documentation des journaux Windows Update). Recherchez-y le code 0x8024402C et lisez les lignes qui précèdent : elles nomment l’adresse que l’agent tentait de joindre. C’est souvent la façon la plus rapide de découvrir qu’un poste interroge encore un serveur WSUS démantelé depuis des mois.
Solution 6 : écarter le filtrage réseau
Pare-feu d’entreprise, filtrage DNS, contrôle parental, suite de sécurité avec inspection HTTPS : tout composant qui s’interpose peut casser la résolution ou la connexion. Testez la machine sur un autre réseau, un partage de connexion mobile par exemple. Si la mise à jour aboutit ailleurs, le problème est bien sur le réseau d’origine, et la correction se fait côté équipement, pas côté Windows.
Désactiver temporairement une protection ne se fait que le temps du test, sur un réseau de confiance, et se réactive immédiatement après.
Quand le code n’est pas vraiment 0x8024402C
Deux codes voisins mènent ailleurs. Une expiration de délai pendant le téléchargement, avec le code 0x800705B4, indique que la connexion aboutit mais que l’opération dure trop longtemps : voir notre page sur l’erreur 0x800705b4. Un fichier introuvable dans le cache de mise à jour donne plutôt 0x80070002, traité dans notre article sur l’erreur 0x80070002. Enfin, pour la méthode générale applicable à n’importe quel code, notre guide de dépannage de Windows Update reprend les étapes communes.
FAQ
0x8024402C signifie-t-il que Windows est corrompu ?
Non. Le code désigne un échec de résolution de nom vers le serveur proxy ou le serveur de mises à jour. Les commandes de réparation d’image système ne traitent pas ce problème, sauf si un autre incident s’ajoute au premier.
Pourquoi mon navigateur fonctionne alors que Windows Update échoue ?
Parce que l’agent Windows Update utilise la configuration de proxy WinHTTP de la machine, distincte des paramètres de la session utilisateur employés par les navigateurs. Les deux configurations peuvent diverger sans que rien ne le signale.
Faut-il supprimer le dossier SoftwareDistribution ?
Pas en première intention sur ce code. Vider le cache de mise à jour est utile quand des fichiers téléchargés sont endommagés, ce qui n’est pas le cas ici puisque rien n’a pu être téléchargé.
Le code apparaît sur un seul poste du parc, que regarder en premier ?
La configuration réseau de ce poste : serveurs DNS reçus, proxy WinHTTP, valeurs WUServer imposées par stratégie. Un poste qui a voyagé entre deux sites ou revenu du télétravail garde souvent des réglages inadaptés.
Un VPN peut-il provoquer cette erreur ?
Oui, très fréquemment. Un tunnel actif, ou un tunnel mal fermé qui laisse des serveurs DNS injoignables sur la carte réseau, empêche la résolution des noms utilisés par Windows Update.
Sources
Photo d’en-tête : « Server Rack with Spaghetti-Like Mass of Network Cables » par Kim Scarborough, Wikimedia Commons, licence CC BY-SA 2.0. La photo illustre l’infrastructure réseau en cause dans ce code d’erreur, pas un écran de Windows Update.
Microsoft Learn, Erreur 0x8024402C lors de l’installation d’un composant facultatif.
Microsoft Learn, Résoudre les échecs d’analyse des mises à jour logicielles.
Microsoft Support, Résoudre les problèmes de mise à jour de Windows.
Microsoft Learn, Journaux Windows Update.
Microsoft Learn, Commande netsh.
Michel, dirigeant d’une PME informatique et formateur, expert en logiciels professionnels tels que CRM et ERP. Sa connaissance approfondie des outils de gestion d’entreprise lui permettant de conseiller et former efficacement d’autres sociétés à leur utilisation.
