Connexion Premium

Dans Windows 11, un fichier peut consommer jusqu’à 500 Go, mais le cas est rare

Au cours de l’année écoulée, quelques utilisateurs ont remarqué que Windows 11 pouvait se mettre à consommer plusieurs centaines de gigaoctets, a priori sans raison valable, comme relevé par Windows Latest.

En creusant un peu, le problème se concentre sur un seul fichier : CapabilityAccessManager.db-wal. Ce comportement n’a guère de sens, car ce fichier sert uniquement à stocker des informations liées aux autorisations données aux applications pour accéder à des fonctions du système comme la géolocalisation, la capture d’écran, le microphone, la caméra et ainsi de suite. Il n’est pas censé dépasser quelques mégaoctets.

Quand ce fichier se met à atteindre des dizaines, voire des centaines de gigaoctets, c’est qu’un sérieux bug est à l’œuvre. Selon les témoignages, l’espace consommé peut atteindre jusqu’à 500 Go, posant alors un vrai problème.

Le bug est assez simple à repérer. On commence par se rendre dans les Paramètres, puis dans Système > Stockage. Là, on clique sur « Afficher plus de catégories » (texte en bleu) et on repère la ligne « Système et espace réservé », qui devrait être en première ou deuxième position, selon le nombre d’applications installées.

Cet espace réservé comprend les fichiers système à proprement parler (en général une vingtaine de Go), la mémoire virtuelle ou encore le fichier nécessaire à la mise en veille prolongée. La taille varie donc en fonction de votre quantité de mémoire vive et de vos paramètres. Si vous avez cependant quelques centaines de gigaoctets, il y a peut-être un problème.

Avec un outil comme WizTree, TreeSize ou WinDirStat, on peut facilement repérer le souci, notamment la taille précise du fichier incriminé quand son comportement déraille. On peut aussi exécuter une commande dans l’Invite de Windows avec des droits administrateurs pour obtenir ces informations :

robocopy "C:\ProgramData\Microsoft\Windows\CapabilityAccessManager" "%TEMP%\CAMCheck" /L /B /R:0 /W:0 /BYTES /NP
Ici tout va bien

Microsoft est au courant de ce problème. Dans les notes de la mise à jour optionnelle KB5095093, on peut lire dans la partie « Change log » qu’un ajout a été fait le 29 juin pour régler le souci sur le fichier. Cette mise à jour optionnelle sera intégrée dans le prochain correctif mensuel (Patch Tuesday), prévu pour le 14 juillet.

Commentaires (22)

votre avatar
Dans le panneau de conf, je vois 128Go pour "Système et espace réservé".
Mais le fichier en question est a 0.



Nouveau rép. 6 C:ProgramDataMicrosoftWindowsCapabilityAccessManager
Nouveau fichier 1048576 CapabilityAccessManager.db
Nouveau fichier 32768 CapabilityAccessManager.db-shm
Nouveau fichier 0 CapabilityAccessManager.db-wal
Nouveau fichier 77824 CapabilityConsentStorage.db
Nouveau fichier 32768 CapabilityConsentStorage.db-shm
Nouveau fichier 115392 CapabilityConsentStorage.db-wal



Y'a ptet des choses à revoir dans l'article.
votre avatar
Le problème vient surtout de là je pense :
Si vous avez beaucoup plus qu’une cinquantaine de gigaoctets, il y a sans doute un problème. Cet espace réservé comprend les fichiers système à proprement parler (une vingtaine de Go), la mémoire virtuelle ou encore le fichier nécessaire à la mise en veille prolongée.
Un PC avec 8Go de RAM n'aurait pas du tout le même espace qu'un PC ayant 64 Go. Je suis à 208, mais c'est normal (64Go de RAM).

Il faut afficher le détail. Je suis quand même à 147 Go de fichiers systèmes, sans pour autant être affecté par le bogue.
votre avatar
Oui vous avez raison, j'ai légèrement modifié l'article pour évoquer le cas de la RAM, mais ça peut surtout être très différent d'une configuration à une autre, entre la RAM, la présence ou non de la veille prolongée, les options actives ou non, etc.

Merci en tout cas :)
votre avatar
Perso, je n'aime pas du tout la manière de calculer l'espace de mémoire virtuelle pour Windows. En gros, la mémoire virtuelle = la taille totale de la RAM.

