> ## Documentation Index > Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt > Use this file to discover all available pages before exploring further. # Utilisation de la mémoire du noyau > Utilisation de la mémoire du noyau Dans Windows et dans le Microsoft Game Development Kit (GDK), la mémoire du noyau existe sous la forme d'un pool unique partagé par le noyau et tous les pilotes. La mémoire du noyau est toujours allouée à partir de la partition système. La majorité des besoins en mémoire du noyau relèvent de la responsabilité de la plateforme et, par conséquent, ils ne sont pas imputés au budget mémoire du titre. Toutefois, les éléments suivants illustrent les cas où le code du jeu est directement responsable de l'utilisation de la mémoire du noyau. * Structures de suivi pour chaque réservation de mémoire virtuelle * Gestion des fichiers, des événements et des objets de synchronisation de threads * Mise en réseau Les titres doivent fournir la mémoire nécessaire à l'utilisation du noyau dont ils sont directement responsables. Comme la mémoire du noyau existe sous la forme d'un pool unique, les allocations ne sont pas « fractionnables » de la même manière que l'utilisation de la plateforme et celle du titre sont réparties pour les binaires et les tas. Un mécanisme différent est donc utilisé pour permettre aux développeurs de fournir la mémoire nécessaire de manière déterministe. Le système d'exploitation alloue presque toute la mémoire du noyau qu'il consomme lors de la séquence de démarrage du système d'exploitation du Microsoft Game Development Kit (GDK). Une fois le démarrage terminé, les variations habituelles de l'utilisation par la plateforme sont d'environ 1 à 2 Mo. Lorsqu'un processus de titre est lancé, la consommation actuelle de mémoire du noyau est interrogée et un « seuil de bruit » est établi à 16 Mo au-dessus de la consommation actuelle de mémoire du noyau. Cette valeur est établie de sorte que, lorsque la limite est dépassée, cela résulte directement du comportement du titre plutôt que d'une variation normale du système d'exploitation. La surveillance est mise en œuvre en instrumentant les API suivantes, connues pour entraîner des allocations de mémoire du noyau. * `CreateFile` * `CreateEvent` * `CreateSemaphore` Si un appel à l'une de ces API se produit alors que l'utilisation de la mémoire du noyau approche du seuil ou l'a dépassé, des informations supplémentaires sont fournies via `XError` et le flux de débogage. Si l'utilisation de la mémoire du noyau a dépassé la limite, l'appel d'API échoue avec une valeur `GetLastError()` égale à `ERROR\_NOT\_ENOUGH\_MEMORY`. La sortie de diagnostic est visible dans un débogueur attaché, *xbwatson.exe* et *xbdbgmon.exe*. ### Avertissement (à 14 Mo) La sortie suivante s'affiche lorsqu'un avertissement se déclenche à 14 Mo. ```text theme={null} XERROR: HR:8007000E threadID:1096 WARNING: Title is consuming significant kernel pool memory. Use XMemGetWorkingSetStatistics to review usage and XMemTransferMemory to raise the quota. ``` ### Erreur (à 16 Mo) La sortie suivante s'affiche lorsqu'une erreur se déclenche à 16 Mo. ```text theme={null} \[XMEM\]: Initial Kernel Pool Usage: 19628032 \[XMEM\]: Current Kernel Pool Usage: 36683776 \[XMEM\]: Kernel Pool Limit: 36405248 Top Consumers: ``` Le tableau suivant présente le format des balises de pool (Pool Tag). | Tag | PagedAllocs | PagedFrees | PagedUsed | NonPagedAllocs | NonPagedFrees | NonPagedUsed | | - | - | - | - | - | - | - | | Even | 0 | 0 | 0 | 238750 | 219461 | 2469856 | | Thre | 0 | 0 | 0 | 385 | 130 | 620160 | | Mdl | 0 | 0 | 0 | 3843 | 3079 | 740080 | | MmRe | 318 | 159 | 693520 | 0 | 0 | 0 | | MmSt | 563 | 132 | 6133760 | 0 | 0 | 0 | | File | 185 | 2 | 1096096 | 0 | 0 | 0 | | TcDM | 0 | 0 | 0 | 1078 | 681 | 1587104 | | AfdB | 0 | 0 | 0 | 86 | 35 | 1623152 | | Mmww | 0 | 0 | 0 | 5503 | 705 | 530272 | | Xvnc | 0 | 0 | 0 | 13 | 6 | 1448784 | | XFSd | 0 | 0 | 0 | 1473 | 927 | 537040 | | Sema | 0 | 0 | 0 | 12766 | 150 | 1615552 | L'erreur suivante s'affiche également. ```text theme={null} XERROR: HR:8007000E threadID:1164 ERROR: Title has exhausted kernel pool quota. Common consumers include handles, thread sync. objects, and virtual address reservations. Use XMemTransferMemory to raise the quota. ``` Toutes les allocations de mémoire du noyau sont associées à une balise (de manière similaire au balisage avec `XMEM\_MAKE\_TAG` et `XMemVirtualAlloc`) pour indiquer l'utilisation de la mémoire. La balise peut aider à déterminer la source de l'utilisation de la mémoire. Le tableau suivant présente les balises de « forte utilisation » les plus courantes liées à l'utilisation par le titre. | Balise | Objectif | | - | - | | `Even` | Objets événement alloués avec `CreateEvent`. | | `File` | Handles de fichiers alloués par `CreateFile`. | | `Sema` | Objets sémaphore alloués par `CreateSemaphore`. | | `Mmww` | Bitmaps « Write Watch » alloués pour tout `MEM\_RESERVE` de mémoire graphique afin de prendre en charge les captures GPU de Performance Investigator for XBOX (PIX). | | `MmSt`, `Mdl` | Structures de contrôle utilisées par le MM pour suivre les allocations de pages physiques (`XMemAllocatePhysicalPages`, `XMemMapPhysicalPages`) et tous les mappages de fichiers (`CreateFileMapping`, ainsi que tous les fichiers .dll ou .exe chargés. | | `XFSk`, `XFsm` | Mémoire utilisée par XRFS, le pilote de système de fichiers Win32 utilisé pour les déploiements de fichiers libres (Loose) et les scénarios d'exécution à partir du PC (Run-from-PC). | | `TcDM`, `AfdB` | Mémoire utilisée par le pilote réseau. | La mémoire du noyau est divisée en deux grandes catégories appelées « non paginée » et « paginée ». Dans le Microsoft Game Development Kit (GDK), il n'existe aucune différence fonctionnelle entre ces catégories, et elles peuvent être considérées comme synonymes. ## Coûts courants en mémoire du noyau Le tableau suivant présente les coûts attendus en mémoire du noyau de chaque action répertoriée. | Action | Coût | | - | - | | Ouverture d'un fichier | Environ 2 Ko par handle de fichier | | Événements et sémaphores | 128 octets par événement ou sémaphore (ou 12 Mo pour 100 000) | | Réservations d'adresses virtuelles | 80 octets chacune (ou 7,5 Mo pour 100 000) | | `XMemAllocatePhysicalPages` | 128 octets par page physique de 64 Ko | ## Augmentation de la limite L'utilisation de la mémoire des titres de petite taille peut tenir dans les limites existantes. Toutefois, les titres plus volumineux doivent recevoir de la mémoire pour prendre en charge leur utilisation de la mémoire du noyau. L'API [XMemTransferMemory](/fr/reference/system/xmem/functions/xmemtransfermemory) permet de fournir la mémoire nécessaire. ## Profilage de l'utilisation du pool du noyau PIX ne prend pas en charge la surveillance de l'utilisation du pool du noyau. Il est possible de surveiller la consommation à l'aide de xperf et de Windows Performance Analyzer (WPA). Suivez les étapes suivantes pour profiler la mémoire du noyau. 1. Entrez la commande `xbrun /x/title xperf -start -on PROC_THREAD+LOADER+POOL -stackwalk PoolAlloc+PoolFree -f d:\krnl.etl` 2. Exécutez le scénario du titre. 3. Entrez la commande `xbrun /x/title xperf -stop -d d:\krnl.merged.etl` 4. Entrez la commande `xbcp xd:\krnl.merged.etl %TEMP%\pool_usage.etl` 5. Ouvrez le fichier *pool\_usage.etl* dans WPA et effectuez l'analyse comme illustré dans la figure 1. **Figure 1. Analyse du pool de mémoire du noyau dans WPA.** Capture d'écran de l'analyse du pool de mémoire du noyau dans WPA ## Related topics - [Répertoire des rubriques NDA : liens actifs vers Microsoft Learn](/fr-CA/nda/nda-topic-directory.md) - [Notes de version de PlayFab Party](/fr/services/playfab/multiplayer/networking/release-notes.md) - [Accéder aux ressources et téléchargements du GDK](/fr/home/onboarding-access/access-resources.md) - [Accéder aux ressources et aux téléchargements du GDK](/fr-CA/home/onboarding-access/access-resources.md) - [Guide de programmation Direct3D 12](/fr-CA/build/gdk-and-engines/guides/directx-12-programming-guide.md)