Erreur 0x80246007 : téléchargement de la mise à jour interrompu

Neuf fois sur dix, le code 0x80246007 signifie simplement que le fichier de mise à jour n’a jamais fini d’arriver sur le disque : Windows croit disposer du paquet, le gestionnaire de téléchargement, lui, n’a rien livré. La documentation Microsoft associe ce code à WU_E_DM_NOTDOWNLOADED, « la mise à jour n’a pas été téléchargée », dans la famille des erreurs du gestionnaire de téléchargement.

Points clés

• Code officiel : 0x80246007 = WU_E_DM_NOTDOWNLOADED, classé par Microsoft dans les erreurs du gestionnaire de téléchargement.
• Le composant en cause est presque toujours BITS, le service de transfert intelligent en arrière-plan, ou le cache local de Windows Update.
• Les trois premières solutions ne modifient aucun fichier système et suffisent dans la majorité des cas.
• Le journal utile s’appelle WindowsUpdate.log et se reconstruit avec la cmdlet Get-WindowsUpdateLog depuis Windows 10.
• Installer le paquet à la main depuis le catalogue Microsoft contourne le problème sans le régler : à garder pour les mises à jour urgentes.

Ce que dit vraiment le code 0x80246007

Windows Update travaille en deux temps. L’agent de mise à jour détecte le paquet à installer, puis délègue le transfert à un gestionnaire de téléchargement qui s’appuie sur BITS. Ce service télécharge en arrière-plan, à débit variable, et reprend là où il s’est arrêté après une coupure.

Le préfixe 0x8024 désigne les erreurs propres à Windows Update. Dans la table officielle, les codes 0x80246001 à 0x8024600x concernent tous le gestionnaire de téléchargement : URL absente, empreinte de fichier incorrecte, version de BITS incompatible, connexion impossible à BITS. Le 0x80246007 est le constat final de cette série : l’installation a été lancée alors que le contenu n’était pas là.

Conséquence pratique : chercher la panne du côté de l’installation ou des pilotes est une perte de temps. Le problème se situe entre le service de transfert, le dossier de cache et le disque.

Les causes fréquentes, par ordre de probabilité

• BITS arrêté, désactivé ou bloqué par une stratégie, un antivirus tiers ou un pare-feu d’entreprise.
• Cache de téléchargement corrompu dans C:\Windows\SoftwareDistribution\Download, souvent après un arrêt brutal.
• Espace disque insuffisant sur le volume système pendant le transfert, en particulier sur les tablettes à 64 Go.
• Connexion instable, VPN qui coupe, réseau limité qui suspend les transferts en arrière-plan.
• Serveur WSUS ou stratégie de groupe qui pointe vers une source interne indisponible, sur un poste géré.
• Composant système endommagé, cas minoritaire, qui se confirme avec DISM et SFC.

1. Relancer proprement le téléchargement

Redémarrez le poste, ouvrez Paramètres puis Windows Update et relancez la recherche. Un redémarrage remet BITS dans un état propre et purge les files de transfert en mémoire. Si le réseau utilisé est déclaré comme connexion limitée, désactivez ce réglage le temps du téléchargement : Windows suspend les transferts en arrière-plan sur ce type de réseau.

Vérifiez aussi la place disponible sur le volume système avant d’insister. Une mise à jour cumulative demande plusieurs gigaoctets de marge pour se décompresser, en plus de la taille du paquet.

2. Vérifier l’état des services de mise à jour

Ouvrez une invite de commandes en administrateur et interrogez les trois services concernés :

sc query bits
sc query wuauserv
sc query cryptsvc

Un service arrêté se relance avec net start bits. Un service dont le type de démarrage est passé à Désactivé se corrige dans la console Services, où BITS doit être en Manuel et le service Windows Update en Manuel ou Automatique selon la configuration. Sur un poste d’entreprise, une stratégie peut forcer ces valeurs : le service informatique doit alors intervenir en amont.

Un antivirus tiers qui inspecte le trafic chiffré interfère parfois avec les transferts BITS. Une désactivation temporaire de son module web, le temps du téléchargement, permet de trancher.

