Je suis désolé, je sais que cela semble être une réponse désinvolte... mais la réponse à la question de votre titre est "parce qu'ils ne sont pas censés le faire".
Ou pour le dire plus poliment : La mémoire vive est largement utilisée en dehors des ensembles de travail privés des processus. Une partie se trouve dans les ensembles de travail partagés des processus, mais il est impossible d'avoir une idée fiable de l'utilisation réelle qui en est faite, en raison du partage ; en additionnant les chiffres des processus, vous obtiendrez un résultat beaucoup trop important.
Les autres éléments qui occupent la RAM, comme le pool non paginé, la partie résidente du pool paginé et les parties résidentes des autres utilisations de l'espace noyau, n'apparaissent pas du tout dans l'affichage des "processus" du Gestionnaire de tâches.
En ce qui concerne votre problème spécifique :
Sur l'écran du gestionnaire des tâches, voyez-vous la section "mémoire du noyau" ? Vous avez 6 Go de "mémoire non paginée" (c'est-à-dire un pool non paginé). Cela fait partie de la section "En cours d'utilisation" dans votre deuxième graphique. La mémoire non paginée n'est imputée à aucun processus, c'est pourquoi l'addition des chiffres par processus dans le gestionnaire de tâches ne permet pas d'approcher le total en cours d'utilisation. Il est fort probable qu'un pilote l'utilise. Cette quantité est tout à fait excessive ; elle devrait être bien inférieure à 1 Go. Quel que soit le pilote responsable de la partie excessive de l'utilisation du pool non paginé, il est incontestablement bogué.
RAMmap peut le confirmer (dans l'onglet "Use Counts", regardez le total pour "Nonpaged Pool") mais il ne peut pas vous aider à trouver le pilote qui en est la cause.
Voici comment le trouver : Procurez-vous une copie de l'outil Microsoft "poolmon". Il s'agit d'un outil en mode caractère (il n'y en a jamais eu) distribué avec le Windows Driver Kit. Pour Windows 7, le WDK est un téléchargement gratuit . Vous devez télécharger l'ensemble (il s'agit d'une ISO) et l'installer à partir de là, mais vous pouvez choisir de n'installer que les outils, si c'est tout ce que vous voulez.
Trouvez poolmon dans les répertoires du WDK - assurez-vous de choisir le bon, 32 ou 64 bits - et exécutez-le à partir d'une invite de commande administrateur. Vous obtiendrez un affichage comme celui-ci :
![enter image description here]()
Appuyez ensuite sur la touche "p" (non, je ne plaisante pas. Pas de menus ici !) jusqu'à ce que la colonne "Type" n'affiche que "Nonp". Appuyez ensuite sur la touche "b" (deux fois si nécessaire) pour trier l'affichage par ordre décroissant dans la colonne "Bytes" (ce qui a déjà été fait dans l'exemple ici).
Regardez ensuite la colonne "Tag" de la ligne supérieure. Dans le cas (manifestement artificiel) illustré ici, il s'agit de "Leak". (Ce système utilise un pilote qui a été délibérément bogué pour causer ce problème - il "fuit" le pool non paginé).
btw, les lignes surlignées sont celles qui ont changé depuis la dernière mise à jour de cet écran archaïque.
Recherchez maintenant c : \Windows\System32\Drivers pour un fichier .sys contenant cette chaîne. Dans ce cas, vous recherchez "Leak", comme ceci :
c:\windows\system32> findstr /s Leak *.sys
Recherchez ensuite sur le web des références à cette chaîne de caractères et/ou à ce nom de conducteur.
Il serait également utile de revenir ici et d'indiquer le nom complet, le nom du fabricant, etc. du fichier .sys.
(Je parie que l'étiquette que vous trouverez sera ECMC, que le pilote sera intmsd.sys et qu'il sera associé à un produit appelé ExpressCache ou IntelliMemory. Je désinstallerais ce produit. Il existe une mise à jour qui corrige le problème, mais même avec la version corrigée, je n'ai jamais vu les performances d'un système améliorées par ce produit ; il duplique essentiellement une fonctionnalité qui se trouve déjà dans Windows).
Si vous ne pouvez pas le trouver de cette manière, l'étape suivante consiste à utiliser le "Windows Performance Toolkit". Cherchez cette chaîne dans ce forum, avec les réponses de magicandre1981, pour obtenir un mode d'emploi. Ignorez les réponses qui mentionnent xperf - il s'agit d'une ancienne version de l'outil.
MISE À JOUR : Selon les commentaires, l'OP a fait ce qui précède et a constaté que bien que poolmon ait indiqué que la taille totale du pool non paginé était effectivement énorme, toutes les parties allouées étaient apparemment minuscules. Ma conjecture (également dans les commentaires) est que cela est dû à ce que j'appellerai un pool "gonflé" : Le pool a été alloué, puis libéré, mais pour une raison quelconque, la quantité de RAM allouée au pool n'a pas été réduite pour refléter la "libération". En suivant la procédure décrite dans cette réponse par magicandre peut identifier le coupable.