Je peux comprendre qu'un PC avec 8 Gio puisse avoir besoin d'un espace complémentaire mais je suis contre le fait que cela soit imposé dès lors que la RAM est assez grande.

J'aimerai pouvoir mettre cette mémoire à 0 et que windows se débrouille avec la RAM disponible. C'est son rôle après tout.
votre avatar
sysdm.cpl → onglet "Paramètres système avancés" → dans la catégorie "Performances", cliquer le bouton "Paramètres…" pour ouvrir une nouvelle boîte de dialogue, intitulée "Options de performance"

Sur celle-ci, onglet "Avancé", bouton "Modifier…", pour ouvrir encore une boîte de dialogue, intitulée "Mémoire virtuelle".

Sur celle-là, décocher "Gestion automatique du fichier d'échange pour tous les lecteurs" en haut, puis pour chaque lecteur affiché dans la liste en dessous, activer le bouton radio "Aucun fichier d'échange", et cliquer "Définir".

Le fichier devrait être supprimé à partir du redémarrage suivant.
votre avatar
Merci pour le tuto. Je connaît très bien cette boîte de dialogue et c'est exactement ce que j'ai tenté de faire depuis des années en commençant par windows 7 mais cela se traduisait systématiquement par la recréation d'un swap par windows.

Je viens de ré-essayer sur 25H2 en VM et pour le moment, ça tient. A voir si cela tient à l'usage.
votre avatar
Bientôt Windows 11 sortira du stade de version alpha et sera utilisable sans se livrer à une surveillance constante.
votre avatar
Perso j'attends encore 3 ans pour penser à une migration de mon PC principal (celui du boulot, pas le choix). Bon espoir que ça soit finalisé d'ici là.

Win10, il démarre en 35secs et presque jamais un BSOD. Et ma barre des tâches est toujours sur le côté gauche !

/s
votre avatar
15 secondes pour ma part le Windows 10. Sur ma config du moins.

Sur une autre config (portable), Linux Mint démarre en 5-6 secondes.
votre avatar
:chinois: je compte depuis le BIOS, et je préfère qu'il charge et vérifie tous les périphériques. Sans doute pas loin de toi pour le chargement de Win10 ;-)
votre avatar
Debian avec Mate, boot en moins de 3 secondes.
C'est vrai, pas pour troller. Le windows manager est dispo et le proc est au repos.
votre avatar
46510712 CapabilityAccessManager.db-wal

C'est en octet par défaut ?
Dans ce cas, tout va bien.
votre avatar
Ce bug est tellement "windowsien"... :roll::mdr2:
votre avatar
Du point de vue d'un Linuxien, tout ça est fascinant. Et dire que j'ai encore le PC des enfants avec un SSD de 32Go où ça passe à l'aise. Visiblement, sous Windows ce serait plus tendu.
votre avatar
C'était très tendu avec Windows 10. Il te restait au mieux 10 Go... Jusqu'à ce qu'un jour Microslop décide que 7 Go doivent être affectés à Windows Update. Les ordinateurs HP Stream par exemple avec eMMC de 32 Go étaient quasiment inutilisables.

Windows 11 ? Jamais testé mais je n'essaierai pas même avec 64 Go.
votre avatar
Même que 32Go même avec une distribution linux classique, c'est tendu. Il y a juste de quoi installer le système et quelques logiciels.
votre avatar
J'ai justement un SSD de 32 Go avec LinuxMint (/home séparé sur un 2e disque) : la partition / occupe moins de la moitié du disque.
votre avatar
Sur la machine en question, le disque est rempli à hauteur de 27Go.

Mais je ne suis pas d'accord avec toi : un système de base (Debian, chez moi), ça tient dans 4Go (si tu es économe) à 8Go (si tu es gourmand).
votre avatar
Pour une installation minimal surement, mais c'est pas vraiment le cas d'utilisation type d'un pc desktop.
Si je prend mon système (Fedora 44 avec KDE Plasma), bah 32go c'est trop limité.
votre avatar
Pour moi un desktop c'est openbox :D
votre avatar
Petite question au passage : pourquoi doit-on passer par une commande robocopy avec plein de paramètres juste pour voir ces fichiers ?
Ils ne sont pas visibles avec un "dir /a" sur le dossier en question, et je n'arrive même pas à entrer dedans avec 7-zip File Manager…