3. Vider la file d’attente de BITS

Les travaux de transfert de BITS survivent aux redémarrages, y compris quand ils sont dans un état incohérent. La liste se lit en administrateur avec bitsadmin /list /allusers /verbose. Les travaux orphelins de Windows Update se suppriment avec bitsadmin /reset /allusers, puis on relance la recherche de mises à jour.

Cette opération ne touche pas aux fichiers système. Elle annule en revanche les transferts en cours d’autres applications qui utilisent BITS, comme certains clients de déploiement logiciel.

4. Réinitialiser le cache de Windows Update

C’est la solution qui règle la majorité des cas résistants. Le principe : arrêter les services, renommer les dossiers de cache pour que Windows les recrée vides, redémarrer les services.

net stop wuauserv
net stop bits
net stop cryptsvc
ren %systemroot%\SoftwareDistribution SoftwareDistribution.old
ren %systemroot%\System32\catroot2 catroot2.old
net start cryptsvc
net start bits
net start wuauserv

La première recherche de mises à jour après cette opération est plus longue, l’historique des mises à jour est réinitialisé et les paquets doivent être retéléchargés en entier. Rien n’est perdu côté données ni côté mises à jour déjà installées. La procédure détaillée, avec les précautions, est décrite dans notre article dédié à la réinitialisation des composants Windows Update.

5. Réparer l’image système avec DISM puis SFC

Si le cache reconstruit ne change rien, le magasin de composants est peut-être en cause. Les deux commandes s’exécutent dans cet ordre, dans une invite en administrateur :

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

DISM répare le magasin de composants en récupérant les fichiers manquants depuis Windows Update, puis SFC vérifie les fichiers protégés du système en s’appuyant sur ce magasin réparé. L’inverse ne fonctionne pas : SFC seul échoue quand la source de réparation est elle-même abîmée. Comptez dix à trente minutes selon le disque, sans interrompre le processus.

Cas particulier : quand le poste ne peut plus rien télécharger du tout, DISM accepte une source locale montée depuis une image ISO officielle de la même version de Windows, via le paramètre /Source.

6. Installer la mise à jour depuis le catalogue Microsoft

Dernier recours avant les opérations lourdes, et solution la plus rapide quand la mise à jour est un correctif de sécurité attendu. Relevez le numéro KB affiché dans l’historique des mises à jour, cherchez-le sur le catalogue Microsoft Update, téléchargez le paquet .msu qui correspond exactement à votre version de Windows et à votre architecture, puis exécutez-le.

Cette méthode contourne le gestionnaire de téléchargement : elle installe le correctif mais laisse le mécanisme cassé. À utiliser en attendant de traiter la cause, pas comme réponse définitive. Vérifiez toujours l’édition et la build ciblées par le paquet : un .msu destiné à une autre version refuse simplement de s’installer.

Quand le code ne vient pas de là

Trois signaux orientent vers un autre diagnostic. Un poste en entreprise qui échoue sur toutes les mises à jour avec le même code pointe vers une source WSUS injoignable, pas vers le disque. Une erreur qui change de code à chaque tentative, 0x80070002 puis 0x80246007 puis autre chose, ressemble davantage à un problème de stockage ou de système de fichiers : un chkdsk sur le volume système est justifié.

Enfin, un échec systématique juste après le redémarrage, en phase d’installation et non de téléchargement, sort du périmètre du 0x80246007 et rejoint plutôt la famille des erreurs d’installation, comme l’erreur 0x80073701 ou l’erreur 0x8007001f. Pour tout ce qui se termine en écran bleu après une mise à jour, le guide des écrans bleus par code d’arrêt reste le point d’entrée.

Poste géré en entreprise : proxy, WSUS et stratégies

Sur un poste d’entreprise, la cause se trouve rarement sur la machine. Le service de mise à jour peut être dirigé vers un serveur WSUS interne par stratégie de groupe, et une simple erreur de nom de server ou un partage indisponible produit exactement ce code. La clé WindowsUpdate du registre, sous HKLM\SOFTWARE\Policies\Microsoft\Windows, indique la source réellement utilisée.

