L’erreur 0x800705aa est la traduction en hexadécimal du code Win32 1450, que Microsoft libelle « les ressources système sont insuffisantes pour effectuer le service demandé ». Neuf fois sur dix, ce n’est pas la mémoire vive installée qui manque, mais une ressource interne du noyau saturée par un pilote ou un processus qui ne relâche rien.
Points clés
- 0x800705aa correspond au code d’erreur système 1450 (0x5AA), ERROR_NO_SYSTEM_RESOURCES, documenté par Microsoft.
- La ressource épuisée est presque toujours un pool du noyau (paginé ou non paginé), un quota de handles ou l’espace du fichier d’échange, pas la barrette de RAM.
- Un redémarrage fait disparaître le message quelques heures : c’est la signature typique d’une fuite de ressources, pas d’un manque matériel.
- Les trois déclencheurs les plus fréquents sont un pilote réseau ou de stockage fautif, une sauvegarde qui ouvre des milliers de fichiers, et un fichier d’échange fixé trop bas.
- L’outil de diagnostic gratuit qui tranche le plus vite est PoolMon, qui classe la consommation du noyau par balise d’allocation.
Ce que signifie vraiment « ressources système insuffisantes »
La table officielle des codes d’erreur Windows range 1450 parmi les erreurs système générales, avec la description « les ressources système sont insuffisantes pour effectuer le service demandé ». Les codes voisins précisent le type de manque : 1451 vise explicitement le pool non paginé, 1452 le pool paginé.
Le mot « ressources » désigne ici les réserves internes du noyau Windows, pas la quantité de mémoire affichée dans le Gestionnaire des tâches. Un poste avec 32 Go de RAM libre à 70 % peut parfaitement renvoyer 0x800705aa, parce que le compteur qui a atteint sa limite est ailleurs : nombre de handles ouverts, entrées de table, mémoire noyau réservée par un pilote.
C’est ce qui différencie ce code de l’erreur 0x8007000e, qui signale un vrai manque de mémoire disponible pour l’opération demandée.
Où l’erreur apparaît le plus souvent.
Le message remonte dans des contextes qui semblent sans rapport, mais qui ont un point commun : ils demandent beaucoup de petites allocations au noyau en peu de temps.
- Copie ou déplacement d’un gros volume de fichiers, en particulier vers un partage réseau ou un disque externe.
- Sauvegarde planifiée, antivirus en analyse complète, indexation.
- Ouverture d’une machine virtuelle ou d’un logiciel de virtualisation.
- Installation d’une mise à jour cumulative volumineuse.
- Impression d’un document lourd ou d’une longue file d’attente.
Si le message ne survient que dans une seule application, le coupable est probablement cette application ou son pilote associé. S’il apparaît partout après quelques heures d’utilisation, la piste de la fuite noyau devient prioritaire.
Étape 1 : mesurer avant de modifier quoi que ce soit
Ouvrez le Gestionnaire des tâches, onglet Performance, puis regardez la mémoire noyau et le nombre de handles. Ajoutez la colonne « Handles » dans l’onglet Détails : un processus qui dépasse plusieurs dizaines de milliers de handles sans raison est un suspect direct.
Pour aller plus loin, deux outils Microsoft suffisent. Process Explorer, publié par Sysinternals, affiche en temps réel les handles et les objets ouverts par chaque processus. RAMMap, du même ensemble, détaille la répartition de la mémoire physique, y compris la part occupée par le pool paginé et le pool non paginé.
Le verdict le plus net vient de PoolMon, livré avec le kit de développement de pilotes Windows. Il regroupe les allocations du noyau par balise d’allocation, ce qui permet d’identifier le composant responsable : c’est exactement l’usage prévu par Microsoft pour détecter une fuite mémoire dans un pilote. La balise qui grossit sans jamais redescendre désigne le pilote à mettre à jour.
Étape 2 : traiter le fichier d’échange
Un fichier d’échange désactivé ou fixé à une taille trop faible provoque des refus d’allocation qui ressortent en 1450. Microsoft publie une méthode de dimensionnement pour les versions 64 bits de Windows, et rappelle que la gestion automatique reste le réglage recommandé pour un poste standard.
La remise en automatique se fait dans Paramètres système avancés, Performances, Paramètres, Avancé, Mémoire virtuelle. Cochez « Gestion automatique du fichier d’échange pour les lecteurs », validez, redémarrez. Sur un poste où un utilitaire d’optimisation a désactivé le fichier d’échange, ce seul geste règle souvent le problème.
Étape 3 : isoler le pilote fautif
Quand PoolMon désigne une balise sans que le nom du pilote soit évident, la démarche classique reste le démarrage en mode minimal, services tiers désactivés, puis la réactivation par moitiés jusqu’à voir revenir l’erreur.
Les familles de pilotes concernées reviennent souvent : cartes réseau, contrôleurs de stockage, filtres d’antivirus, outils de chiffrement, clients de sauvegarde. Sur un portable, le pilote réseau du constructeur est le premier à mettre à jour depuis le site du fabricant de la machine, pas depuis un agrégateur de pilotes.
Si la machine produit aussi des écrans bleus, la piste change de nature et rejoint le diagnostic décrit dans notre article sur l’écran bleu MEMORY_MANAGEMENT.
Étape 4 : Driver Verifier, à manier avec précaution
Microsoft fournit le Vérificateur de pilotes, qui soumet les pilotes à des contraintes serrées pour faire apparaître les défauts de gestion mémoire. L’outil est efficace, mais il provoque volontairement un arrêt du système dès qu’il détecte une faute.
Deux précautions avant de le lancer : créer un point de restauration, et savoir désactiver le vérificateur depuis le mode sans échec avec verifier /reset. Sans cette sortie de secours, un poste peut redémarrer en boucle sur écran bleu. Réservez cette étape aux cas où toutes les pistes plus simples ont échoué.
Étape 5 : vérifier le matériel, en dernier
Une barrette défaillante ne provoque pas directement l’erreur 1450, mais elle produit des symptômes voisins, plantages aléatoires compris. Un test mémoire complet lève le doute en une nuit : la méthode et les outils sont détaillés dans notre guide sur le test de la mémoire RAM sous Windows.
Sur un poste ancien limité à 4 Go de mémoire vive, l’ajout de RAM ne corrige pas une fuite noyau, mais il repousse le seuil où le système commence à refuser des allocations. C’est un pansement utile, pas un diagnostic.
Les journaux d’événements à consulter
L’Observateur d’événements de Windows garde la trace des refus d’allocation. Dans le journal Système, filtrez sur les sources liées au noyau et au stockage : un message répété à intervalle régulier indique un service ou un pilote qui redemande sans arrêt une ressource déjà épuisée.
Notez la date et l’heure de chaque occurrence, puis comparez avec les tâches planifiées du poste. Une sauvegarde nocturne, une analyse antivirus complète ou une synchronisation de fichiers volumineux tombent souvent pile sur les mêmes créneaux. Cette corrélation vaut n’importe quel outil de diagnostic.
Quelques commandes utiles. Ces commandes s’exécutent dans une invite ouverte en administrateur. Elles ne corrigent pas une fuite de pilote, mais elles écartent les causes secondaires avant d’aller plus loin :
sfc /scannow: contrôle l’intégrité des fichiers protégés du système et remplace les versions altérées.DISM /Online /Cleanup-Image /RestoreHealth: répare le magasin de composants utilisé par la commande précédente.chkdsk C: /f: vérifie le système de fichiers du volume, à planifier au redémarrage.tasklist /svc: liste les processus et les services qu’ils hébergent, pratique pour rattacher un identifiant de processus à un service précis.
Sur un poste où le message apparaît seulement à la connexion d’un périphérique USB ou d’un disque externe, le pilote du contrôleur concerné passe en tête de liste des suspects, avant toute autre manipulation.
Un point de vigilance sur le registre : plusieurs guides trouvés en ligne proposent de créer des valeurs dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control pour relever une limite du système. Ces modifications ne figurent dans aucune procédure Microsoft pour le code 1450 et peuvent rendre un poste instable. Tant que la mesure n’a pas désigné la ressource réellement saturée, l’éditeur du registre reste fermé.
Le suivi dans le temps compte autant que le diagnostic ponctuel. Notez la version de Windows installée, la version du pilote suspect et la date de chaque modification appliquée. Sur un parc, ce journal permet de voir si le problème suit une mise à jour précise ou un modèle de machine, et d’éviter de refaire trois fois la même manipulation sur trois postes différents.
Quand l’erreur touche un partage réseau
Le cas est fréquent en entreprise : la copie vers un serveur de fichiers échoue à mi-parcours avec 0x800705aa, alors que la même copie en local passe sans broncher. Le nombre de connexions et de fichiers ouverts simultanément sur le serveur entre alors en jeu, autant que les ressources du poste client.
Le contrôle se fait des deux côtés : compteurs mémoire du serveur, pilotes de la carte réseau sur le client, et découpage de la copie en lots plus petits pour vérifier que le volume est bien le facteur déclenchant.
Questions fréquentes
Ajouter de la RAM fait-il disparaître l’erreur 0x800705aa ?
Pas de manière fiable. Le code signale l’épuisement d’une ressource interne du noyau, qui possède ses propres limites indépendantes de la mémoire installée. L’ajout de RAM peut espacer les occurrences sans supprimer la cause.
Pourquoi l’erreur revient-elle toujours après quelques heures ?
Parce qu’un composant consomme sans relâcher. Le redémarrage remet les compteurs à zéro, la consommation repart, le seuil est atteint de nouveau. Ce rythme régulier est le meilleur indice d’une fuite de pool ou de handles.
Le code 1450 et le code 1451, est-ce la même chose ?
Ils partagent la même description dans la table officielle, mais 1451 nomme explicitement le pool non paginé, une zone de mémoire noyau qui ne peut jamais être déchargée sur le disque. 1450 reste générique.
Faut-il désactiver l’antivirus pour tester ?
Une désactivation temporaire du filtrage de fichiers est un test légitime, sur une machine déconnectée d’Internet et pour quelques minutes. La désinstallation complète n’a de sens que si le test confirme la responsabilité du produit.
L’erreur peut-elle venir d’une mise à jour Windows ?
Oui, indirectement, quand une mise à jour installe une nouvelle version d’un pilote système. La désinstallation de la mise à jour concernée sert alors de test de confirmation, avant de chercher une version corrigée du pilote chez le constructeur.
Sources
Photo d’en-tête : barrettes de mémoire installées sur une carte mère, par Mixabest, domaine public, via Wikimedia Commons. La photo illustre la mémoire physique, alors que l’erreur porte le plus souvent sur les ressources internes du noyau.
Microsoft Learn, codes d’erreur système 1300 à 1699
Microsoft Learn, PoolMon
Microsoft Sysinternals, RAMMap
Microsoft Sysinternals, Process Explorer
Microsoft Learn, dimensionner le fichier d’échange sous Windows 64 bits
Microsoft Learn, Vérificateur de pilotes
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.
