Corriger PAGE_FAULT_IN_NONPAGED_AREA Windows 11

Le système avait besoin de données depuis un bloc de mémoire censé toujours être résident — le pool non paginé, ce que Windows ne bascule jamais sur le disque parce qu’il a besoin d’un accès instantané — et les données n’y étaient pas. Soit la cellule de RAM qui les contenait est devenue défectueuse, soit un pilote a écrit n’importe quoi par-dessus, soit le fichier d’échange sur le disque est corrompu. Code d’arrêt 0x00000050. L’écran bleu nomme parfois un fichier .sys, parfois il dit juste ntoskrnl.exe qui n’est pas utile en soi.

Vérifiez d’abord l’Observateur d’événements. Win+X, Observateur d’événements, Journaux Windows, Système. Cherchez l’entrée BugCheck — le deuxième paramètre vous dit l’adresse mémoire qui a fauté, le quatrième vous dit si c’était une opération de lecture (0) ou d’écriture (1). Un défaut d’écriture pointe généralement vers un pilote qui corrompt activement la mémoire. Un défaut de lecture pourrait être une RAM défaillante, un mauvais fichier d’échange, ou un pilote essayant de lire de la mémoire qu’il a déjà libérée.

Quand il nomme un pilote

Si l’écran bleu ou l’Observateur d’événements montre un fichier .sys précis, c’est votre point de départ. Ceux que je vois le plus souvent avec ce code d’arrêt précis : win32kfull.sys (sous-système d’affichage, généralement un pilote GPU obsolète), ntfs.sys (pilote du système de fichiers — signifie généralement un disque défaillant plutôt qu’un bug de pilote), et ndis.sys ou divers fichiers .sys d’adaptateur réseau.

Le Surface Pro 9 d’une cliente plantait toutes les deux heures avec PAGE_FAULT nommant win32kfull.sys. Elle était sur le pilote Intel Iris Xe de novembre 2025 que Windows Update avait poussé. Restauré à la version d’octobre via le Gestionnaire de périphériques et ça s’est arrêté. Microsoft a poussé ce même mauvais pilote vers des milliers d’appareils Surface avant de le retirer trois semaines plus tard.

Pour tout plantage spécifique à un pilote, la séquence est la même : Mode sans échec, restaurez ou désinstallez le pilote, redémarrez, installez une version connue comme bonne depuis le site du fabricant. Si c’est le pilote GPU, l’installation propre DDU est la bonne méthode — mettre à jour par-dessus une installation de pilote corrompue ne règle pas toujours le problème.

Quand il ne nomme rien

Aucun fichier .sys, ou juste ntoskrnl.exe — soupçonnez la RAM ou le fichier d’échange. Si votre écran bleu dit MEMORY_MANAGEMENT au lieu de PAGE_FAULT, même diagnostic — code d’arrêt différent, causes qui se chevauchent.

Le fichier d’échange est le facile à écarter. C’est le fichier que Windows utilise comme débordement quand la RAM physique se remplit. S’il est sur un secteur mourant du disque, toute tentative d’y basculer des données heurte une erreur de lecture et vous obtenez PAGE_FAULT. Ouvrez les Propriétés système (Win+R, sysdm.cpl), onglet Avancé, Paramètres de performance, onglet Avancé, Modifier la mémoire virtuelle. Décochez « Gérer automatiquement », mettez sur Géré par le système pour votre disque C: précisément, cliquez Définir, redémarrez. Ça force Windows à reconstruire le fichier d’échange à partir de zéro. Si le plantage venait d’un fichier d’échange corrompu, ça le corrige.

Si ça n’aide pas, ou si les plantages arrivent alors que vous n’êtes même pas proche d’utiliser toute votre RAM, soupçonnez la mémoire physique. Même histoire que tout autre écran bleu lié à la mémoire — MemTest86 depuis un démarrage USB, toute la nuit, minimum quatre passages. Le Diagnostic de mémoire Windows attrape peut-être 30% de ce que MemTest86 trouve. J’ai eu une machine qui ne plantait que quand la température ambiante était élevée — les après-midis d’été précisément. Une barrette de RAM avait une cellule marginale qui marchait bien au frais mais échouait quand l’intérieur du boîtier se réchauffait. MemTest86 ne l’a pas attrapée avant que je le lance avec le panneau latéral du boîtier en place et la pièce à 28°C. Bizarre, mais les défauts de mémoire n’apparaissent pas toujours dans des conditions de test idéales.

Si MemTest86 revient propre et que la reconstruction du fichier d’échange n’a pas aidé, lancez sfc /scannow et DISM /Online /Cleanup-Image /RestoreHealth depuis une invite de commandes admin. Des fichiers système corrompus dans la zone du pool non paginé causent le même schéma de plantage. Notre guide SFC couvre quoi faire quand ces commandes trouvent mais ne peuvent pas corriger les problèmes.

Ce code d’arrêt est l’un des plus durs à cerner parce qu’il se situe à l’intersection de la RAM, du stockage et des pilotes. Si vous le chassez depuis plus de deux heures, envoyez-nous vos fichiers de dump de plantage — ils sont dans C:\Windows\Minidump et contiennent l’adresse fautive exacte et la pile d’appels qui pointe la cause.