Deuxième piste : le proxy. BITS n’utilise pas systématiquement les paramètres du navigateur. Un proxy d’entreprise déclaré uniquement au niveau de l’utilisateur laisse le service sans accès internet, et la commande netsh winhttp show proxy montre en une étape la configuration vue par les services système. Les domaines de distribution de Microsoft doivent être joignables sans inspection cassant les connexions chiffrées.

Vérifier le disque avant d’insister

Un secteur défectueux sur le volume système se traduit souvent par un téléchargement qui n’aboutit jamais, avec des codes qui changent d’une tentative à l’autre. L’analyse se lance en administrateur avec chkdsk C: /scan, qui travaille en ligne sans démonter le volume et n’écrit rien. Un résultat propre écarte la piste matérielle en quelques minutes.

Ce que les logiciels de réparation tiers changent, et ne changent pas

La recherche de ce code d’erreur renvoie surtout vers des logiciels de nettoyage et de réparation qui promettent une analyse en un clic. Leur travail réel se limite le plus souvent à ce que les commandes ci-dessus font gratuitement : relancer les services, vider le cache de téléchargement, exécuter DISM. Aucune application tierce ne répare le magasin de composants mieux que l’outil intégré au système d’exploitation, puisque la source de réparation reste Windows Update.

Le vrai risque vient des utilitaires qui nettoient le registre : supprimer des entrées liées aux services de mise à jour dégrade la stabilité du poste sans corriger le téléchargement. Les informations utiles sont déjà accessibles sans rien installer, à savoir l’état des services, l’espace libre du disque et les journaux du système.

Lire le journal pour confirmer

Depuis Windows 10, Windows Update écrit ses traces dans des fichiers ETL, illisibles directement. La cmdlet Get-WindowsUpdateLog, exécutée dans PowerShell en administrateur, les reconstitue en un WindowsUpdate.log lisible sur le Bureau. Recherchez-y les lignes contenant DownloadManager et le code d’erreur : elles indiquent quel paquet a échoué et à quelle étape.

Le fichier C:\Windows\Logs\CBS\CBS.log complète le tableau côté magasin de composants, notamment après un passage de DISM ou de SFC.

Questions fréquentes

Faut-il désinstaller les mises à jour déjà installées ?

Non. Le 0x80246007 concerne un paquet qui n’a pas été téléchargé, donc jamais appliqué. Désinstaller des mises à jour saines ajoute du risque sans rien corriger.

Le dossier SoftwareDistribution.old peut-il être supprimé ?

Oui, une fois que Windows Update fonctionne de nouveau et qu’un cycle complet de recherche et d’installation a réussi. Ce dossier ne contient que du cache : sa suppression libère souvent plusieurs gigaoctets.

Combien d’espace disque prévoir pour une mise à jour ?

Aucun chiffre unique ne s’applique : la marge dépend de la mise à jour et de l’édition installée. Les configurations à faible stockage acceptent un support externe pour héberger les fichiers temporaires d’une mise à niveau, et Windows le propose de lui-même quand la place manque.

Un VPN peut-il provoquer ce code ?

Oui, indirectement. Une session VPN qui se coupe pendant un transfert BITS interrompt le téléchargement, et une inspection de trafic côté entreprise peut bloquer les domaines de distribution de Microsoft. Tester une fois hors VPN est un diagnostic rapide.

_{Photo d’en-tête : écran de progression d’une mise à jour Windows 10 22H2, capture par CSR2Forever, domaine public, via Wikimedia Commons. Elle illustre la phase d’installation, pas le téléchargement lui-même.
Sources : Référence des codes d’erreur Windows Update, Microsoft Learn · Résolution des problèmes de Windows Update, Microsoft Learn · Documentation BITS, Microsoft Learn · Journaux de Windows Update, Microsoft Learn · Options DISM de maintenance des paquets, Microsoft Learn · Catalogue Microsoft Update}