Au démarrage de Linux, le noyau doit pouvoir identifier et monter la partition racine / pour accéder aux fichiers nécessaires au fonctionnement du système. Lorsque cette étape échoue, le démarrage peut s’interrompre sur un Kernel Panic accompagné du message :

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(...)

Cette erreur peut apparaître après une mise à jour du noyau, une modification des partitions ou de GRUB, mais aussi à cause d’un initramfs endommagé, d’un UUID incorrect, d’un pilote de stockage manquant, d’un système de fichiers corrompu ou d’un SSD/disque défaillant.

Il n’est généralement pas nécessaire de réinstaller Linux. En identifiant à quelle étape l’accès à la partition racine échoue, il est souvent possible de réparer le démarrage depuis GRUB, le mode de récupération ou un Live USB Linux.

Dans ce guide, découvrez les causes de l’erreur « VFS: Unable to mount root fs » et les solutions pour démarrer sur un ancien noyau, vérifier la partition racine et son UUID, reconstruire l’initramfs, réparer le système de fichiers et retrouver un Linux fonctionnel.

Qu’est-ce que l’erreur « VFS: Unable to mount root fs » ?

L’erreur « VFS: Unable to mount root fs » est un Kernel Panic qui se produit pendant le démarrage de Linux lorsque le noyau ne parvient pas à accéder ou à monter le système de fichiers racine.

Le message se présente généralement sous une forme proche de :

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Le système de fichiers racine, représenté par /, contient les fichiers indispensables au fonctionnement de Linux. Si le noyau ne parvient pas à le monter, il ne peut pas poursuivre normalement la séquence de démarrage et déclenche alors un Kernel Panic.

Le problème peut apparaître très tôt au démarrage, parfois juste après une mise à jour du noyau, une modification des partitions ou une opération ayant affecté l’initramfs ou le stockage.

Que signifie VFS ?

VFS (Virtual File System) est la couche du noyau Linux qui fournit une interface commune aux différents systèmes de fichiers, tels que ext4, XFS ou Btrfs.

Lorsque le message indique :

VFS: Unable to mount root fs

cela signifie donc que le noyau n’a pas réussi à monter le système de fichiers devant devenir la racine /.

Cela ne signifie pas nécessairement que le système de fichiers lui-même est endommagé. Le noyau peut tout simplement ne pas parvenir à trouver le périphérique qui le contient ou ne pas disposer du pilote nécessaire pour y accéder.

Que signifie « unknown-block » ?

La fin du message fournit également un indice important :

unknown-block(0,0)

Les deux nombres correspondent à des identifiants utilisés par Linux pour représenter le périphérique de stockage.

Lorsque le message indique unknown-block(0,0), le noyau ne parvient généralement pas à identifier correctement le périphérique contenant la partition racine. Il faut alors rechercher en priorité un problème concernant l’initramfs, le paramètre root=, l’UUID de la partition ou le pilote du contrôleur de stockage.

Dans d’autres situations, vous pouvez rencontrer par exemple :

unknown-block(8,1)

Le noyau a alors identifié un périphérique bloc précis, ce qui peut davantage orienter les recherches vers la partition, le système de fichiers ou son accessibilité.

Le contenu exact de unknown-block(...) constitue donc un indice de diagnostic, mais ne permet pas à lui seul de déterminer la cause.

Quelles sont les causes de « Unable to mount root fs » ?

L’erreur « VFS: Unable to mount root fs » signifie que le noyau Linux n’arrive pas à monter la partition racine /. Plusieurs problèmes peuvent interrompre la chaîne de démarrage entre GRUB, le noyau, l’initramfs et le périphérique de stockage.

Le message unknown-block(...) ainsi que les erreurs affichées juste avant le Kernel Panic peuvent fournir de précieux indices.

Cause	Exemple	Indices possibles
Initramfs endommagé ou incomplet	Mise à jour interrompue, mauvaise génération de l’image	Erreur apparue après une mise à jour du noyau
Nouveau noyau défectueux ou incompatible	Régression du kernel, module incompatible	Ancien noyau fonctionnel depuis GRUB
Mauvaise partition racine	Paramètre root= incorrect	UUID ou périphérique différent de la partition réelle
UUID incorrect	Partition recréée, clonée ou modifiée	UUID de GRUB/fstab différent de celui retourné par blkid
Pilote de stockage absent	NVMe, SATA, RAID ou contrôleur non disponible dans l’initramfs	Souvent unknown-block(0,0)
Système de fichiers endommagé	Corruption ext4, XFS, Btrfs…	Erreurs de système de fichiers avant le panic
SSD ou disque défaillant	Erreurs de lecture ou contrôleur instable	I/O error, erreurs NVMe/SATA
Configuration GRUB incorrecte	Mauvaise entrée ou paramètres du noyau erronés	Mauvais root=, problème après modification de GRUB

Démarrer Linux avec un ancien noyau

Si l’erreur « VFS: Unable to mount root fs » est apparue juste après une mise à jour du noyau Linux, commencez par essayer de démarrer avec la version précédente du kernel.

Linux conserve généralement plusieurs noyaux installés. Il est donc possible de sélectionner un ancien kernel depuis GRUB sans désinstaller immédiatement la nouvelle version.

Sélectionner un ancien noyau depuis GRUB

Redémarrez le PC et affichez le menu GRUB. Selon la distribution et la configuration, vous devrez éventuellement maintenir la touche Maj (Shift) ou appuyer plusieurs fois sur Échap (Esc) pendant le démarrage.

Ensuite :

• Sélectionnez Options avancées pour Ubuntu, ou l’entrée équivalente de votre distribution.
• GRUB affiche les différentes versions du noyau disponibles.
• Sélectionnez une version antérieure du noyau, sans choisir le mode Recovery dans un premier temps.
• Démarrez Linux normalement.

Si le système démarre correctement, vérifiez le noyau actuellement utilisé avec :

uname -r

Vous pouvez également afficher les noyaux présents dans /boot :

ls -lh /boot

Si l’ancien noyau fonctionne

Si Linux démarre avec le kernel précédent mais affiche « Unable to mount root fs » avec la version la plus récente, cela constitue un indice important.

Le problème peut notamment concerner :

• L’initramfs associé au nouveau noyau.
• Un pilote ou module de stockage absent de cet initramfs.
• Un module DKMS qui n’a pas été correctement reconstruit.
• Une régression ou une incompatibilité avec le nouveau kernel.

Dans ce cas, évitez de supprimer immédiatement l’ancien noyau fonctionnel : il constitue une solution de secours pendant le diagnostic.

Vous pouvez ensuite tenter de reconstruire l’initramfs du noyau problématique et mettre à jour la configuration de GRUB.

Si aucun ancien noyau ne démarre

Si plusieurs versions du noyau provoquent la même erreur, la piste d’une simple régression du kernel devient moins probable.

Il faut alors vérifier en priorité la partition racine, son UUID, l’initramfs, le système de fichiers et le périphérique de stockage.

Si Linux ne démarre avec aucun noyau disponible, utilisez le mode de récupération ou un Live USB Linux afin d’accéder au système et d’effectuer les réparations.

Le démarrage avec un ancien noyau constitue donc surtout un test de diagnostic rapide : si l’ancien kernel fonctionne, concentrez les recherches sur ce qui a changé avec la nouvelle version plutôt que de modifier immédiatement les partitions ou le système de fichiers.

Démarrer en mode de récupération

Si Linux ne démarre toujours pas normalement, le mode de récupération (Recovery Mode) permet d’accéder à plusieurs outils de dépannage sans charger complètement le système.

Il est particulièrement utile avec l’erreur « VFS: Unable to mount root fs », car il peut permettre d’obtenir un shell administrateur et d’effectuer certaines réparations sur le système de fichiers, l’initramfs ou la configuration du démarrage.

Depuis GRUB, ouvrez généralement Options avancées, puis sélectionnez une entrée du noyau comportant la mention Recovery Mode.

Selon la distribution et la situation, vous pourrez notamment :

• Accéder à un shell root.
• Vérifier ou réparer le système de fichiers.
• Reconstruire l’initramfs.
• Corriger une mise à jour de paquets interrompue.
• Vérifier les partitions et leurs UUID.
• Mettre à jour la configuration de GRUB.
• Examiner les journaux et messages d’erreur.

Si plusieurs noyaux sont proposés, vous pouvez également essayer le mode de récupération d’un ancien kernel lorsque l’erreur est apparue après une mise à jour.

Pour accéder au mode Recovery et connaître les différents outils disponibles, suivez le guide correspondant à votre distribution :

Le guide complet :

Si le mode de récupération ne démarre pas non plus ou provoque le même Kernel Panic, utilisez plutôt un Live USB Linux. Celui-ci permettra d’accéder aux partitions depuis un système indépendant afin de vérifier le stockage, réparer le système de fichiers ou reconstruire l’initramfs.

Vérifier la partition racine et son UUID

L’erreur « VFS: Unable to mount root fs » peut apparaître lorsque le noyau Linux cherche la partition racine / au mauvais emplacement. Cela peut notamment se produire après un clonage de disque, une modification du partitionnement, une restauration ou un changement incorrect de la configuration de démarrage.

L’objectif est donc de vérifier que la partition existe toujours et que son UUID correspond à celui utilisé par Linux et GRUB.

Identifier la partition racine

Depuis le mode de récupération ou un Live USB Linux, affichez les partitions et leurs systèmes de fichiers :

lsblk -f

Vous pouvez compléter avec :

sudo blkid

Repérez la partition contenant votre installation Linux, par exemple :

/dev/nvme0n1p2

ou :

/dev/sda2

Notez son UUID, par exemple :

UUID="a1b2c3d4-e5f6-7890-abcd-123456789abc"

Plus de détails

Comparer l’UUID avec /etc/fstab

Depuis un Live USB, montez la partition racine, en adaptant le périphérique à votre configuration :

sudo mount /dev/nvme0n1p2 /mnt

Puis consultez :

cat /mnt/etc/fstab

Repérez la ligne correspondant à / :

UUID=a1b2c3d4-e5f6-7890-abcd-123456789abc  /  ext4  defaults  0  1

L’UUID doit correspondre à celui obtenu avec lsblk -f ou blkid.

Si les valeurs sont différentes, Linux peut essayer de monter une ancienne partition ou un système de fichiers dont l’identifiant a changé.

Ne modifiez toutefois pas /etc/fstab avant d’avoir identifié avec certitude la partition racine.

Vérifier le paramètre root= de GRUB

GRUB indique également au noyau où se trouve la partition racine grâce au paramètre root=.

Si Linux démarre avec un ancien noyau, affichez les paramètres utilisés :

cat /proc/cmdline

Vous pouvez notamment obtenir :

root=UUID=a1b2c3d4-e5f6-7890-abcd-123456789abc

Vérifiez là encore que cet UUID correspond à celui de la véritable partition racine.

Si Linux ne démarre plus, sélectionnez son entrée dans GRUB puis appuyez sur e. Recherchez la ligne commençant par linux et vérifiez la valeur :

root=UUID=...

Vous pouvez temporairement remplacer un UUID incorrect par le bon afin de tester le démarrage. Cette modification n’est valable que pour cette tentative et ne change pas définitivement la configuration de GRUB.

Si Linux démarre après cette correction, vous avez probablement identifié la cause du problème.

Corriger définitivement l’UUID

Une fois Linux démarré, corrigez si nécessaire l’UUID incorrect dans /etc/fstab ou la configuration concernée, puis régénérez GRUB.

Sur Ubuntu et Debian :

sudo update-grub

Si la partition racine, son UUID et le paramètre root= sont déjà corrects mais que le Kernel Panic affiche toujours unknown-block(0,0), le problème vient probablement d’une autre étape du démarrage.

Il faut alors vérifier en priorité l’initramfs et les pilotes nécessaires pour accéder au périphérique de stockage.

Reconstruire l’initramfs

L’initramfs est chargé très tôt pendant le démarrage de Linux. Il contient notamment les modules et outils nécessaires pour détecter le périphérique de stockage et accéder à la partition racine /.

S’il est endommagé, incomplet ou ne contient plus un pilote nécessaire, le noyau peut ne pas parvenir à monter la partition racine et afficher l’erreur « VFS: Unable to mount root fs ». Cette situation peut notamment survenir après une mise à jour du noyau ou d’un pilote.

Reconstruire l’initramfs sur Ubuntu et Debian

Si vous pouvez démarrer avec un ancien noyau ou depuis le mode de récupération, reconstruisez les images initramfs avec :

sudo update-initramfs -u -k all

Pour reconstruire uniquement celle du noyau actuellement utilisé :

sudo update-initramfs -u -k "$(uname -r)"

Mettez ensuite à jour GRUB :

sudo update-grub

Puis redémarrez le PC et essayez à nouveau le noyau qui provoquait l’erreur.

Reconstruire l’initramfs sur Fedora et RHEL

Fedora, RHEL et plusieurs distributions dérivées utilisent généralement dracut.

Pour reconstruire l’initramfs du noyau en cours :

sudo dracut --force

Si plusieurs noyaux sont installés, vérifiez leurs versions :

ls /lib/modules/

Lorsque vous devez réparer un noyau différent de celui actuellement démarré, veillez à reconstruire l’image correspondant à la bonne version du kernel.

Vérifier que l’initramfs existe

Vous pouvez contrôler les images présentes dans /boot :

ls -lh /boot

Selon la distribution, vous devez notamment retrouver des fichiers de type :

vmlinuz-...
initrd.img-...

ou :

initramfs-....img

Vérifiez qu’une image initramfs existe bien pour le noyau que vous essayez de démarrer. Un nouveau kernel accompagné d’un initramfs absent ou mal généré peut expliquer pourquoi l’ancien noyau fonctionne alors que le nouveau provoque le Kernel Panic.

Si Linux ne démarre plus du tout

Si aucun noyau ou mode de récupération ne permet de démarrer, utilisez un Live USB Linux. Vous pourrez monter l’installation existante, entrer dans le système avec chroot, puis reconstruire l’initramfs et mettre à jour GRUB.

Le guide complet :

Le principe est alors : Live USB → monter Linux → chroot → reconstruire l’initramfs → mettre à jour GRUB

Inutile de détailler ici toute la procédure chroot, puisqu’elle est déjà expliquée dans le guide dédié.

Si l’erreur persiste

Si l’initramfs a été correctement reconstruit mais que le noyau affiche toujours unknown-block(0,0), vérifiez ensuite que l’image contient bien les pilotes nécessaires au contrôleur de stockage.

Si le SSD ou le disque est détecté mais que la partition racine ne peut toujours pas être montée, recherchez plutôt un système de fichiers endommagé ou un problème avec le périphérique de stockage.

Vérifier et réparer le système de fichiers

Si le noyau détecte correctement la partition racine mais n’arrive pas à monter son système de fichiers, une corruption de celui-ci peut provoquer l’erreur « VFS: Unable to mount root fs ».

Ce problème peut notamment apparaître après un arrêt brutal du PC, une coupure de courant, un plantage pendant une écriture ou des erreurs provenant du SSD ou du disque dur.

Recherchez dans les messages précédant le Kernel Panic des indications comme :

EXT4-fs error
Buffer I/O error
I/O error
BTRFS error
XFS
Superblock

Vérifier le système de fichiers avec fsck

Sous Linux, la commande fsck permet de vérifier et, selon le système de fichiers, de réparer les erreurs détectées. fsck sert en réalité d’interface aux outils adaptés au type de système de fichiers concerné.

Commencez par identifier la partition et son système de fichiers :

lsblk -f

Par exemple, si la partition racine utilise ext4 et correspond à /dev/nvme0n1p2, vous pouvez effectuer sa vérification depuis un Live USB ou un environnement de récupération, une fois la partition démontée :

sudo fsck /dev/nvme0n1p2

Selon les erreurs rencontrées, l’outil peut proposer de réparer les incohérences détectées.

Pour connaître les différentes options et méthodes de réparation, consultez notre guide complet :

Le guide complet :

Enfin notez que vous pouvez effectuer un fsck depuis les options de récupération :

Attention au type de système de fichiers

Tous les systèmes de fichiers ne se réparent pas de la même manière. Pour XFS, par exemple, fsck.xfs ne réalise pas directement la réparation : l’outil dédié est xfs_repair.

Btrfs utilise également ses propres outils de vérification et de réparation ; fsck.btrfs n’effectue pas une vérification classique.

Il est donc important d’identifier le système de fichiers avec lsblk -f avant de lancer une réparation.

Si les erreurs réapparaissent après avoir réparé le système de fichiers, ne vous contentez pas de relancer régulièrement fsck. Des corruptions répétées peuvent être le symptôme d’un SSD ou disque défaillant, d’erreurs d’entrée/sortie ou d’une autre instabilité matérielle.

Dans ce cas, l’étape suivante consiste à vérifier l’état du périphérique de stockage.

Vérifier le SSD ou le disque dur

Si l’erreur « VFS: Unable to mount root fs » s’accompagne d’erreurs d’entrée/sortie ou si le système de fichiers se corrompt régulièrement, vérifiez également l’état du SSD ou du disque dur.

Un périphérique de stockage défaillant peut empêcher le noyau de lire correctement la partition racine. Dans ce cas, reconstruire l’initramfs ou réparer le système de fichiers peut ne résoudre le problème que temporairement.

Rechercher les erreurs de stockage

Depuis le mode de récupération ou un Live USB, consultez les messages du noyau :

dmesg -T | grep -Ei "error|fail|i/o|nvme|ata|sata"

Vous pouvez également utiliser :

journalctl -k | grep -Ei "error|fail|i/o|nvme|ata|sata"

Recherchez notamment des messages tels que :

I/O error
Buffer I/O error
critical medium error
nvme
ata error
reset
timeout

Des erreurs répétées de lecture, des timeouts ou des réinitialisations du contrôleur de stockage constituent des indices importants.

Le guide complet :

Identifier le disque concerné

Affichez les périphériques de stockage avec :

lsblk -o NAME,MODEL,SIZE,FSTYPE,MOUNTPOINTS

lsblk permet d’obtenir les informations sur les périphériques bloc détectés par Linux.

Repérez le SSD ou disque contenant la partition racine avant de poursuivre les vérifications.

Vérifier les données SMART

Les SSD et disques compatibles exposent généralement des informations S.M.A.R.T. permettant de surveiller leur état de santé, les erreurs enregistrées et différents indicateurs d’usure. Sous Linux, ces données peuvent notamment être interrogées avec smartctl, fourni par smartmontools.

Comme tu as déjà un guide complet consacré à cette vérification, je ne détaillerais pas ici toutes les commandes et attributs SMART :

Le tutoriel à suivre :

L’objectif est notamment de rechercher des erreurs matérielles, des secteurs problématiques, une usure anormale du SSD ou des erreurs enregistrées par le contrôleur.

Si le stockage présente des signes de défaillance, sauvegardez vos données importantes avant d’effectuer des réparations répétées du système de fichiers.

À l’inverse, si le disque est en bon état, que la partition est correctement détectée et que son système de fichiers ne présente pas d’erreur, revenez plutôt aux pistes liées à l’initramfs, aux pilotes de stockage ou à la configuration du démarrage.

Vérifier les pilotes de stockage dans l’initramfs

Pour monter la partition racine /, le noyau doit pouvoir détecter le SSD ou le disque dès les premières étapes du démarrage. Les pilotes nécessaires au contrôleur de stockage doivent donc être disponibles dans l’initramfs.

Si un module NVMe, SATA, RAID ou correspondant à un contrôleur particulier est absent, Linux peut ne pas détecter le périphérique contenant la partition racine et afficher notamment :

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Cette piste est particulièrement intéressante lorsque le problème apparaît après une mise à jour du noyau, une reconstruction de l’initramfs ou une modification de la configuration du stockage.

Identifier le pilote de stockage utilisé

Si vous pouvez démarrer avec un ancien noyau fonctionnel, identifiez le contrôleur de stockage et le pilote utilisé :

lspci -k | grep -A3 -Ei "sata|raid|storage|non-volatile|nvme"

Vous pouvez également rechercher les principaux modules de stockage chargés :

lsmod | grep -Ei "nvme|ahci|ata|scsi|raid"

Selon le matériel, vous pouvez par exemple rencontrer nvme, nvme_core, ahci ou libahci. Le module réellement nécessaire dépend toutefois du contrôleur présent sur le PC.

Vérifier que le module est présent dans l’initramfs

Sur Ubuntu et Debian, affichez d’abord les images disponibles :

ls -lh /boot/initrd.img-*

Puis recherchez le pilote dans l’initramfs correspondant au noyau qui ne démarre pas. Par exemple pour NVMe :

lsinitramfs /boot/initrd.img-<version-du-noyau> | grep -i nvme

ou pour AHCI :

lsinitramfs /boot/initrd.img-<version-du-noyau> | grep -i ahci

Sur une distribution utilisant dracut, utilisez plutôt lsinitrd :

lsinitrd /boot/initramfs-<version-du-noyau>.img | grep -Ei "nvme|ahci"

Si l’ancien noyau démarre correctement, comparer son initramfs avec celui du nouveau kernel peut aider à repérer un module absent dans l’image problématique.

Que faire si le pilote est absent ?

Si vous avez identifié avec certitude un module indispensable absent de l’initramfs, commencez par reconstruire l’image comme expliqué dans la section précédente.

Sur Ubuntu/Debian :

sudo update-initramfs -u -k all
sudo update-grub

Si le module reste absent, il est possible de forcer son inclusion dans l’initramfs. Cette opération dépend toutefois de la distribution et ne doit être effectuée qu’après avoir identifié précisément le pilote nécessaire.

Cas des volumes RAID, LVM ou chiffrés

La détection du disque ne suffit pas toujours. Si la partition racine se trouve sur LVM, un RAID ou un volume chiffré, l’initramfs doit également disposer des composants nécessaires pour assembler ou déverrouiller le volume avant de pouvoir monter /.

Ainsi, si le SSD apparaît correctement depuis un Live USB mais que Linux affiche toujours unknown-block au démarrage, vérifiez la configuration de l’initramfs et la manière dont la partition racine est construite.

Si les pilotes nécessaires sont bien présents, poursuivez plutôt le diagnostic du côté de l’UUID, de GRUB, du système de fichiers ou du stockage lui-même.

Réparer depuis un Live USB Linux

Si Linux ne démarre avec aucun noyau disponible ni en mode de récupération, utilisez un Live USB Linux. Celui-ci permet d’accéder au système installé depuis un environnement indépendant afin d’effectuer les réparations.

Commencez par identifier et monter la partition racine comme expliqué dans la section « Vérifier la partition racine et son UUID ». Profitez également du Live USB pour sauvegarder vos fichiers importants si vous suspectez une corruption du système de fichiers ou un problème de stockage.

Une fois la partition montée, vous pouvez utiliser chroot afin d’exécuter les commandes dans l’environnement du Linux installé.

Réparer l’installation avec chroot

Pour reconstruire l’initramfs ou corriger la configuration de démarrage, vous pouvez ensuite utiliser chroot afin d’exécuter les commandes dans l’environnement du Linux installé.

Cette opération nécessite notamment de monter certains systèmes virtuels et, selon la configuration, les partitions /boot et EFI. La procédure étant identique à celle utilisée pour réparer GRUB depuis un Live USB, suivez le guide dédié :

Le guide complet :

mkdir -p /tmp/chroot
sudo mount -t ext4 /dev/sda2 /tmp/chroot
sudo mount --bind /proc /tmp/chroot/proc
sudo mount --bind /dev /tmp/chroot/dev
sudo mount --bind /sys /tmp/chroot/sys
sudo chroot /tmp/chroot/

Une fois dans le chroot, sur Ubuntu ou Debian, reconstruisez l’initramfs :

update-initramfs -u -k all

Puis régénérez la configuration de GRUB :

update-grub

Sur Fedora, RHEL ou une distribution utilisant dracut, reconstruisez l’initramfs avec l’outil correspondant à votre distribution.

Quittez ensuite le chroot, démontez proprement les partitions puis redémarrez le PC sans le Live USB.

Si l’erreur « VFS: Unable to mount root fs » persiste malgré un UUID correct et un initramfs reconstruit, poursuivez les vérifications du côté des pilotes de stockage, du système de fichiers et de l’état du SSD ou du disque dur.

Que faire si l’erreur persiste ?

Si Linux affiche toujours « VFS: Unable to mount root fs » après les vérifications précédentes, évitez de multiplier les modifications au hasard. À ce stade, il faut déterminer précisément à quelle étape l’accès à la partition racine échoue.

Vérifiez en priorité les points suivants :

• Essayez un ancien noyau Linux depuis GRUB.
• Vérifiez que la partition racine est bien détectée avec lsblk -f et blkid.
• Comparez son UUID avec celui utilisé dans /etc/fstab et le paramètre root= de GRUB.
• Reconstruisez l’initramfs et vérifiez qu’il contient les pilotes de stockage nécessaires.
• Contrôlez et réparez le système de fichiers si des erreurs sont détectées.
• Vérifiez l’état de santé du SSD ou du disque dur.
• Recherchez les messages I/O error, nvme, ata, EXT4-fs error ou similaires avant le Kernel Panic.
• Utilisez un Live USB Linux lorsque le système installé ne permet plus d’effectuer ces opérations.

Le message unknown-block(...) peut également aider à orienter les recherches. Un unknown-block(0,0) suggère notamment que le noyau ne parvient pas à identifier correctement le périphérique racine, ce qui renforce les pistes liées à l’initramfs, au paramètre root= ou au pilote de stockage.

À l’inverse, si le périphérique est identifié mais que son système de fichiers ne peut pas être monté, concentrez davantage les vérifications sur la partition, le système de fichiers et l’état du stockage.

Sauvegarder les données avant d’aller plus loin

Si le SSD ou le disque présente des erreurs ou si le système de fichiers se corrompt régulièrement, sauvegardez vos fichiers importants avant de poursuivre les réparations.

Un Live USB permet généralement d’accéder à la partition Linux et de copier les données vers un autre support, à condition que le stockage reste suffisamment fonctionnel.

Évitez notamment d’enchaîner les réparations du système de fichiers sur un disque présentant des erreurs matérielles : la priorité devient alors la récupération des données et le remplacement du périphérique défaillant.

Le guide complet :

Réinstaller Linux en dernier recours

Une réinstallation peut être envisagée si le stockage est sain mais que le système reste impossible à démarrer malgré :

UUID correct → système de fichiers sain → initramfs reconstruit → pilotes présents → GRUB corrigé.

Elle doit toutefois rester une solution de dernier recours. L’erreur « Unable to mount root fs » possède souvent une cause précise qu’il est possible de corriger sans réinstaller complètement Linux.

Si le problème s’accompagne d’autres Kernel Panic, de blocages ou d’erreurs matérielles sans rapport apparent, élargissez également le diagnostic au reste du PC.

Le guide complet :

L’article Kernel Panic « VFS: Unable to mount root fs » sous Linux : les solutions est apparu en premier sur malekal.com.

Un Kernel Panic est l’une des erreurs les plus critiques que peut rencontrer un système Linux. Il se produit lorsque le noyau détecte une situation suffisamment grave pour qu’il ne puisse plus continuer à fonctionner normalement. Le système peut alors se figer complètement, afficher une série de messages techniques ou redémarrer automatiquement.

Les causes sont nombreuses : pilote ou module noyau défectueux, mise à jour du kernel, mémoire RAM instable, problème CPU, carte graphique, SSD ou disque défaillant, système de fichiers corrompu ou erreur lors du démarrage.

Identifier l’origine d’un Kernel Panic nécessite donc d’examiner les messages du noyau et les événements ayant précédé le plantage. Des outils comme journalctl, dmesg, lsmod ou kdump permettent de récupérer des informations précieuses et d’orienter le diagnostic vers un problème logiciel ou matériel.

Dans ce guide, découvrez comment diagnostiquer un Kernel Panic sous Linux, récupérer et analyser les journaux, identifier un pilote ou module responsable, vérifier le matériel et réparer un système qui ne démarre plus après le plantage.

Qu’est-ce qu’un Kernel Panic sous Linux ?

Un Kernel Panic est une erreur critique du noyau Linux qui se produit lorsque celui-ci rencontre une situation suffisamment grave pour qu’il ne puisse plus continuer à fonctionner normalement.

Le noyau (kernel) constitue le cœur du système Linux. Il assure notamment la communication avec le matériel, la gestion de la mémoire, des processus, des pilotes et des systèmes de fichiers. Lorsqu’une erreur irrécupérable survient à ce niveau, poursuivre l’exécution pourrait provoquer une corruption des données ou aggraver le problème. Le noyau peut alors déclencher volontairement un panic et arrêter le système.

Selon la configuration de Linux, le PC peut alors :

• Se figer complètement avec un message d’erreur à l’écran.
• Afficher une série d’informations techniques et une Call Trace.
• Redémarrer automatiquement après quelques secondes.
• Rester bloqué jusqu’à un redémarrage manuel.

Un Kernel Panic est donc différent du simple plantage d’une application. Si Firefox, un jeu ou un autre programme se ferme brutalement, le noyau Linux continue généralement de fonctionner. Lors d’un Kernel Panic, c’est au contraire le fonctionnement du système lui-même qui est compromis.

Kernel Panic, Kernel Oops ou blocage : quelles différences ?

Tous les problèmes graves de Linux ne correspondent pas nécessairement à un Kernel Panic.

Un Kernel Oops indique qu’une erreur a été détectée dans le noyau. Linux enregistre des informations techniques sur l’incident et peut parfois continuer à fonctionner, même si le système peut ensuite devenir instable.

Un Kernel Panic est plus grave : le noyau considère qu’il n’est plus possible de poursuivre l’exécution de manière sûre.

Enfin, un freeze ou blocage de Linux peut avoir de nombreuses autres origines : pilote graphique bloqué, manque de mémoire, problème matériel, stockage défaillant ou processus qui monopolise certaines ressources. Un écran figé ne signifie donc pas automatiquement qu’un Kernel Panic s’est produit.

Les messages affichés à l’écran ou enregistrés dans les journaux sont essentiels pour faire la différence. Des termes comme Kernel panic, Oops, BUG, Call Trace ou le nom d’un module noyau constituent alors des indices importants.

Dans la suite de ce guide, nous allons voir quelles sont les principales causes d’un Kernel Panic et comment récupérer ces informations afin d’identifier son origine.

Quelles sont les causes d’un Kernel Panic ?

Un Kernel Panic peut avoir une origine logicielle ou matérielle. Un pilote défectueux, un problème de mémoire RAM, une erreur de stockage ou encore une mise à jour du noyau peuvent provoquer une erreur suffisamment grave pour empêcher Linux de continuer à fonctionner normalement.

Voici les causes les plus courantes :

Cause	Exemples	Indices possibles
Pilote ou module noyau	Pilote graphique, Wi-Fi, stockage, module tiers	Nom d’un module dans la Call Trace, panic après une mise à jour
Mémoire RAM instable	Barrette défectueuse, XMP/EXPO instable, timings incorrects	Erreurs aléatoires, panic différents, corruption mémoire
Processeur instable	Overclocking, undervolting, température excessive	Plantages sous forte charge, erreurs matérielles
Carte graphique / pilote GPU	Pilote NVIDIA/AMD, module noyau graphique	Écran noir, blocage graphique, module GPU cité dans les journaux
SSD ou disque dur	Erreurs d’E/S, SSD défaillant, contrôleur de stockage	I/O error, erreurs NVMe/SATA, système de fichiers inaccessible
Système de fichiers	Corruption ext4, Btrfs, XFS…	Erreurs de montage, corruption ou erreurs de lecture
Noyau Linux	Régression ou bug après une mise à jour	Problème apparu avec une nouvelle version du kernel
Initramfs / démarrage	Image initramfs endommagée, pilote de stockage manquant	Kernel Panic principalement au démarrage
Matériel ou firmware	BIOS/UEFI, carte mère, alimentation, périphérique PCIe	Erreurs matérielles, comportement instable ou aléatoire

Pilote ou module du noyau défectueux

Les pilotes et modules du noyau sont une cause importante de Kernel Panic puisqu’ils s’exécutent directement dans l’espace noyau.

Un problème peut apparaître après la mise à jour d’un pilote graphique, l’installation d’un module tiers ou le passage à une nouvelle version du noyau Linux. Les pilotes NVIDIA, les modules DKMS ou certains pilotes de périphériques constituent par exemple des éléments à vérifier lorsqu’un Kernel Panic apparaît après une modification du système.

Le nom du module impliqué peut parfois apparaître dans la Call Trace ou dans les messages enregistrés avant le plantage.

Problème matériel ou instabilité du PC

Un Kernel Panic peut également être la conséquence d’une instabilité matérielle. La mémoire RAM est notamment à surveiller : une barrette défectueuse ou des paramètres XMP/EXPO trop agressifs peuvent provoquer des corruptions mémoire qui finissent par faire planter le noyau.

Le processeur peut également devenir instable à cause d’un overclocking, d’un undervolting trop important ou, dans certains cas, de températures excessives.

Si les Kernel Panic sont aléatoires, impliquent des modules différents ou apparaissent principalement sous forte charge, il est pertinent d’élargir le diagnostic au matériel.

Les guides complets :

Stockage et système de fichiers

Un SSD ou un disque dur défaillant peut provoquer des erreurs d’entrée/sortie (I/O) qui empêchent le noyau d’accéder correctement aux données nécessaires au fonctionnement du système.

Une corruption du système de fichiers peut également entraîner des problèmes graves, notamment lorsque la partition système devient inaccessible.

Des messages contenant I/O error, EXT4-fs error, BTRFS error, nvme ou encore des erreurs SATA constituent alors des pistes à examiner.

Mise à jour ou régression du noyau Linux

Enfin, un Kernel Panic peut apparaître après une mise à jour du noyau. Une nouvelle version peut introduire une régression ou révéler une incompatibilité avec un pilote ou un périphérique particulier.

Un indice particulièrement intéressant est donc la date d’apparition du problème. Si Linux fonctionnait normalement avant une mise à jour du kernel et que les Kernel Panic ont commencé immédiatement après, démarrer temporairement sur l’ancien noyau depuis GRUB constitue un excellent test.

L’identification de la cause repose toutefois rarement sur le seul message « Kernel Panic ». Il faut récupérer les journaux du noyau et les informations affichées au moment du plantage pour déterminer quel pilote, composant ou sous-système est réellement impliqué.

Comment récupérer les informations après un Kernel Panic ?

Pour déterminer l’origine d’un Kernel Panic, il faut récupérer les messages enregistrés par le noyau avant le plantage. Ils peuvent contenir le nom d’un pilote ou d’un module, une erreur mémoire, une erreur d’entrée/sortie ou encore une Call Trace permettant d’orienter le diagnostic.

Lorsque Linux a redémarré, journalctl est généralement le premier outil à utiliser.

Consulter les messages du noyau du démarrage précédent

Sur une distribution utilisant systemd, exécutez :

journalctl -k -b -1

L’option -k limite l’affichage aux messages du noyau, tandis que -b -1 demande les journaux correspondant au démarrage précédent.

Vous pouvez également afficher uniquement les erreurs :

journalctl -k -b -1 -p err

Recherchez notamment des termes comme :

panic
Oops
BUG
Call Trace
segfault
I/O error
MCE
EDAC
nvme
ext4
btrfs

Il est souvent utile d’examiner également les dernières lignes précédant le plantage, car l’erreur ayant déclenché le Kernel Panic peut apparaître avant le message final.

Vérifier les démarrages disponibles

Pour connaître les journaux de démarrage encore disponibles :

journalctl --list-boots

Vous obtenez une liste permettant d’identifier le démarrage actuel (0) et les précédents (-1, -2, etc.).

Vous pouvez ensuite consulter un démarrage particulier, par exemple :

journalctl -k -b -2

Cette méthode est particulièrement pratique lorsque le PC a déjà été redémarré plusieurs fois depuis le Kernel Panic.

Consulter les messages avec dmesg

La commande dmesg affiche les messages du tampon du noyau :

dmesg -T

Vous pouvez filtrer les erreurs avec, par exemple :

dmesg -T | grep -Ei "error|fail|panic|oops|bug|mce|edac|nvme|i/o"

dmesg est surtout utile pour examiner le démarrage et la session en cours. Après un redémarrage consécutif à un Kernel Panic, journalctl -k -b -1 est généralement plus intéressant pour retrouver les événements du système précédent.

Que faire si le journal du démarrage précédent est vide ?

Les journaux ne sont pas toujours conservés après un redémarrage. Vous pouvez vérifier si les anciens boots sont disponibles avec :

journalctl --list-boots

Si seul le démarrage actuel apparaît, la journalisation persistante n’est probablement pas disponible ou les anciens journaux ont déjà été supprimés.

Dans ce cas, il peut être nécessaire de configurer la conservation persistante du journal systemd avant de reproduire le problème.

Il faut également garder à l’esprit qu’un Kernel Panic particulièrement brutal peut empêcher Linux d’écrire les derniers messages sur le disque. Le journal peut alors s’interrompre juste avant l’information la plus intéressante.

Pour les plantages difficiles à reproduire ou lorsque les journaux classiques ne suffisent pas, des mécanismes plus avancés comme kdump permettent de conserver un vidage mémoire du noyau afin d’effectuer une analyse plus approfondie.

Une fois les messages récupérés, l’étape suivante consiste à identifier les lignes réellement importantes dans le Kernel Panic et à interpréter la Call Trace.

Vérifier si un pilote ou module noyau est responsable

Les pilotes et modules du noyau sont une cause fréquente de Kernel Panic, car ils s’exécutent directement dans l’espace noyau. Un module défectueux, incompatible avec une nouvelle version du kernel ou mal compilé peut provoquer une erreur critique du système.

La première étape consiste à rechercher si un nom de module revient dans les journaux ou dans la Call Trace du Kernel Panic.

Vous pouvez par exemple filtrer les messages du démarrage précédent avec :

journalctl -k -b -1 | grep -Ei "module|driver|oops|bug|call trace|taint"

Si un nom de module apparaît régulièrement juste avant le plantage, notez-le pour poursuivre les vérifications.

Lister les modules noyau chargés

La commande suivante affiche les modules actuellement chargés :

lsmod

Vous pouvez rechercher un module précis avec :

lsmod | grep nom_module

Pour obtenir davantage d’informations :

modinfo nom_module

modinfo peut notamment afficher :

• Le chemin du module.
• Sa version.
• Son auteur.
• Les dépendances.
• Les paramètres disponibles.
• La version du noyau pour laquelle il a été compilé selon le module.

Ces informations sont utiles lorsqu’un pilote tiers ou un module DKMS est suspecté.

Vérifier les modules DKMS

Certains pilotes tiers sont reconstruits automatiquement à chaque mise à jour du noyau grâce à DKMS, notamment certains pilotes graphiques ou pilotes matériels additionnels.

Pour afficher les modules DKMS installés :

dkms status

Si un Kernel Panic apparaît juste après une mise à jour du noyau, vérifiez que les modules nécessaires ont bien été recompilés pour la nouvelle version et qu’aucune erreur DKMS n’est présente.

Vous pouvez aussi comparer la version du noyau actuellement utilisée :

uname -r

avec les informations retournées par modinfo.

Rechercher les erreurs liées à un pilote précis

Si vous connaissez le nom du module suspect, filtrez directement les journaux :

journalctl -k -b -1 | grep -i nom_module

ou, pour la session en cours :

dmesg -T | grep -i nom_module

Recherchez notamment des messages indiquant :

• Une erreur d’initialisation.
• Un timeout.
• Une erreur PCIe.
• Un crash ou un BUG.
• Une erreur de mémoire.
• Un module marqué comme tainted.
• Un échec de chargement du firmware.

Désactiver temporairement un module pour confirmer le diagnostic

Si un module non essentiel semble responsable, vous pouvez tenter de le désactiver temporairement afin de vérifier si les Kernel Panic disparaissent.

Pour retirer un module chargé :

sudo modprobe -r nom_module

Cette commande ne fonctionne que si le module n’est pas utilisé par un périphérique ou un autre module.

Pour empêcher son chargement au prochain démarrage, il est également possible de le placer temporairement dans une blacklist modprobe. Cette méthode doit toutefois être utilisée avec prudence : bloquer un pilote graphique, réseau ou de stockage indispensable peut empêcher le système de fonctionner correctement.

L’objectif n’est donc pas de désactiver au hasard les modules présents dans la Call Trace, mais de vérifier si le même pilote revient systématiquement dans plusieurs Kernel Panic.

Le tutoriel :

Vérifier les changements récents

Si le problème est apparu récemment, demandez-vous ce qui a changé juste avant :

• Mise à jour du noyau Linux.
• Mise à jour du pilote NVIDIA ou AMD.
• Installation d’un nouveau module DKMS.
• Mise à jour du BIOS/UEFI.
• Ajout d’un périphérique PCIe, USB ou de stockage.
• Modification d’un paramètre du kernel ou du démarrage.

Lorsqu’un Kernel Panic apparaît juste après une mise à jour du noyau, un test très efficace consiste à redémarrer sur l’ancienne version du kernel depuis GRUB. Si les plantages disparaissent, cela renforce fortement l’hypothèse d’une régression du noyau ou d’une incompatibilité avec un pilote/module.

Enfin, gardez à l’esprit qu’un module cité dans une Call Trace n’est pas automatiquement le responsable. Une corruption mémoire ou une instabilité matérielle peut provoquer le crash d’un pilote parfaitement sain. Il faut donc toujours croiser cette piste avec les autres symptômes et les tests matériels.

Analyser un Kernel Panic avec kdump

Lorsque les journaux journalctl et dmesg ne permettent pas d’identifier l’origine d’un Kernel Panic, les utilisateurs avancés et administrateurs système peuvent utiliser kdump pour effectuer une analyse plus approfondie.

Kdump utilise kexec pour démarrer un second noyau, appelé noyau de capture, après le plantage. Une partie de la mémoire est réservée à l’avance afin que ce noyau puisse récupérer l’état mémoire du système qui vient de planter et l’enregistrer dans un fichier vmcore.

Le principe est le suivant : Kernel Panic → noyau de capture → création du vmcore → analyse du crash

Le fichier vmcore peut ensuite être analysé avec des outils spécialisés comme crash, en utilisant les symboles de débogage correspondant au noyau ayant planté. Cette analyse permet notamment d’examiner les messages du noyau, la pile d’appels, les processus et les modules présents au moment du crash.

La mise en place et surtout l’analyse d’un vmcore restent toutefois des opérations techniques destinées principalement aux administrateurs système et au débogage du noyau. Pour un PC personnel, commencez par journalctl, les messages du noyau, la vérification des pilotes/modules et le diagnostic matériel.

Pour configurer kdump ou analyser un crash en profondeur, consultez la documentation officielle : Documentation officielle de kdump — Linux Kernel

Pour l’analyse d’un vmcore avec l’utilitaire crash, la documentation Red Hat fournit également une procédure détaillée : Analyser un core dump avec crash — Red Hat

Que faire si Linux ne démarre plus après un Kernel Panic ?

Si Linux ne démarre plus après un Kernel Panic, le problème peut venir du noyau récemment installé, d’un pilote/module incompatible, de l’initramfs, du système de fichiers ou d’un problème matériel.

L’objectif est d’abord de retrouver un système démarrable, puis d’analyser ce qui a changé juste avant l’apparition du problème.

Démarrer sur un ancien noyau depuis GRUB

Si les Kernel Panic ont commencé après une mise à jour du noyau, essayez en priorité de démarrer sur une version précédente.

Depuis le menu GRUB :

• Ouvrez Options avancées pour Ubuntu/Debian ou l’entrée équivalente de votre distribution.
• Sélectionnez un ancien noyau Linux.
• Démarrez normalement.

Si le système démarre correctement avec l’ancien kernel, cela oriente fortement vers une régression du noyau ou un problème de pilote/module compatible uniquement avec certaines versions.

Vous pouvez vérifier la version utilisée avec :

uname -r

Utiliser le mode de récupération

Si un ancien noyau ne suffit pas, essayez le mode Recovery / dépannage proposé dans GRUB.

Selon la distribution, ce mode permet notamment de :

• Ouvrir un shell root.
• Vérifier le système de fichiers.
• Réparer certains paquets.
• Recréer l’initramfs.
• Désactiver temporairement un pilote ou module problématique.

Il peut être utile lorsque le Kernel Panic survient très tôt pendant le démarrage.

Vérifier ou reconstruire l’initramfs

Un initramfs endommagé ou incomplet peut empêcher le noyau de charger les pilotes nécessaires au démarrage, notamment ceux liés au stockage.

Sur Debian/Ubuntu, vous pouvez reconstruire l’initramfs avec :

sudo update-initramfs -u -k all

Puis mettre à jour GRUB :

sudo update-grub

Sur d’autres distributions, la commande peut différer, par exemple avec dracut.

Démarrer depuis un Live USB

Si aucun noyau installé ne permet de démarrer, utilisez un Live USB Linux.

Depuis le système Live, vous pouvez :

• Accéder aux fichiers importants et effectuer une sauvegarde.
• Monter la partition Linux.
• Vérifier le système de fichiers.
• Examiner les journaux présents sur le disque.
• Réparer le chargeur d’amorçage.
• Réinstaller un noyau ou reconstruire l’initramfs.

C’est également une bonne méthode pour déterminer si le problème vient du système installé ou d’une panne matérielle plus générale.

Vérifier le système de fichiers et le stockage

Si le Kernel Panic est associé à des erreurs de lecture, de montage ou d’entrée/sortie, vérifiez le stockage avant d’insister sur les réparations logicielles.

Vous pouvez rechercher des erreurs dans les journaux avec des termes comme :

I/O error
EXT4-fs error
BTRFS error
nvme
ata
Buffer I/O error

Un système de fichiers endommagé peut parfois être réparé avec fsck, à condition de ne pas lancer la vérification sur une partition montée en écriture.

Profitez également du Live USB pour vérifier l’état SMART du SSD ou du disque si une défaillance matérielle est suspectée.

Le guide :

Désactiver temporairement un module problématique

Si les journaux ou la Call Trace pointent régulièrement vers un module noyau précis, il peut être utile de désactiver temporairement ce module afin de vérifier si Linux démarre à nouveau.

Cette opération est surtout pertinente pour les pilotes graphiques, Wi-Fi ou modules tiers. Évitez toutefois de blacklister au hasard un pilote lié au stockage ou à un composant indispensable au démarrage.

En dernier recours : sauvegarder puis réparer ou réinstaller

Si Linux reste impossible à démarrer malgré un ancien noyau, la reconstruction de l’initramfs et la vérification du stockage, sauvegardez d’abord vos données depuis un Live USB.

Vous pourrez ensuite tenter une réparation plus complète du système ou, si la corruption est importante, procéder à une réinstallation.

Avant d’en arriver là, vérifiez cependant que le problème n’est pas matériel. Des Kernel Panic répétés avec des messages différents peuvent être provoqués par une RAM instable, un SSD défaillant, un CPU instable ou un autre composant matériel.

Le guide complet :

Les messages de Kernel Panic les plus courants

Kernel panic – not syncing: VFS: Unable to mount root fs

C’est le cas incontournable. Le noyau a démarré, mais n’arrive pas à monter le système de fichiers racine (/). Les pistes typiques sont :

• initramfs absent, endommagé ou incorrect ;
• pilote du contrôleur de stockage ou du système de fichiers absent de l’initramfs ;
• mauvais paramètre root= transmis au noyau ;
• UUID de partition incorrect ;
• problème après une mise à jour du noyau ;
• système de fichiers endommagé ;
• SSD/disque ou contrôleur de stockage défaillant.

Le guide dédié :

Le guide Kernel Panic pourrait n’en donner qu’une explication de 200 mots + lien vers ce futur guide.

Kernel panic – not syncing: Attempted to kill init!

Le message Kernel panic - not syncing: Attempted to kill init! apparaît lorsque le processus init, généralement le processus PID 1, s’arrête ou rencontre une erreur qui l’empêche de poursuivre son fonctionnement.

Ce processus joue un rôle essentiel : il constitue le premier processus lancé en espace utilisateur et permet ensuite d’initialiser le reste du système. S’il disparaît, Linux ne peut normalement plus poursuivre son fonctionnement et déclenche un Kernel Panic.

Cette erreur peut notamment être liée à :

• Un initramfs endommagé ou incomplet.
• Un problème avec systemd ou le programme utilisé comme init.
• Une corruption du système de fichiers racine.
• Des bibliothèques ou fichiers système manquants ou corrompus.
• Une mise à jour interrompue ou défectueuse.
• Une erreur de mémoire ou une instabilité matérielle provoquant le crash du processus init.

Si le problème apparaît au démarrage, essayez d’abord de lancer un ancien noyau depuis GRUB ou le mode de récupération. Vous pouvez ensuite vérifier le système de fichiers, reconstruire l’initramfs et contrôler les fichiers système.

Il est également important d’examiner les lignes affichées juste avant Attempted to kill init! : ce message indique la conséquence finale du problème, mais pas nécessairement sa cause initiale.

Kernel panic – not syncing: Fatal exception

Le message Kernel panic - not syncing: Fatal exception indique qu’une exception suffisamment grave s’est produite dans le noyau pour empêcher Linux de poursuivre son fonctionnement en toute sécurité.

Contrairement à une erreur très spécifique comme VFS: Unable to mount root fs, le message Fatal exception ne permet généralement pas à lui seul d’identifier la cause.

Il faut donc examiner les informations qui le précèdent, notamment :

• La Call Trace.
• Le nom d’un pilote ou module noyau.
• Les éventuels messages Oops ou BUG.
• Le processus et le CPU concernés.
• Les erreurs mémoire ou matérielles précédant le panic.
• Les modules éventuellement indiqués comme chargés ou impliqués.

Une Fatal exception peut notamment provenir d’un bug du noyau, d’un pilote défectueux, d’un module tiers ou d’une corruption mémoire provoquée par une instabilité matérielle.

Après le redémarrage, consultez en priorité les messages du noyau du démarrage précédent :

journalctl -k -b -1

Si plusieurs Kernel Panic présentent des Call Trace différentes et impliquent des modules sans rapport entre eux, élargissez également les vérifications à la RAM, au processeur et au matériel.

Kernel Panic après une mise à jour du noyau

Si les Kernel Panic commencent immédiatement après une mise à jour du noyau Linux, la nouvelle version du kernel constitue une piste importante.

Le problème ne vient toutefois pas nécessairement du noyau lui-même. Une mise à jour peut également révéler une incompatibilité avec un pilote, un module DKMS, l’initramfs ou un périphérique matériel.

Le test le plus simple consiste à redémarrer le PC et à sélectionner l’ancienne version du noyau depuis les options avancées de GRUB.

Si Linux fonctionne normalement avec l’ancien kernel, vérifiez ensuite :

• Les éventuelles erreurs connues avec la nouvelle version du noyau.
• Les modules DKMS avec dkms status.
• Les pilotes graphiques ou autres pilotes tiers récemment mis à jour.
• La bonne génération de l’initramfs.
• Les journaux du démarrage ayant échoué.
• Les paramètres du noyau éventuellement modifiés.

Vous pouvez connaître le noyau actuellement utilisé avec :

uname -r

et afficher les noyaux disponibles dans /boot :

ls -lh /boot

Si l’ancien noyau fonctionne correctement, conservez-le temporairement comme solution de secours plutôt que de supprimer immédiatement les autres versions. Cela permet de continuer à utiliser Linux pendant que vous recherchez s’il s’agit d’une régression du kernel ou d’une incompatibilité avec un module.

L’article Kernel Panic sous Linux : causes, diagnostic et solutions est apparu en premier sur malekal.com.

VLC Media Player est réputé pour sa légèreté et sa capacité à lire pratiquement n’importe quel format audio ou vidéo. Pourtant, certains utilisateurs de Windows 11 signalent depuis plusieurs versions des ralentissements au démarrage, des saccades ou des comportements anormaux qui ne se reproduisent pas nécessairement sous Windows 10 ou Linux.

Dans un nouvel échange rapporté par WindowsLatest, VideoLAN rejette l’idée selon laquelle VLC serait simplement devenu trop lourd ou mal optimisé. Le projet pointe plutôt du doigt plusieurs changements et problèmes propres à Windows 11, tout en profitant de l’occasion pour rappeler les contraintes très différentes qui existent entre un projet open source multiplateforme et une application développée directement par Microsoft.

La polémique intervient alors que Microsoft tente justement de moderniser Windows 11 et ses applications avec davantage de composants natifs, notamment WinUI, tout en promettant de réduire la consommation de mémoire et les lenteurs de son interface.

Des ralentissements de VLC déjà signalés sous Windows 11

Les problèmes de performances de VLC sous Windows 11 ne sont pas nouveaux.

Des rapports publiés sur le système de suivi de VideoLAN font état depuis plusieurs années de lancements anormalement longs. Un utilisateur signalait ainsi dès 2022 que la première ouverture de VLC après le démarrage de Windows 11 pouvait prendre plus d’une minute, alors que les autres applications démarraient normalement.

Plus récemment, des utilisateurs de VLC 3.0.23 ont également observé un délai d’une dizaine de secondes lors du premier lancement, avant que les ouvertures suivantes ne redeviennent instantanées.

D’autres problèmes sont beaucoup plus spécifiques à Windows 11.

Par exemple, un bug affectant VLC 3.0.21 et 3.0.23 provoque un blocage lorsque l’utilisateur tente de modifier le type de fichier depuis la fenêtre « Ajouter un fichier » de la liste de lecture. Le problème a été reproduit sous Windows 11 25H2, alors que le même scénario fonctionne correctement sous Windows 10.

Ces éléments ne suffisent pas à démontrer qu’un seul bug Windows explique tous les ralentissements de VLC, mais ils montrent que certaines régressions sont bien liées à l’environnement Windows 11 plutôt qu’au lecteur multimédia seul.

Quelles sont les solutions ?

Tentez de regénérer le cache VLC peut résoudre les lenteurs d’ouverture du lecteur.
Pour cela :

• Accédez au dossier : C:\Program Files (x86)\VideoLAN\VLC
• Double-cliquez sur vlc-cache-gen.exe

• Puis relancez VLC pour vérifier si son ouverture est plus rapide

Windows 11 24H2 pose aussi des problèmes avec certaines configurations GPU

Un autre exemple particulièrement intéressant concerne les ordinateurs utilisant plusieurs cartes graphiques.

Un rapport publié dans le bug tracker de VLC décrit des pertes massives d’images sous Windows 11 24H2 lorsqu’un système utilise simultanément un GPU intégré AMD et une carte graphique NVIDIA dédiée.

Dans ce scénario, VLC peut tomber temporairement à environ 12 images par seconde lorsqu’il est affiché sur un écran connecté au GPU intégré.

Le problème :

• apparaît après le passage à Windows 11 24H2 ;
• ne se produisait pas sur la version précédente de Windows ;
• disparaît lorsque VLC est affiché sur un écran connecté directement au GPU dédié ;
• ne semble pas lié à une saturation du CPU, du GPU ou du stockage.

Le développeur à l’origine du rapport soupçonne une interaction complexe avec le compositeur graphique de Windows, notamment lorsque plusieurs GPU provenant de constructeurs différents sont utilisés.

Cela illustre bien la difficulté pour un logiciel comme VLC : le lecteur peut être correctement optimisé, mais dépend malgré tout d’une longue chaîne comprenant Windows, Direct3D, le compositeur graphique et les pilotes GPU.

VLC reste pourtant nettement plus léger que le nouveau Media Player de Microsoft

La critique est d’autant plus intéressante que les propres applications multimédias de Microsoft ne sont pas particulièrement exemplaires en matière de performances.

WindowsLatest avait précédemment comparé le nouveau Lecteur multimédia de Windows 11 avec VLC et l’ancien Lecteur Windows Media.

Dans ce test, VLC et l’ancien lecteur de Microsoft ouvraient une vidéo quasiment immédiatement, alors que le nouveau Media Player nécessitait plusieurs secondes.

La différence était également importante au niveau de la mémoire :

• nouveau Media Player : environ 377 Mo de RAM au repos ;
• ancien Lecteur Windows Media : environ 103 Mo.

Cette comparaison ne constitue évidemment pas un benchmark universel, mais elle montre que l’équation « application moderne = application plus rapide » est loin d’être automatique.

Microsoft a d’ailleurs reconnu travailler sur la consommation de mémoire et les performances de WinUI, son framework moderne destiné à devenir progressivement la base de nombreuses interfaces de Windows 11.

Microsoft veut justement rendre Windows 11 plus natif

Cette discussion arrive à un moment intéressant pour Windows.

Microsoft a récemment annoncé vouloir réduire l’usage de composants Web dans l’interface de Windows 11 au profit de technologies plus natives. L’objectif est notamment de réduire :

• la consommation de mémoire ;
• les temps de démarrage ;
• l’activité CPU ;
• les animations saccadées.

WinUI 3 doit jouer un rôle central dans cette transformation.

Microsoft prévoit notamment de moderniser progressivement plusieurs éléments historiques de Windows avec ce framework, mais l’entreprise travaille parallèlement à optimiser WinUI avant de généraliser son utilisation.

Le paradoxe est donc assez visible : Microsoft encourage les développeurs à créer des applications Windows modernes et natives, alors que certaines applications historiques comme VLC restent parfois plus rapides avec une architecture beaucoup plus ancienne.

Pourquoi VLC ne peut pas être comparé directement à une application Microsoft

Il faut également tenir compte d’une différence fondamentale.

Le nouveau Media Player de Microsoft est conçu spécifiquement pour Windows.

VLC, lui, est un projet multiplateforme qui doit fonctionner sur un très grand nombre de systèmes et d’architectures.

VideoLAN maintient VLC pour :

• Windows ;
• Linux ;
• macOS ;
• Android ;
• iOS ;
• différentes architectures ARM et x86 ;
• plusieurs générations de systèmes d’exploitation.

VLC 3 continue même de prendre en charge certaines anciennes versions de Windows, tandis que VLC 4 suit une autre trajectoire de compatibilité. Le projet VideoLAN travaille actuellement à faire cohabiter ces branches et à gérer leur mise à jour selon la version de Windows utilisée.

Cette compatibilité impose nécessairement davantage de couches d’abstraction et limite la possibilité d’utiliser exclusivement les toutes dernières API de Windows.

Microsoft, à l’inverse, contrôle à la fois le système d’exploitation, ses API, son framework graphique et ses propres applications.

Comparer uniquement les temps de lancement sans tenir compte de cette différence serait donc assez réducteur.

VLC garde aussi un avantage important : les codecs

VLC conserve également un avantage considérable sur le lecteur de Microsoft : sa compatibilité avec les formats multimédias.

Le logiciel peut lire une très grande variété de codecs sans demander l’installation de packs supplémentaires.

Le cas du HEVC/H.265 est particulièrement parlant.

Le nouveau Media Player de Windows peut nécessiter l’installation de l’extension HEVC disponible dans le Microsoft Store, alors que VLC prend directement en charge ce format.

Windows 11 24H2 a également supprimé de son installation standard le codec AC-3 (Dolby Digital). Les applications disposant de leurs propres décodeurs, comme VLC, continuent toutefois de lire ces contenus indépendamment des codecs fournis par Windows.

Cette indépendance vis-à-vis des codecs du système constitue depuis longtemps l’un des principaux atouts de VLC.

Un logiciel signé et rapide ne dépend pas uniquement de son propre code

Le débat met surtout en lumière un point souvent oublié lorsqu’on analyse les performances d’une application.

Lorsqu’un logiciel tourne sous Windows, son comportement dépend également :

• du planificateur CPU ;
• du système graphique ;
• des pilotes GPU ;
• des API Direct3D ;
• de la gestion de l’énergie ;
• de l’Explorateur de fichiers ;
• des boîtes de dialogue système ;
• des mécanismes de sécurité ;
• du compositeur de fenêtres.

Une régression dans l’une de ces couches peut donc rendre une application plus lente sans que son propre code ait changé.

Les problèmes observés avec VLC sous Windows 11 24H2 sur les configurations multi-GPU constituent un bon exemple : le même logiciel fonctionne normalement sur certaines configurations et devient saccadé lorsqu’il utilise une combinaison particulière de GPU et de sorties vidéo.

Cela ne signifie pas que VLC n’a jamais de problèmes

Il serait néanmoins excessif d’attribuer toutes les difficultés de VLC à Windows 11.

Le bug tracker du projet contient également des problèmes qui proviennent clairement de VLC ou de ses interactions avec certains pilotes.

VLC 3.0.22, par exemple, a rencontré des écrans noirs et des plantages avec certaines fonctions NVIDIA RTX Video HDR et RTX Video Super Resolution après une mise à jour des pilotes NVIDIA.

Des ralentissements ont aussi été rapportés lors de la lecture de certains contenus HEVC 12 bits ou AV1 très haute définition.

La réalité est donc plus nuancée : les performances d’un lecteur multimédia moderne dépendent à la fois du logiciel, de Windows et des pilotes graphiques.

VLC 4 doit moderniser profondément le lecteur

VideoLAN travaille parallèlement sur VLC 4.0, qui doit constituer la plus importante évolution du lecteur depuis de nombreuses années.

Jean-Baptiste Kempf décrit cette version comme la plus grosse refonte de VLC depuis environ vingt ans. Elle doit notamment proposer :

• une nouvelle interface ;
• de nouvelles capacités HDR ;
• une lecture sans interruption entre les morceaux ;
• de nouvelles fonctions audio et vidéo ;
• des améliorations importantes du moteur multimédia.

Le défi sera donc de moderniser fortement l’interface tout en conservant l’une des caractéristiques qui ont fait le succès de VLC : sa légèreté.

C’est précisément le problème auquel Microsoft est également confronté avec Windows 11. Moderniser l’interface sans augmenter la consommation de RAM ou dégrader la réactivité s’avère beaucoup plus complexe qu’un simple changement esthétique.

Microsoft et VideoLAN ont finalement le même problème

Derrière les critiques, Microsoft et VideoLAN travaillent en réalité sur un problème très similaire.

Microsoft tente de remplacer progressivement plusieurs composants historiques de Windows par une interface plus moderne basée sur WinUI, tout en réduisant la consommation de ressources.

VideoLAN prépare de son côté VLC 4.0, avec une refonte complète de l’interface sans vouloir sacrifier les performances et la compatibilité.

Dans les deux cas, les développeurs doivent composer avec plusieurs décennies d’héritage logiciel.

La différence est que Microsoft contrôle Windows de bout en bout, alors que VLC doit s’adapter aux décisions prises par Microsoft, Apple, Google, les fabricants de GPU et de nombreux autres acteurs.

Conclusion

Les critiques de VideoLAN envers Windows 11 rappellent qu’il est parfois trop simple d’accuser une application lorsqu’elle devient subitement plus lente après une mise à jour du système.

Plusieurs rapports montrent que VLC rencontre effectivement des problèmes spécifiques à Windows 11, notamment des lancements anormalement longs, des dysfonctionnements liés aux boîtes de dialogue système et des saccades sur certaines configurations multi-GPU apparues avec Windows 11 24H2.

Cela ne signifie pas pour autant que VLC est exempt de bugs. Mais le logiciel reste généralement très léger face à certaines applications modernes de Windows, tout en offrant une compatibilité multimédia nettement plus large.

Cette controverse illustre finalement un problème plus général de Windows 11 : Microsoft cherche encore le bon équilibre entre modernisation, performances et compatibilité. Et lorsqu’un logiciel multiplateforme comme VLC doit s’adapter à ces changements, les régressions peuvent rapidement devenir visibles pour des millions d’utilisateurs.

L’article VLC accuse Windows 11 d’être à l’origine de ses ralentissements et défend le modèle open source face à Microsoft est apparu en premier sur malekal.com.

Les écrans bleus de Windows, aussi appelés BSOD, peuvent être difficiles à diagnostiquer car le code d’arrêt affiché ne suffit pas toujours à identifier la cause réelle du plantage. Windows enregistre cependant des informations techniques dans des fichiers minidump (.dmp) qui permettent d’aller plus loin dans l’analyse.

Dans ce guide, nous allons voir comment analyser un écran bleu sur Windows 11 ou Windows 10, interpréter le code d’arrêt, identifier un pilote ou un composant suspect et exploiter les minidumps avec AnalysePC, WhoCrashed, BlueScreenView ou WinDbg.

Qu’est-ce qu’un écran bleu (BSOD) et un code d’arrêt ?

Un écran bleu, aussi appelé BSOD (Blue Screen of Death), apparaît lorsque Windows rencontre une erreur critique qu’il ne peut pas récupérer normalement. Le système interrompt alors son fonctionnement afin d’éviter une corruption plus importante et redémarre généralement le PC.

L’écran affiche un code d’arrêt (Stop Code), par exemple VIDEO_TDR_FAILURE, DRIVER_POWER_STATE_FAILURE ou MEMORY_MANAGEMENT. Ce code donne une première indication sur la nature du problème, mais il ne suffit pas toujours à identifier précisément sa cause.

Windows enregistre généralement des informations supplémentaires dans un fichier minidump (.dmp). Son analyse permet de rechercher le pilote, le composant matériel ou le contexte logiciel impliqué dans le plantage.

Le guide complet :

Où Windows enregistre les informations sur les écrans bleus ?

Windows enregistre les informations liées aux écrans bleus dans des fichiers de vidage mémoire (dump). Selon la configuration du système, il peut s’agir d’un minidump léger ou d’un fichier de vidage plus complet.

Les minidumps sont généralement stockés dans :

C:\Windows\Minidump

Un fichier de vidage mémoire plus complet peut également être créé dans :

C:\Windows\MEMORY.DMP

Ces fichiers contiennent notamment le code d’arrêt, le contexte du plantage et des informations sur les pilotes chargés au moment du BSOD. Ce sont eux qu’utilisent les outils comme AnalysePC, WhoCrashed, BlueScreenView ou WinDbg pour rechercher la cause du crash.

Pour vérifier ou modifier le type de fichier de vidage créé par Windows, vous pouvez suivre ce guide :

Analyser automatiquement les écrans bleus avec AnalysePC

AnalysePC permet d’analyser automatiquement les fichiers minidump enregistrés par Windows après un écran bleu. L’outil récupère le code d’arrêt, recherche les pilotes présents dans le dump et croise ces informations avec la configuration et l’historique du PC.

Pour chaque BSOD, AnalysePC peut notamment afficher :

• le code d’arrêt détecté ;
• la piste technique la plus probable, par exemple un pilote comme nvlddmkm.sys ;
• un niveau de confiance selon la qualité des indices présents dans le dump ;
• les pilotes et versions actuellement installés ;
• les modifications de pilotes ou mises à jour intervenues avant ou après le plantage ;
• un plan d’action avec les vérifications et solutions recommandées.

L’intérêt est de ne pas se limiter au nom d’un fichier trouvé dans le minidump. AnalysePC replace le crash dans son contexte afin de déterminer si le pilote constitue réellement une piste crédible ou seulement un élément présent au moment du plantage.

Pour lancer une analyse et découvrir le fonctionnement complet de l’outil, consultez le tutoriel dédié :

Comprendre le code d’arrêt détecté

AnalysePC commence par identifier le code d’arrêt enregistré dans le fichier minidump. Il peut s’agir par exemple de VIDEO_TDR_FAILURE, DRIVER_POWER_STATE_FAILURE, MEMORY_MANAGEMENT ou encore WHEA_UNCORRECTABLE_ERROR.

Le rapport indique ensuite la signification générale du code et la famille de problèmes à laquelle il correspond. Cela permet de savoir rapidement si la piste s’oriente plutôt vers un pilote, la carte graphique, la mémoire, le stockage ou un problème matériel.

Lorsque plusieurs fichiers minidump sont disponibles, AnalysePC peut également comparer les différents BSOD afin de voir si le même code d’arrêt ou la même famille d’erreurs revient régulièrement.

Identifier le pilote ou composant suspect

Le minidump peut contenir le nom d’un pilote ou d’un module présent au moment du plantage. AnalysePC tente de transformer cette information technique en une piste plus compréhensible.

Par exemple, un fichier comme nvlddmkm.sys peut être rapproché du pilote graphique NVIDIA actuellement installé. Le rapport affiche alors le composant concerné, la version du pilote et les éléments qui renforcent ou affaiblissent cette hypothèse.

AnalysePC attribue aussi un niveau de confiance à la piste proposée. C’est important, car la présence d’un pilote dans un dump ne signifie pas automatiquement qu’il est responsable du BSOD. Le véritable problème peut provenir du matériel, d’un autre pilote ou d’une corruption survenue plus tôt.

Exploiter la chronologie des pilotes et mises à jour

AnalysePC ne se contente pas de lire le contenu du minidump. Il rapproche également le plantage de l’historique des pilotes et des mises à jour Windows disponible dans le rapport.

Cela permet notamment de repérer :

• une mise à jour de pilote installée peu avant les premiers BSOD ;
• un changement de version après un plantage ;
• plusieurs modifications successives d’un même pilote ;
• une mise à jour Windows proche de la période d’apparition des problèmes.

La chronologie aide ainsi à déterminer si un changement récent constitue une piste crédible. À l’inverse, si un pilote a été mis à jour après les plantages et qu’aucun nouvel incident n’est apparu, AnalysePC peut également signaler que le problème a peut-être déjà été corrigé.

Suivre les solutions proposées par AnalysePC

À partir du code d’arrêt, des pilotes détectés et des autres éléments du rapport, AnalysePC propose un plan de résolution adapté à la piste retenue.

Selon le problème, les recommandations peuvent par exemple consister à mettre à jour ou réinstaller proprement un pilote, revenir à une version précédente, vérifier Windows Update, contrôler les températures ou effectuer des tests matériels.

Lorsque les données ne permettent pas d’identifier une cause suffisamment fiable, le rapport le précise et propose des vérifications complémentaires plutôt que de désigner arbitrairement un responsable.

Cette dernière partie permet donc de passer directement de l’analyse du BSOD aux actions à effectuer pour confirmer la cause et tenter de corriger le problème.

Analyser un écran bleu avec WhoCrashed

WhoCrashed est un outil spécialisé dans l’analyse des fichiers minidump générés après un écran bleu. Il examine les informations enregistrées par Windows et tente d’identifier le code d’arrêt, le pilote éventuellement impliqué et la nature probable du plantage.

Son principal intérêt est sa simplicité : il fournit un rapport lisible sans nécessiter de manipuler directement les fichiers .dmp ou d’utiliser WinDbg. Il peut ainsi constituer une bonne première étape pour comprendre l’origine d’un BSOD.

L’identification d’un pilote dans WhoCrashed doit toutefois rester une piste de diagnostic. Un fichier mentionné dans le dump n’est pas nécessairement la cause réelle du problème.

Pour apprendre à utiliser l’outil et interpréter ses résultats, consultez le guide dédié :

Analyser les fichiers minidump avec BlueScreenView

BlueScreenView est un utilitaire qui analyse les fichiers minidump créés par Windows après un écran bleu. Il permet de retrouver rapidement les différents BSOD enregistrés sur le PC et d’afficher, pour chacun d’eux, le code d’arrêt, la date du plantage ainsi que les pilotes ou modules présents dans le dump.

L’outil est particulièrement pratique pour comparer plusieurs écrans bleus et repérer si le même pilote revient régulièrement. Il propose une vue plus technique que WhoCrashed, tout en restant beaucoup plus simple à utiliser que WinDbg.

Comme pour les autres outils d’analyse de minidumps, un pilote mis en évidence par BlueScreenView doit être considéré comme une piste et non comme une preuve certaine de sa responsabilité.

Pour apprendre à utiliser BlueScreenView et interpréter les informations affichées, consultez le tutoriel dédié :

Analyser un BSOD avec WinDbg

WinDbg est l’outil de débogage de Microsoft destiné à l’analyse avancée des fichiers de vidage mémoire. Il permet d’examiner en détail un minidump ou un fichier MEMORY.DMP afin d’obtenir le code d’arrêt, la pile d’appels, les modules chargés et les pilotes potentiellement impliqués dans le plantage.

Il est plus technique que WhoCrashed ou BlueScreenView, mais fournit aussi davantage d’informations. La commande !analyze -v permet notamment d’obtenir une première analyse détaillée du crash et d’identifier les éléments les plus pertinents à examiner.

WinDbg est surtout utile lorsqu’un BSOD reste difficile à expliquer ou lorsque les outils plus simples ne permettent pas d’identifier clairement la cause.

Pour apprendre à ouvrir un fichier de vidage et interpréter les informations retournées par WinDbg, consultez le tutoriel dédié :

Le tutoriel :

Comment interpréter le pilote indiqué dans le minidump ?

Lors de l’analyse d’un écran bleu, le minidump peut faire apparaître le nom d’un pilote ou d’un module, par exemple nvlddmkm.sys, rtkvhd64.sys ou encore ntoskrnl.exe. Il faut toutefois éviter de considérer automatiquement ce fichier comme la cause certaine du BSOD.

Le pilote affiché peut être directement responsable du plantage, mais il peut aussi simplement avoir été actif au moment de l’erreur. Un problème matériel, une corruption mémoire ou un autre pilote peut avoir provoqué l’instabilité avant que le fichier signalé ne soit impliqué.

Il est donc préférable de croiser plusieurs éléments : le code d’arrêt, le pilote cité, sa version, les autres minidumps disponibles et les changements récents de pilotes ou de Windows.

Si le même pilote revient dans plusieurs BSOD avec des codes cohérents, la piste devient plus crédible. À l’inverse, si les fichiers incriminés changent constamment, il peut être nécessaire d’élargir le diagnostic à la mémoire, au matériel ou à la stabilité générale du système.

C’est notamment l’intérêt d’AnalysePC, qui ne se limite pas au nom du pilote extrait du dump et tente de le replacer dans le contexte global du PC.

Les codes d’arrêt Windows les plus courants

Chaque écran bleu est associé à un code d’arrêt (Stop Code) qui donne une première indication sur la nature du problème rencontré par Windows. Certains concernent plutôt les pilotes, d’autres la mémoire, le stockage, la carte graphique ou encore une erreur matérielle.

Parmi les codes fréquemment rencontrés, on peut citer VIDEO_TDR_FAILURE, DRIVER_POWER_STATE_FAILURE, MEMORY_MANAGEMENT, CRITICAL_PROCESS_DIED ou WHEA_UNCORRECTABLE_ERROR.

Le code d’arrêt constitue toutefois seulement un point de départ : il faut généralement le croiser avec le contenu du minidump et les autres informations du PC pour identifier la cause réelle.

Pour connaître la signification des principaux codes et les solutions associées, consultez le guide dédié aux codes d’arrêt et erreurs BSOD de Windows.

Pour les connaître, suivez ce guide :

Que faire si la cause des écrans bleus reste inconnue ?

Lorsque plusieurs écrans bleus affichent des codes d’arrêt ou des pilotes différents, il ne faut pas forcément chercher une cause indépendante pour chaque BSOD. Une instabilité plus générale peut provoquer des plantages variés : mémoire défectueuse, surchauffe, alimentation, pilote instable ou autre problème matériel.

Dans ce cas, il est préférable d’élargir le diagnostic du PC plutôt que de se limiter à l’analyse d’un seul minidump. Vous pouvez notamment :

• effectuer un diagnostic complet du PC afin de rechercher des anomalies matérielles, logicielles et système ;
• lancer un StressTest Malekal pour vérifier la stabilité du processeur, de la carte graphique, de la mémoire et surveiller les températures sous charge ;
• demander de l’aide sur le forum Malekal en fournissant le rapport AnalysePC afin qu’il puisse être examiné dans son ensemble.

Les guides :

Cette approche est particulièrement utile lorsque les BSOD semblent aléatoires ou que le pilote indiqué change d’un plantage à l’autre. Dans ce cas, le problème peut se situer en amont du composant mentionné dans le minidump.

Cas particulier : des codes d’arrêt différents à chaque BSOD

Si l’analyse des minidumps ne permet pas d’identifier clairement l’origine des écrans bleus, il faut poursuivre avec des vérifications plus larges.

Commencez par contrôler les pilotes, les mises à jour de Windows, l’état du stockage et la mémoire. Un test mémoire approfondi peut être utile si les codes d’arrêt sont variés ou évoquent une corruption de données.

Il est également recommandé de surveiller les températures du processeur et de la carte graphique et, si nécessaire, d’effectuer un StressTest afin de vérifier si les plantages apparaissent sous charge.

Si aucune piste ne se dégage malgré ces contrôles, vous pouvez publier le rapport AnalysePC et les informations sur les BSOD sur le forum Malekal afin d’obtenir une analyse plus approfondie du problème.

Que faire après avoir identifié la cause du BSOD ?

Une fois le code d’arrêt identifié et les informations du minidump analysées, il devient généralement plus simple de rechercher la cause du BSOD et d’appliquer les solutions adaptées.

Selon le diagnostic, il peut être nécessaire de mettre à jour ou réinstaller un pilote, vérifier la mémoire RAM, contrôler le SSD, annuler une mise à jour récente ou rechercher une instabilité matérielle.

Pour poursuivre le dépannage, utilisez notre guide général consacré à la résolution des écrans bleus. Il regroupe les principales vérifications et solutions à appliquer lorsqu’un PC rencontre des BSOD sous Windows 11 ou Windows 10.

Suivre ce tutoriel :

L’article Comment diagnostiquer un écran bleu (BSOD) et trouver la cause sur Windows 11/10 est apparu en premier sur malekal.com.

Des chercheurs en sécurité ont dévoilé une nouvelle famille d’attaques baptisée Plug and Pwn, capable d’exploiter le mécanisme Plug and Play de Windows pour installer automatiquement des composants vulnérables et obtenir les privilèges SYSTEM.

L’attaque repose sur un principe particulièrement intéressant : au lieu d’exploiter directement Windows, les chercheurs émulent de faux périphériques USB afin de pousser le système à télécharger et installer des logiciels ou pilotes de constructeurs pourtant signés et légitimes. Certains de ces composants contiennent ensuite des faiblesses permettant une élévation de privilèges.

Présentée lors de la DEF CON 34 par les chercheurs Alejandro Hernando et Borja Martínez, cette technique peut, dans certains scénarios, fonctionner sans clic, sans utilisateur connecté et même à distance via le protocole RDP.

Plug and Play, un mécanisme pratique qui travaille avec des privilèges élevés

Lorsqu’un périphérique USB est connecté à un PC, Windows tente automatiquement de l’identifier.

Le système recherche ensuite un pilote adapté et peut également télécharger depuis Windows Update des composants supplémentaires fournis par le constructeur.

Cette installation peut inclure :

• des pilotes ;
• des services ;
• des programmes d’assistance ;
• des exécutables ;
• des « co-installers » utilisés par certains fabricants.

Le problème est que cette procédure s’exécute avec les privilèges NT AUTHORITY\SYSTEM, c’est-à-dire avec des droits supérieurs à ceux d’un administrateur classique, sans nécessairement afficher de demande UAC.

Les chercheurs se sont donc demandé ce qui se passerait s’il était possible de contrôler précisément l’identité du périphérique que Windows pense avoir détecté.

Un faux périphérique USB peut tromper Windows

Pour leurs démonstrations, les chercheurs ont utilisé le framework FaceDancer associé à du matériel comme Cynthion et GreatFET.

FaceDancer permet d’émuler un périphérique USB et de définir artificiellement ses caractéristiques : identifiant matériel, classe de périphérique, interfaces ou encore points de terminaison.

Du point de vue de Windows, le périphérique émulé ressemble alors à un véritable appareil connecté au port USB. Le système tente donc de rechercher le pilote et les logiciels associés comme s’il s’agissait du matériel original.

Les chercheurs peuvent même modifier l’identité du périphérique en cours d’attaque, en le faisant disparaître puis réapparaître comme un autre matériel.

Cette possibilité leur permet de chaîner plusieurs composants vulnérables provenant de fabricants différents.

Une attaque sans clic sur un Windows 11 entièrement à jour

La démonstration la plus impressionnante combine des composants liés à Sierra Wireless et Sony FeliCa.

Dans un premier temps, le faux périphérique se présente comme un appareil Sierra Wireless. Windows installe alors automatiquement le logiciel correspondant.

Les chercheurs exploitent une faiblesse de ce composant pour modifier les paramètres DNS de la machine.

Le périphérique change ensuite d’identité pour se faire passer pour un appareil Sony FeliCa.

Windows télécharge alors un autre logiciel constructeur. Celui-ci récupère certains fichiers via une connexion non chiffrée.

Comme les attaquants ont auparavant pris le contrôle de la résolution DNS, ils peuvent rediriger ces téléchargements vers leur propre serveur et faire déposer un fichier malveillant avec les privilèges SYSTEM.

Enfin, le périphérique se présente de nouveau comme l’appareil Sierra Wireless afin de provoquer le chargement du fichier malveillant.

Le résultat est l’ouverture d’un reverse shell avec les privilèges SYSTEM.

D’après les chercheurs, cette chaîne d’attaque fonctionne contre un Windows 11 entièrement mis à jour, sans utilisateur connecté, et nécessite environ cinq minutes.

Pas besoin d’une clé USB classique

Il ne faut pas imaginer cette attaque comme une simple clé USB malveillante du type BadUSB.

Les chercheurs ont besoin de pouvoir émuler précisément différents périphériques USB et leurs identifiants matériels.

Le matériel utilisé pour leurs démonstrations est néanmoins suffisamment compact pour être transporté facilement. Selon Alejandro Hernando, un Raspberry Pi configuré en mode USB Gadget pourrait théoriquement également être utilisé pour ce type d’attaque.

En revanche, le Flipper Zero ne permet pas actuellement d’exécuter directement cette technique, car son mode BadUSB est principalement destiné à l’émulation de périphériques HID comme un clavier et ne dispose pas du support nécessaire pour FaceDancer.

NoPlug & Pwn : l’attaque peut aussi fonctionner à distance via RDP

Encore plus surprenant, les chercheurs ont développé une variante baptisée NoPlug & Pwn, qui ne nécessite même plus de périphérique USB physiquement connecté au PC ciblé.

Cette technique exploite la redirection des périphériques USB via le Bureau à distance (RDP).

Cette fonction permet normalement à un périphérique branché sur le PC local d’être rendu disponible à l’intérieur d’une session distante.

Les chercheurs ont créé un client RDP capable d’envoyer directement de faux descripteurs USB.

Le serveur Windows distant croit alors qu’un véritable périphérique vient d’être connecté et déclenche le mécanisme Plug and Play habituel.

Dans leur démonstration, ils ont émulé une caméra Intel RealSense.

Windows Update récupère le package associé, qui contient un co-installer vulnérable à un détournement de DLL. Les chercheurs exploitent ensuite cette faiblesse pour obtenir les privilèges SYSTEM sur la machine distante.

Cette variante nécessite toutefois que la redirection USB via RDP soit activée. Elle pourrait notamment concerner certains environnements de bureaux virtuels où cette fonctionnalité est couramment utilisée.

Ce n’est pas une nouvelle idée, mais l’attaque va beaucoup plus loin

Le principe rappelle une vulnérabilité médiatisée en 2021 avec Razer Synapse.

À l’époque, le simple branchement d’une souris ou d’un clavier Razer pouvait pousser Windows à télécharger automatiquement l’installateur Synapse avec les privilèges SYSTEM.

Une faiblesse de cet installateur permettait alors de lancer PowerShell depuis l’interface d’installation et d’hériter des mêmes privilèges élevés.

Les chercheurs à l’origine de Plug and Pwn expliquent toutefois avoir adopté une approche plus générale.

Plutôt que de cibler uniquement la vulnérabilité d’un installateur particulier, ils se sont intéressés à toute la chaîne d’installation automatique des périphériques Windows.

Le problème devient alors beaucoup plus large : Windows peut automatiquement installer des composants de nombreux constructeurs différents, et il suffit qu’un de ces éléments comporte une faiblesse exploitable pour qu’il puisse entrer dans une chaîne d’attaque.

Pourquoi des pilotes signés peuvent-ils être dangereux ?

Un pilote ou un logiciel signé n’est pas nécessairement exempt de vulnérabilités.

La signature permet principalement de vérifier l’origine du fichier et de s’assurer qu’il n’a pas été modifié depuis sa publication.

Elle ne garantit pas que son code est parfaitement sécurisé.

Plug and Pwn exploite précisément cette différence : Windows fait confiance à des packages légitimes et signés, mais certains de leurs composants peuvent contenir des vulnérabilités anciennes ou des comportements dangereux.

Les attaquants ne cherchent donc pas nécessairement à faire installer un pilote malveillant inconnu.

Ils poussent Windows à installer des logiciels légitimes mais vulnérables, puis exploitent ces vulnérabilités pour obtenir davantage de privilèges.

A lire :

Désactiver les co-installers peut limiter certaines attaques

Une première mesure de protection consiste à désactiver l’exécution des co-installers lors de l’installation des périphériques.

Cela peut être réalisé avec la valeur de Registre :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Installer

puis en créant une valeur DWORD :

DisableCoInstallers = 1

D’après les chercheurs, cette configuration bloque certaines des chaînes d’attaque présentées, notamment celles exploitant Sony FeliCa ou Intel RealSense.

Cette mesure ne supprime toutefois pas complètement la surface d’attaque.

Windows continue notamment :

• d’énumérer les périphériques Plug and Play ;
• de rechercher les pilotes dans Windows Update ;
• d’interpréter les fichiers INF ;
• d’installer certains services déclarés par ces fichiers.

Les entreprises peuvent durcir davantage l’installation des périphériques

Sur les postes sensibles, les chercheurs recommandent de combiner plusieurs protections.

Les administrateurs peuvent notamment :

• désactiver les co-installers ;
• appliquer des restrictions d’installation des périphériques ;
• autoriser uniquement certains identifiants matériels ;
• désactiver la redirection Plug and Play dans les environnements RDP ou VDI lorsqu’elle n’est pas nécessaire.

Cette dernière protection est particulièrement importante contre la variante NoPlug & Pwn.

La stratégie RDP correspondante peut notamment être contrôlée à travers le paramètre lié à fDisablePNPRedir.

Tous les scénarios ne sont pas considérés comme de nouvelles vulnérabilités

Les chercheurs n’ont pas signalé chacune de leurs chaînes d’exploitation comme une nouvelle faille indépendante auprès des différents constructeurs.

La raison est importante : Plug and Pwn repose souvent sur la combinaison de plusieurs comportements légitimes et de vulnérabilités existantes.

Une fonctionnalité prise isolément n’est donc pas nécessairement vulnérable.

C’est l’enchaînement qui devient dangereux : faux périphérique → détection Plug and Play → téléchargement automatique → installation avec les droits SYSTEM → exploitation d’un composant vulnérable

Cette approche illustre parfaitement la notion de chaîne d’exploitation, où plusieurs faiblesses relativement limitées permettent ensemble d’obtenir un résultat beaucoup plus grave.

Une attaque surtout préoccupante pour les environnements sensibles

Pour un particulier, Plug and Pwn reste une attaque relativement sophistiquée.

La version physique nécessite qu’un attaquant puisse connecter un dispositif spécialisé au PC, tandis que la variante distante dépend de la présence d’un accès RDP et de la redirection des périphériques.

Le risque est donc surtout important dans les entreprises, les infrastructures sensibles, les postes partagés et les environnements de bureaux virtuels.

Mais ces recherches mettent en évidence un problème plus général : le simple fait de brancher un périphérique peut déclencher l’exécution automatique de composants tiers avec des privilèges extrêmement élevés.

Cette confiance accordée au processus d’installation des pilotes constitue une surface d’attaque difficile à éliminer complètement.

Conclusion

Plug and Pwn ne repose pas sur une unique faille spectaculaire de Windows, mais sur l’exploitation d’un mécanisme profondément intégré au système : l’installation automatique des périphériques.

En imitant des appareils légitimes, les chercheurs ont réussi à pousser Windows 11 à télécharger des packages signés de constructeurs, puis à combiner leurs faiblesses pour obtenir les privilèges SYSTEM.

Le fait qu’une variante puisse également fonctionner à travers RDP sans connecter physiquement de périphérique montre que le problème dépasse largement la simple menace des clés USB inconnues.

Ces travaux rappellent surtout qu’un pilote signé ou un logiciel distribué par Windows Update n’est pas nécessairement sans risque. La sécurité dépend également de la qualité des composants fournis par les fabricants et de la façon dont Windows les installe avec des privilèges élevés.

Pour les environnements sensibles, restreindre l’installation des périphériques, désactiver les co-installers inutiles et limiter la redirection USB via RDP constituent donc des mesures de durcissement pertinentes.

L’article Plug and Pwn : de faux périphériques USB peuvent donner les droits SYSTEM sous Windows est apparu en premier sur malekal.com.

Microsoft a introduit dans Windows 11 un nouveau profil à faible latence, appelé Low Latency Profile (LLP) en anglais, afin d’améliorer la réactivité du système lors de certaines interactions courtes.

Son principe est de permettre au processeur d’augmenter rapidement ses performances lorsqu’une action nécessite une réponse immédiate, par exemple lors de l’ouverture du menu Démarrer, de la recherche Windows, de certains éléments de l’interface ou du lancement d’applications, puis de revenir à un fonctionnement normal une fois l’opération terminée.

L’objectif n’est donc pas de maintenir le CPU à pleine puissance en permanence, mais de rendre Windows 11 plus réactif au bon moment, tout en limitant l’impact sur la consommation, la batterie et les températures.

Dans ce guide, découvrez comment fonctionne le profil à faible latence de Windows 11, dans quelles situations il intervient, quels gains de réactivité attendre, son impact sur les jeux et l’autonomie, comment savoir s’il est actif et quelles solutions appliquer en cas de problème.

Qu’est-ce que le profil à faible latence de Windows 11 ?

Le profil à faible latence, appelé Low Latency Profile (LLP) en anglais, est une optimisation introduite dans Windows 11 pour améliorer la réactivité du système lors de certaines interactions courtes. Son déploiement a commencé avec les mises à jour de Windows 11 de juin 2026.

Son principe est assez simple : lorsqu’une action nécessitant une réponse rapide est détectée, Windows peut augmenter temporairement la fréquence du processeur afin d’exécuter cette tâche plus rapidement.

Le profil peut notamment intervenir lors de certaines actions comme :

• L’ouverture du menu Démarrer.
• L’utilisation de la recherche Windows.
• L’affichage du Centre de notifications/actions.
• L’ouverture de certains menus et éléments de l’interface.
• Le lancement d’applications, selon les améliorations progressivement déployées par Microsoft.

Comme l’illustre le schéma ci-dessus, cette augmentation des performances est ponctuelle. Le processeur peut fonctionner à une fréquence élevée pendant environ une à trois secondes, puis Windows revient à son fonctionnement normal lorsque le besoin de réactivité disparaît.

Le but n’est donc pas d’augmenter en permanence les performances du processeur, mais de rendre Windows plus réactif au moment précis où l’utilisateur effectue une action.

Un mécanisme progressivement étendu aux applications

Les premières améliorations ont surtout concerné les éléments essentiels de l’interface de Windows, comme Démarrer, la recherche et le Centre de notifications/actions. Microsoft étend également ce mécanisme au lancement des applications, afin qu’elles puissent profiter de la même accélération ponctuelle du processeur.

Le profil à faible latence n’est donc pas réservé aux applications Microsoft. Les informations disponibles indiquent que les applications Windows traditionnelles tierces peuvent également en bénéficier lors de leur lancement.
C’est notamment le cas depuis le KB5121003.

En revanche, il ne faut pas le considérer comme un mode destiné aux charges longues et intensives telles qu’un rendu vidéo, un benchmark ou un jeu fonctionnant pendant plusieurs heures. Son intérêt se situe principalement dans les courtes périodes où Windows doit répondre immédiatement à une action de l’utilisateur.

C’est cette succession de petites accélérations qui doit rendre l’utilisation quotidienne de Windows 11 plus fluide, sans maintenir inutilement le processeur à une fréquence élevée lorsque le PC est au repos ou qu’aucune interaction ne le nécessite.

Quels gains de réactivité peut-on attendre ?

Le profil à faible latence vise principalement à réduire le délai entre une action de l’utilisateur et la réponse de Windows 11. Il ne rend donc pas le processeur intrinsèquement plus rapide : il permet surtout à Windows d’exploiter plus rapidement les performances disponibles lors de courtes interactions.

Les premiers tests rapportés avec cette fonctionnalité montrent des gains pouvant atteindre :

• Jusqu’à 40 % de réduction du temps de lancement de certaines applications.
• Jusqu’à 70 % d’amélioration sur certaines interactions avec l’interface de Windows, notamment l’ouverture du menu Démarrer ou de menus contextuels.

Ces chiffres correspondent toutefois aux meilleurs résultats observés et ne signifient pas que Windows 11 devient globalement 40 ou 70 % plus rapide. Le gain dépend du processeur, de la configuration du PC, de l’application utilisée et surtout du temps que le CPU représentait initialement dans l’opération.

Des gains surtout visibles sur les PC les moins réactifs

Sur un PC récent et puissant, une application ou le menu Démarrer peuvent déjà s’ouvrir très rapidement. Gagner quelques dizaines de millisecondes peut alors être difficile à percevoir.

L’amélioration peut être plus sensible sur un ordinateur portable ou un PC moins performant, notamment lorsque le processeur fonctionne habituellement à une fréquence réduite pour limiter sa consommation. Le profil à faible latence lui permet alors d’augmenter plus rapidement sa fréquence lorsqu’une interaction utilisateur le nécessite.

L’objectif est donc avant tout d’améliorer la sensation de réactivité : menus qui apparaissent plus rapidement, applications qui commencent leur lancement plus tôt et interface qui répond plus immédiatement aux actions de l’utilisateur.

Le profil à faible latence améliore-t-il les performances dans les jeux ?

Malgré son nom, le profil à faible latence de Windows 11 n’est pas une optimisation spécifiquement destinée aux jeux vidéo. Son objectif principal est d’améliorer la réactivité de Windows lors d’actions courtes, comme l’ouverture d’une application, du menu Démarrer, de la recherche ou de certains éléments de l’interface.

Le mécanisme augmente temporairement les performances du processeur lorsqu’une tâche sensible à la latence est détectée, puis revient à un fonctionnement normal après quelques secondes. Il n’est donc pas conçu pour maintenir des fréquences CPU plus élevées pendant toute une session de jeu. Les informations disponibles actuellement n’indiquent pas de gain direct attendu sur les FPS.

Ne pas confondre avec la latence dans les jeux

Le terme « faible latence » peut prêter à confusion. Dans le cas du profil à faible latence, il s’agit principalement de réduire le temps de réponse de Windows pour certaines interactions.

Ce n’est pas la même chose que la latence d’entrée (input lag) d’un jeu, qui correspond au délai entre une action effectuée avec la souris, le clavier ou la manette et son résultat visible à l’écran.

Le profil à faible latence ne doit donc pas être confondu avec :

• NVIDIA Reflex et les technologies équivalentes destinées à réduire la latence de la chaîne de rendu.
• Les réglages de faible latence proposés par certains pilotes graphiques.
• Le Mode Jeu de Windows.
• Les optimisations graphiques de Windows 11.
• La fréquence de rafraîchissement variable (VRR).
• Le ping ou la latence d’une connexion réseau.

Windows 11 dispose d’ailleurs d’une fonction distincte appelée Optimisations pour les jeux fenêtrés, qui peut réduire la latence des images de certains jeux DirectX 10 et DirectX 11 fonctionnant en mode fenêtré ou sans bordure.

Le guide complet :

Un bénéfice possible autour du lancement du jeu

Le profil à faible latence peut néanmoins améliorer la réactivité avant le jeu. Le lancement du jeu ou de son launcher peut bénéficier de l’accélération temporaire du processeur, comme n’importe quelle autre application compatible avec ce mécanisme.

Une fois le jeu lancé et le CPU/GPU sollicités en continu, le profil à faible latence n’a plus le même objectif. Il ne faut donc pas attendre de cette fonction une augmentation significative des FPS, une réduction du ping ou une diminution directe de l’input lag.

Pour les joueurs, le profil à faible latence doit ainsi être considéré avant tout comme une amélioration de la réactivité générale de Windows 11, et non comme une nouvelle optimisation des performances gaming.

Quel impact sur la consommation, la batterie et les températures ?

Le profil à faible latence augmente temporairement les performances du processeur lorsqu’une interaction nécessitant une réponse rapide est détectée. Cette montée en fréquence entraîne logiquement une augmentation ponctuelle de la consommation électrique et de la chaleur produite par le CPU.

Toutefois, contrairement à un mode de performances élevées utilisé en permanence, cette sollicitation ne dure généralement que quelques secondes. Une fois l’opération terminée, le processeur peut revenir à un état de fonctionnement plus économe. Le principe est justement d’obtenir davantage de performances au moment où elles sont utiles sans maintenir continuellement le CPU à une fréquence élevée.

Quel impact sur l’autonomie d’un PC portable ?

Sur batterie, ces accélérations peuvent entraîner une légère augmentation de la consommation. L’impact réel sur l’autonomie dépend toutefois de la fréquence à laquelle le mécanisme est sollicité, du processeur et de la gestion énergétique définie par le constructeur du PC.

Windows dispose par ailleurs de paramètres de gestion du processeur qui tiennent compte à la fois des besoins de performances et de l’efficacité énergétique lors des opérations sensibles à la latence. Microsoft documente notamment LatencyHintEpp, qui définit la préférence entre performances et économie d’énergie lorsqu’un indicateur de sensibilité à la latence est détecté.

Le profil à faible latence ne doit donc pas être assimilé à un mode qui maintient constamment le processeur à sa fréquence maximale.

Le tutoriel :

Les températures vont-elles augmenter ?

Une augmentation momentanée de la fréquence CPU peut également provoquer une petite hausse ponctuelle de la température, notamment lors du lancement d’une application.

En pratique, ces phases étant très courtes, elles ne sont pas comparables à une charge prolongée comme un jeu, un encodage vidéo ou un stress test. Le système de refroidissement et les mécanismes de gestion thermique du PC continuent par ailleurs de limiter les performances lorsque cela est nécessaire pour maintenir le matériel dans ses conditions normales de fonctionnement.

Il ne faut donc pas s’attendre à une hausse importante et permanente des températures simplement parce que le profil à faible latence est utilisé. Son principe repose justement sur des accélérations brèves du processeur, suivies d’un retour à son fonctionnement normal.

Les guides complets :

Profil à faible latence ou mode Performances élevées : quelles différences ?

Le profil à faible latence et le mode Performances élevées agissent tous les deux sur la gestion des performances du processeur, mais leur fonctionnement et leur objectif sont différents.

Le profil à faible latence est un profil de gestion du processeur activé automatiquement dans certaines situations, notamment pendant le démarrage et le lancement des applications. Windows dispose de plusieurs profils de ce type — par défaut, faible consommation, mode jeu, faible latence, etc. — afin d’adapter la gestion du CPU au scénario en cours.

Le mode Performances élevées, en revanche, est un mode d’alimentation général. Il modifie durablement la politique énergétique de Windows afin de privilégier davantage les performances au détriment de la consommation électrique.

Profil à faible latence	Performances élevées
Activé automatiquement par Windows	Sélectionné comme mode ou plan d’alimentation
Utilisé pour certaines tâches sensibles à la latence	S’applique de manière beaucoup plus générale au fonctionnement du PC
Agit pendant de courtes périodes	Reste actif tant que le mode d’alimentation est utilisé
Cherche à améliorer la réactivité	Privilégie globalement les performances
Conserve une logique d’économie d’énergie hors des périodes concernées	Peut augmenter davantage la consommation énergétique
Ne constitue pas un nouveau mode d’alimentation visible	Fait partie des réglages d’alimentation de Windows

A lire :

Une accélération ciblée plutôt qu’un mode permanent

Lorsqu’un indicateur de sensibilité à la latence est détecté, Windows peut demander au moteur de gestion des performances du processeur d’augmenter temporairement son niveau de performances. Il peut également adapter la préférence entre performances et efficacité énergétique ou maintenir davantage de cœurs disponibles selon la configuration.

Le principe peut être résumé ainsi :

Profil à faible latence : Interaction → besoin de réactivité → performances CPU augmentées → tâche terminée → retour au fonctionnement normal.

Performances élevées : Mode activé → politique énergétique orientée performances → fonctionnement maintenu jusqu’au changement de mode.

Cette différence permet au profil à faible latence d’améliorer la sensation de réactivité sans imposer en permanence une politique énergétique agressive.

Les deux mécanismes peuvent coexister

Il ne faut donc pas considérer le profil à faible latence comme le remplaçant du mode Performances élevées. Ils interviennent à des niveaux différents de la gestion énergétique de Windows.

Le profil à faible latence répond à un besoin ponctuel de réactivité, tandis que le mode Performances élevées convient davantage lorsqu’on souhaite privilégier globalement les performances du PC pendant une période prolongée.

Pour la plupart des utilisateurs, il n’est donc pas nécessaire d’activer le mode Performances élevées simplement pour profiter du profil à faible latence : Windows gère automatiquement ce dernier lorsqu’un scénario compatible est détecté.

Comment obtenir le profil à faible latence sur Windows 11 ?

Le profil à faible latence est distribué automatiquement par Windows Update. Il n’existe donc pas de programme particulier à télécharger ni de nouveau mode d’alimentation à installer manuellement.

Microsoft a commencé son déploiement sur Windows 11 24H2 et 25H2 avec les mises à jour de 2026. La mise à jour cumulative KB5094126 du 9 juin 2026, pour les builds 26100.8655 et 26200.8655, concerne justement Windows 11 24H2 et 25H2.
Le Patch Tuesday d’Août 2026 (KB5121003) étend ce mécanisme aux applications).

Pour disposer des dernières améliorations :

• Ouvrez les Paramètres de Windows 11.
• Accédez à Windows Update.
• Cliquez sur Rechercher des mises à jour.
• Installez les mises à jour disponibles.
• Redémarrez le PC lorsque Windows le demande.

Vous pouvez vérifier votre version de Windows avec la commande :

winver

Le tutoriel :

Un déploiement progressif

Installer la dernière mise à jour de Windows 11 ne signifie pas nécessairement que le profil à faible latence sera immédiatement actif sur votre PC.

Microsoft utilise un déploiement progressif (Controlled Feature Rollout). Une fonctionnalité peut donc être présente dans les fichiers de Windows mais rester désactivée jusqu’à ce que Microsoft l’active sur votre appareil. Le déploiement de LLP avec les améliorations de lancement des applications a justement été présenté comme progressif.

Deux PC équipés de la même version et de la même mise à jour de Windows 11 peuvent donc temporairement ne pas bénéficier de la fonctionnalité au même moment.

Il n’y a normalement aucune notification indiquant que le profil à faible latence vient d’être activé, puisqu’il s’agit d’une optimisation transparente de Windows.

Faut-il forcer son activation ?

Des outils comme ViVeTool permettent techniquement de modifier certains identifiants de fonctionnalités internes de Windows et ont été utilisés pour forcer l’activation de LLP avant la fin de son déploiement.

Je déconseille toutefois cette méthode pour un PC utilisé normalement. Si Microsoft effectue un déploiement progressif, c’est notamment pour pouvoir surveiller le comportement de la fonctionnalité sur différentes configurations avant de l’étendre à davantage de machines.

Le plus simple est donc de maintenir Windows 11 à jour et de laisser Windows Update activer automatiquement le profil à faible latence lorsqu’il devient disponible pour votre PC.

La difficulté est alors de savoir si cette optimisation est déjà active, puisqu’aucun interrupteur n’est affiché dans les Paramètres. La section suivante explique comment tenter de le vérifier.

Comment savoir si le profil à faible latence est actif ?

Le profil à faible latence fonctionne de manière transparente en arrière-plan. Windows 11 n’affiche actuellement ni interrupteur dans les Paramètres, ni notification, ni indicateur permettant de confirmer directement son activation.

La méthode la plus simple consiste donc à observer le comportement de la fréquence du processeur lorsqu’une action susceptible de déclencher le profil est effectuée.

Vérifier avec le Gestionnaire des tâches

Vous pouvez effectuer un premier test avec le Gestionnaire des tâches :

• Ouvrez le gestionnaire de tâches par un clic droit sur le menu Démarrer ou utilisez le raccourci clavier + X
• Puis Gestionnaire des tâches. Vous pouvez aussi utiliser le raccourci clavier CTRL+MAJ+ESC[/su_rclavier
• Cliquez sur Performances.
• Sélectionnez Processeur.
• Laissez le PC au repos quelques instants afin que la fréquence CPU redescende.
• Ouvrez ensuite plusieurs fois le menu Démarrer, la recherche Windows ou le Centre de notifications/actions.
• Observez la valeur Vitesse du processeur.

Lorsque le profil à faible latence intervient, le processeur peut effectuer une montée très rapide en fréquence, puis revenir presque immédiatement à une fréquence plus faible lorsque l’interaction est terminée.

Le Gestionnaire des tâches n’est toutefois pas idéal pour observer un phénomène aussi court. Son taux de rafraîchissement peut faire manquer une augmentation de fréquence qui ne dure qu’une à trois secondes.

Vérifier plus précisément avec HWiNFO

Pour une observation plus précise, vous pouvez utiliser HWiNFO et ses capteurs.

Laissez d’abord Windows au repos pendant une ou deux minutes, puis surveillez les fréquences des cœurs du processeur pendant que vous ouvrez successivement :

• Le menu Démarrer.
• La recherche Windows.
• Le Centre de notifications/actions.
• Éventuellement une application lorsque le déploiement du profil pour le lancement des applications est actif sur votre PC.

Vous devez rechercher une augmentation brève et nette des fréquences CPU au moment exact de l’interaction, suivie d’un retour rapide vers les fréquences de repos. C’est le comportement caractéristique recherché pour vérifier le fonctionnement du profil à faible latence.

Le guide complet :

L’absence de pic ne prouve pas que le profil est désactivé

Cette méthode reste une vérification indirecte. Une absence de variation évidente ne permet pas à elle seule d’affirmer que le profil à faible latence est désactivé.

Sur un PC configuré en mode Performances élevées, par exemple, le processeur peut déjà fonctionner à une fréquence importante. Le changement sera alors beaucoup moins visible. De même, les mécanismes de boost, le type de processeur et la gestion énergétique du constructeur influencent fortement les fréquences observées.

Enfin, Microsoft déploie progressivement certaines améliorations du profil. Deux PC disposant de la même version de Windows 11 peuvent donc temporairement présenter un comportement différent.

En pratique, si Windows 11 est à jour et que vous observez des pics courts de fréquence CPU précisément lors de l’ouverture des éléments de l’interface concernés, c’est un bon indice que le profil à faible latence fonctionne sur votre PC.

Peut-on activer ou désactiver le profil à faible latence ?

Le profil à faible latence est conçu comme une fonction automatique de Windows 11. Microsoft ne propose actuellement aucun interrupteur dans les Paramètres permettant de l’activer ou de le désactiver manuellement.

Une fois la fonctionnalité déployée sur votre PC par Windows Update, Windows décide automatiquement quand utiliser ce profil selon les opérations sensibles à la latence. Les paramètres sous-jacents de gestion du processeur, comme PerfLatencyHint, existent bien dans Windows, mais ils sont masqués et destinés à la gestion interne de l’alimentation, plutôt qu’à une configuration classique par l’utilisateur.

Il n’est donc normalement pas nécessaire de modifier le Registre, les options d’alimentation ou les paramètres du processeur pour profiter du profil à faible latence.

Forcer l’activation ou la désactivation avec ViVeTool

Pendant le déploiement progressif de la fonctionnalité, il est toutefois possible de modifier son état avec ViVeTool, un outil tiers permettant de gérer certaines fonctionnalités expérimentales ou progressivement déployées de Windows 11.

L’identifiant actuellement associé au profil à faible latence est :

58989092

Pour forcer son activation :

vivetool /enable /id:58989092

• Puis redémarrez Windows.

Pour le désactiver :

vivetool /disable /id:58989092

Redémarrez également le PC après la modification. Cet identifiant et ces commandes sont actuellement utilisés pour le déploiement 2026 du profil à faible latence.

Pour plus de détails, suivez ce tutoriel :

Faut-il utiliser ViVeTool ?

Dans la majorité des cas, non. Il est préférable de laisser Windows Update gérer automatiquement l’activation du profil à faible latence.

Un déploiement progressif permet notamment à Microsoft de contrôler l’arrivée d’une fonctionnalité sur différentes configurations. Forcer son activation peut donc exposer votre PC à un comportement qui n’a pas encore été généralisé à votre configuration.

ViVeTool peut toutefois être utile pour effectuer des tests ou revenir temporairement en arrière lorsqu’un problème apparaît précisément après l’activation du profil. Des utilisateurs ont par exemple signalé avoir désactivé l’identifiant 58989092 pour vérifier si LLP était à l’origine d’un problème, mais ces témoignages ne permettent pas de conclure à un problème généralisé de la fonctionnalité.

Enfin, les identifiants internes utilisés par Windows peuvent évoluer au fil des mises à jour. Avant d’utiliser ViVeTool, vérifiez donc que l’identifiant indiqué correspond toujours à votre version actuelle de Windows 11.

Pour une utilisation normale, la meilleure solution reste de maintenir Windows 11 à jour et de laisser le profil à faible latence fonctionner automatiquement en arrière-plan.

Que faire en cas de problème avec le profil à faible latence ?

Le profil à faible latence fonctionne normalement de manière transparente et ne nécessite aucune intervention. Toutefois, si vous constatez des ralentissements, une fréquence CPU anormalement élevée, une consommation excessive ou un comportement inhabituel apparu après une mise à jour de Windows 11, vous pouvez effectuer quelques vérifications.

À ce jour, Microsoft ne signale pas dans les problèmes connus de la mise à jour KB5094126 de dysfonctionnement généralisé directement attribué au profil à faible latence. Des utilisateurs ont néanmoins rapporté certains comportements anormaux après son déploiement ; ces témoignages ne suffisent pas à établir que LLP en est systématiquement responsable.

Commencez par :

• Installer les dernières mises à jour de Windows 11, car les mises à jour cumulatives suivantes peuvent corriger des problèmes apparus dans les versions précédentes.
• Mettre à jour les pilotes du chipset et du processeur depuis le fabricant du PC ou de la carte mère.
• Vérifier si une mise à jour du BIOS/UEFI est disponible.
• Revenir temporairement au mode d’alimentation Équilibré si vous utilisez Performances élevées ou un profil constructeur particulièrement agressif.
• Surveiller la charge, les fréquences et les températures CPU avec le Gestionnaire des tâches ou HWiNFO afin de vérifier si le processeur revient correctement à un état de faible consommation après une interaction.

Le comportement attendu est une montée en fréquence très courte, généralement de quelques secondes, suivie d’un retour à un fonctionnement normal. Un processeur qui reste continuellement à une fréquence élevée ne correspond donc pas au principe normal du profil à faible latence.

Désactiver temporairement le profil pour effectuer un test

Si le problème est apparu précisément après l’arrivée du profil à faible latence, une méthode de diagnostic consiste à le désactiver temporairement, puis à comparer le comportement du PC.

Avec ViVeTool, lorsque l’identifiant 58989092 correspond bien à la fonctionnalité sur votre version de Windows, vous pouvez utiliser :

vivetool /disable /id:58989092

Redémarrez ensuite Windows et vérifiez si le problème disparaît. Des utilisateurs ont utilisé cette méthode comme test après KB5094126, mais il s’agit d’un contournement non officiel et non d’un correctif recommandé par Microsoft.

Si le problème persiste avec le profil désactivé, il est probablement nécessaire de rechercher une autre cause : pilote, mise à jour Windows, logiciel tiers, gestion de l’alimentation ou problème matériel.

Si, au contraire, le problème disparaît systématiquement lorsque le profil est désactivé et réapparaît lorsqu’il est réactivé, cette comparaison constitue un indice beaucoup plus solide d’un lien avec la fonctionnalité. Dans ce cas, vous pouvez laisser le profil désactivé temporairement et attendre une prochaine mise à jour de Windows 11.

Conclusion

Le profil à faible latence de Windows 11 est avant tout une optimisation de la réactivité plutôt qu’un nouveau mode destiné à augmenter les performances générales du PC. Windows l’utilise ponctuellement lorsqu’une action nécessite une réponse rapide, puis laisse le processeur revenir à son fonctionnement habituel une fois l’opération terminée.

Son intérêt est donc surtout perceptible lors du lancement d’applications et de certaines interactions avec l’interface de Windows 11. Il ne faut pas en attendre une augmentation importante des FPS, une réduction du ping ou une accélération des tâches longues et intensives.

Pour la plupart des utilisateurs, il n’y a d’ailleurs rien à configurer : le profil est distribué progressivement par Windows Update et fonctionne automatiquement. Les utilisateurs avancés peuvent néanmoins surveiller les variations de fréquence du processeur avec le Gestionnaire des tâches ou HWiNFO, voire utiliser ViVeTool pour effectuer des tests lorsque cela est nécessaire.

Vérifier le comportement et les performances de son PC

Si vous souhaitez aller plus loin et vérifier comment votre processeur et les autres composants se comportent lorsqu’ils sont réellement sollicités, vous pouvez utiliser StressTest Malekal.

Le service effectue différents scénarios de charge sous Windows 11/10 et analyse notamment les fréquences CPU/GPU, les températures, le refroidissement, les performances, les limitations thermiques et les éventuelles erreurs matérielles WHEA.

Cela permet par exemple de déterminer si le processeur maintient correctement ses fréquences sous charge, si les températures restent maîtrisées ou si une limitation thermique ou énergétique réduit les performances du PC.

Le guide d’utilisation :

L’article Profil à faible latence de Windows 11 : fonctionnement et performances est apparu en premier sur malekal.com.

Pour analyser votre PC sous Windows 11 ou Windows 10, le système et sa configuration matérielle, vous pouvez utiliser AnalysePC. Ce service permet de générer un diagnostic complet afin de détecter les problèmes liés au système, au démarrage, aux pilotes, aux services, aux disques ou encore aux performances.
AnalysePC : analyser son PC Windows et détecter les problèmes automatiquement.

Mais certaines anomalies n’apparaissent que lorsque le matériel est fortement sollicité. Un processeur peut fonctionner normalement au repos puis surchauffer ou réduire ses fréquences sous charge. De même, une carte graphique peut devenir instable, le refroidissement peut montrer ses limites ou des erreurs matérielles peuvent apparaître pendant un effort prolongé.

C’est pour compléter ce diagnostic que StressTest Malekal permet de vérifier la santé et le comportement d’un PC sous Windows 11 ou Windows 10 lorsqu’il est soumis à une forte charge. Les tests sont exécutés avec Malekal Optimisation Center (MOC), qui sollicite les différents composants et collecte leurs mesures. StressTest Malekal analyse ensuite les résultats afin de présenter les températures, fréquences, performances, graphiques, scores et éventuelles anomalies détectées.

Dans ce guide, découvrez comment utiliser StressTest Malekal sous Windows 11 et Windows 10 et interpréter les résultats concernant le CPU, le GPU, le refroidissement, la mémoire RAM, le stockage, le thermal throttling et les erreurs WHEA.

Qu’est-ce que StressTest Malekal ?

StressTest Malekal est un service gratuit qui permet de tester le comportement, les performances et la stabilité du matériel de votre PC en Windows 11/10 lorsqu’il est soumis à différentes charges de travail.

Contrairement à un simple benchmark qui fournit principalement un score de performances, StressTest Malekal cherche à déterminer comment les composants se comportent pendant l’effort. Le service analyse notamment l’évolution de la charge, des températures et des fréquences afin de détecter une surchauffe, une baisse anormale des performances ou un problème de stabilité.

Le test s’appuie sur Malekal Optimisation Center (MOC) pour solliciter et collecter les mesures du PC. Une fois les tests terminés, les données sont envoyées vers StressTest Malekal afin de générer un rapport détaillé et plus facile à interpréter.

L’analyse porte notamment sur :

Élément testé	Ce que StressTest Malekal vérifie
Processeur (CPU)	Charge, fréquences, températures et maintien des performances pendant l’effort
Carte graphique (GPU)	Charge GPU, températures, fréquences et comportement sous forte sollicitation
Mémoire RAM	Performances mémoire et débits obtenus pendant le benchmark
SSD / stockage	Performances du périphérique de stockage pendant les tests
Refroidissement	Montée en température, températures maximales et comportement lors de la récupération
Thermal throttling	Recherche d’une réduction des fréquences provoquée notamment par une température trop élevée
Stabilité	Recherche d’anomalies apparaissant pendant les différentes phases de charge
Erreurs WHEA	Détection d’erreurs matérielles signalées par Windows pendant les tests

StressTest Malekal ne se contente donc pas de répondre à la question « mon PC est-il rapide ? ». L’objectif est également de déterminer s’il maintient correctement ses performances sous charge, si son refroidissement est suffisant et si des anomalies apparaissent lorsque le CPU, le GPU ou les autres composants sont sollicités.

L’intérêt est surtout de croiser plusieurs mesures. Une température élevée n’est par exemple pas nécessairement problématique si le processeur conserve ses fréquences et reste sous ses limites thermiques. À l’inverse, une baisse importante des fréquences lorsque la température augmente peut révéler une limitation thermique ou énergétique.

Il peut notamment être utile après le montage d’un nouveau PC, une modification du refroidissement, un changement de composant ou lorsqu’un ordinateur présente des plantages, des baisses de performances, des températures élevées ou une instabilité sous forte charge.

Pour en savoir plus sur le fonctionnement général des stress tests et les autres outils disponibles :

Pour tout comprendre, lisez :

Comment tester son PC avec StressTest Malekal

Pour utiliser StressTest Malekal, les tests sont exécutés directement sur votre ordinateur avec Malekal Optimisation Center (MOC). Le logiciel sollicite successivement les différents composants du PC, collecte les mesures nécessaires puis génère un rapport qui peut être envoyé vers StressTest Malekal pour être analysé.

Avant de commencer, fermez de préférence les applications gourmandes et enregistrez vos documents ouverts. Pendant le test, le processeur et la carte graphique peuvent être fortement sollicités et les ventilateurs peuvent accélérer : ce comportement est normal.

Pour tester votre PC :

• Téléchargez Malekal Optimisation Center (MOC) depuis ce lien :
• Décompressez l’utilitaire dans un répertoire de votre choix
• Fermez toutes les applications gourmandes suceptibles de fausser le stress test (navigateur internet, etc)
• Faites un clic droit sur Lancer-MOC puis exécuter en tant qu’administrateur
• Choisissez entre les options suivantes :
  • 3 Stress Test Court
  • 4 Stress Test Long

• Laissez le test se dérouler jusqu’à son terme sans utiliser intensivement l’ordinateur.
• MOC exécute successivement les différentes phases de test et collecte notamment la charge, les températures et les fréquences du CPU et du GPU.
• Les tests de performances de la mémoire RAM et du stockage sont également exécutés.
• À la fin du test, MOC génère le rapport contenant les mesures collectées.
• Envoyez le rapport vers AnalysePC lorsque le logiciel vous le propose.
• Une adresse Web est alors générée afin de consulter l’analyse complète de votre PC.

Pendant les tests, il est normal que les températures augmentent et que les ventilateurs tournent plus rapidement. Le but est précisément d’observer comment le refroidissement et les composants réagissent lorsque le PC est fortement sollicité.

StressTest Malekal ne s’intéresse pas uniquement aux valeurs obtenues à la fin du test. Les mesures sont collectées pendant les différentes phases afin d’étudier l’évolution des températures, des fréquences et de la charge. Cela permet notamment de détecter une perte de performances sous charge ou un éventuel thermal throttling.

Si une phase ne peut pas être exécutée ou s’interrompt prématurément, les autres tests peuvent continuer lorsque cela est possible. Le rapport indique alors quelles analyses ont été terminées, partielles, échouées ou ignorées, afin de ne pas présenter un résultat incomplet comme un test réussi.

Une fois le rapport envoyé, vous pouvez consulter les scores, températures, graphiques et problèmes détectés. Les sections suivantes expliquent comment lire ces résultats et déterminer si votre PC présente un comportement normal.

Comprendre le résumé du test

Une fois le rapport envoyé, StressTest Malekal affiche un résumé général du comportement de votre PC pendant les tests. Cette première vue permet de repérer rapidement les composants qui fonctionnent normalement et ceux qui nécessitent une analyse plus approfondie.

La navigation dans le rapport et le site est extrêmement simple. Vous pouvez asser d’une section du rapport à une autre grâce au menu de droite.

Le résumé regroupe les principaux résultats obtenus pendant les différentes phases : CPU, GPU, mémoire, stockage, températures et stabilité. Il indique également si certains tests n’ont pas pu être exécutés complètement.

L’objectif n’est pas seulement de fournir une note globale. StressTest Malekal croise plusieurs mesures afin de déterminer si les performances obtenues sont cohérentes avec les températures et le comportement du matériel sous charge.

Vous pouvez notamment retrouver :

• L’état général du test et les éventuelles anomalies détectées.
• Les résultats concernant le processeur et la carte graphique.
• Les températures relevées pendant les phases de charge.
• Les performances de la mémoire RAM et du stockage.
• Les éventuels signes de thermal throttling ou de limitation des performances.
• Les erreurs matérielles WHEA détectées pendant la période du test.
• Les tests qui ont été terminés, partiels, échoués ou ignorés.

Tout ceci se retrouve dans le début du rapport dans la partie Benchmars et comparaisons où vous trouverez un score de CPU, GPU, Mémoire pour évaluer les performances de votre PC.

Ne pas se fier uniquement aux scores

Un score élevé ne signifie pas nécessairement que le PC est parfaitement stable.

Par exemple, un processeur peut obtenir de bonnes performances tout en atteignant une température excessive, ou commencer à réduire ses fréquences lorsque la charge se prolonge. De même, un PC peut terminer le stress test sans planter mais générer des erreurs WHEA, ce qui peut révéler une instabilité matérielle.

À l’inverse, une température relativement élevée n’est pas forcément anormale si le composant reste dans ses limites de fonctionnement et maintient correctement ses fréquences et ses performances.

Toutefois, Stress test Malekal fournit une analyse de la santé matérielle observée durant la monté à charge de votre PC.
Le résumé doit donc être considéré comme un premier niveau de diagnostic. Lorsqu’une anomalie est signalée, consultez les analyses détaillées et les graphiques correspondants afin de comprendre ce qui s’est produit pendant la charge.

Les sections suivantes permettent notamment d’examiner plus précisément les températures et le refroidissement, le comportement du CPU et du GPU, les performances de la mémoire et du stockage ainsi que les éventuelles erreurs de stabilité.

Analyser les températures et le refroidissement

Les températures sont l’un des principaux indicateurs suivis par StressTest Malekal. Le rapport permet d’observer comment le CPU et le GPU montent en température pendant les différentes phases de charge, puis comment le système de refroidissement réagit lorsque la sollicitation diminue.

L’intérêt n’est donc pas uniquement de connaître la température maximale atteinte. StressTest met en relation températures, charge, fréquences et évolution dans le temps afin d’évaluer le comportement thermique du PC.

Ne pas regarder uniquement la température maximale

Un processeur ou un GPU moderne peut atteindre ponctuellement une température élevée sans présenter de problème particulier. La valeur maximale doit toujours être replacée dans le contexte du test.

Un comportement normal peut par exemple suivre cette évolution :

Charge ↑ → température ↑ → stabilisation → fréquences maintenues.

Le composant chauffe, mais le refroidissement parvient à atteindre un équilibre et les performances restent stables.

À l’inverse, une température qui atteint rapidement une valeur très élevée accompagnée d’une baisse des fréquences peut indiquer que le composant commence à limiter ses performances pour réduire la chaleur produite.

C’est pourquoi StressTest Malekal analyse les températures conjointement avec les autres mesures plutôt que de considérer qu’une valeur élevée signifie automatiquement une surchauffe.

Vérifier l’efficacité du refroidissement

Les graphiques permettent également d’observer si le système de refroidissement parvient à stabiliser les températures pendant une charge prolongée.

Une température qui augmente puis forme progressivement un plateau indique généralement que la chaleur produite et celle évacuée par le refroidissement atteignent un équilibre.

La phase de récupération est tout aussi intéressante. Lorsque la charge CPU ou GPU s’arrête, la température doit progressivement redescendre. Cela permet d’évaluer la capacité du ventirad, du watercooling ou du système de refroidissement d’un ordinateur portable à évacuer la chaleur accumulée pendant le test.

Si les températures restent excessivement élevées, augmentent continuellement ou redescendent difficilement après la charge, vérifiez notamment l’encrassement des radiateurs, la circulation de l’air, le montage du système de refroidissement et la pâte thermique.

Observer la ventilation

Lorsque les capteurs correspondants sont disponibles, le rapport peut également fournir des informations sur la vitesse des ventilateurs. Ces données apportent un contexte supplémentaire à l’évolution des températures.

Pendant une forte charge, il est normal que la ventilation augmente progressivement afin d’évacuer davantage de chaleur. À la fin de la charge, les ventilateurs doivent généralement ralentir à mesure que les températures diminuent.

L’absence d’une valeur de ventilation ne signifie toutefois pas qu’un ventilateur ne fonctionne pas : toutes les cartes mères, cartes graphiques et tous les PC portables n’exposent pas leurs capteurs de ventilation de la même manière à Windows.

L’analyse thermique de StressTest Malekal permet ainsi d’observer l’ensemble du comportement du refroidissement : montée en température, stabilisation sous charge, réaction de la ventilation et récupération après l’effort. Ces informations pourront ensuite être croisées avec les fréquences du CPU et du GPU pour déterminer si la chaleur entraîne réellement une perte de performances.

Analyser la charge et le comportement du processeur

La partie CPU de StressTest Malekal permet d’observer comment le processeur réagit lorsqu’il est sollicité. Le rapport ne se limite pas à la température ou à un score de performances : il analyse également la charge CPU, l’utilisation des différents cœurs logiques et l’évolution des fréquences pendant le test.

Ces informations permettent notamment de vérifier si le processeur est correctement sollicité et s’il parvient à maintenir ses performances lorsque la charge se prolonge.

Vérifier la charge CPU et l’utilisation des cœurs

Pendant une phase destinée à solliciter fortement le processeur, son utilisation doit augmenter de manière cohérente avec le scénario exécuté.

StressTest Malekal permet d’observer cette charge dans le temps afin de repérer, par exemple, une sollicitation qui s’interrompt brutalement ou un processeur qui n’atteint pas le niveau de charge attendu.

Il faut toutefois tenir compte du type de test exécuté. Tous les scénarios n’ont pas pour objectif d’utiliser 100 % du processeur : certains peuvent solliciter seulement une partie des ressources afin d’étudier le comportement du PC dans différentes conditions.

Il est donc préférable d’interpréter la charge en fonction de la phase ou du scénario en cours, plutôt que de considérer qu’un CPU qui n’est pas constamment à 100 % présente forcément un problème.

Processeur d’ordinateur : fonctionnement, caractéristiques et technologies essentielles

Comparer le comportement des cœurs logiques

Le rapport permet également d’examiner l’utilisation des différents cœurs logiques du processeur.

Cette vue est intéressante car une utilisation CPU globale peut masquer une répartition très différente de la charge entre les cœurs. Selon le scénario, certains peuvent être fortement sollicités tandis que d’autres restent beaucoup moins utilisés.

Cela permet notamment de distinguer :

• Une charge répartie sur l’ensemble des cœurs logiques.
• Une charge principalement concentrée sur quelques cœurs.
• Un scénario volontairement mono-cœur ou faiblement parallélisé.
• Une répartition inhabituelle de la charge qui mérite d’être rapprochée du scénario exécuté.

Une différence d’utilisation entre les cœurs n’est donc pas automatiquement anormale. Elle peut simplement refléter la manière dont le test ou l’application répartit son travail entre les threads.

Vérifier si les fréquences restent stables

StressTest Malekal suit également l’évolution des fréquences du processeur pendant les différentes phases.

Au début d’une forte charge, le CPU peut augmenter rapidement sa fréquence grâce à ses mécanismes de boost. Lorsque la température et la consommation augmentent, la fréquence peut ensuite se stabiliser à une valeur plus basse.

Un comportement de ce type est généralement normal :

Charge élevée → boost initial → température en hausse → fréquence qui se stabilise.

Il ne faut donc pas comparer en permanence la fréquence observée avec la fréquence maximale annoncée par le constructeur. Celle-ci correspond souvent à des conditions particulières et n’est pas nécessairement maintenue sur tous les cœurs pendant une charge prolongée.

Repérer une baisse anormale des fréquences et des performances

Les processeurs modernes ajustent continuellement leurs fréquences selon plusieurs paramètres :

• La charge appliquée.
• Le nombre de cœurs sollicités.
• La température.
• La consommation électrique.
• Les limites de puissance.
• Le profil énergétique et les paramètres du BIOS/UEFI.

L’analyse dans le temps permet enfin de détecter un processeur qui fournit de bonnes performances au début du test mais ne parvient pas à les maintenir lorsque la sollicitation se prolonge.

Par exemple :

Charge CPU élevée → température qui augmente → fréquence stable
indique généralement un comportement satisfaisant.

À l’inverse :

Charge CPU élevée → température proche de la limite → fréquence qui chute progressivement
peut révéler une limitation thermique.

StressTest Malekal permet ainsi de croiser charge globale, utilisation des cœurs logiques, fréquences et températures pour comprendre le comportement réel du processeur, plutôt que de tirer une conclusion à partir d’une seule valeur.

Analyser le comportement de la carte graphique

La partie GPU de StressTest Malekal permet d’observer comment la carte graphique réagit pendant les phases qui la sollicitent. Le rapport met en relation la charge GPU, les fréquences, les températures et les performances afin de vérifier si la carte graphique reste stable et maintient correctement son niveau de performances.

Cette analyse est particulièrement utile pour détecter un GPU qui fonctionne normalement au repos mais présente une anomalie lorsqu’il est fortement sollicité, par exemple pendant un jeu ou une application 3D.

Vérifier la charge et les fréquences du GPU

Pendant une phase de stress graphique, l’utilisation du GPU doit augmenter conformément au scénario exécuté.

StressTest Malekal permet de suivre cette charge dans le temps et de la comparer à l’évolution des fréquences et de la température.

Un comportement normal peut par exemple prendre cette forme :

Charge GPU élevée → température qui augmente → température qui se stabilise → fréquence relativement stable.

Comme pour le processeur, il ne faut toutefois pas attendre une fréquence parfaitement constante. Les cartes graphiques modernes ajustent continuellement leur fréquence selon la charge, la température, la consommation et les limites de puissance.

Vérifier si le GPU maintient ses performances

L’un des points importants est de déterminer si la carte graphique conserve ses performances lorsque la charge se prolonge.

Un GPU peut atteindre une fréquence élevée au début du test puis se stabiliser légèrement plus bas lorsque sa température augmente. Ce comportement est généralement normal.

En revanche, une diminution importante et progressive de la fréquence alors que la charge reste élevée mérite davantage d’attention, particulièrement si elle accompagne une température proche de la limite du GPU.

Les graphiques permettent alors de distinguer plus facilement une variation normale des mécanismes de boost d’une véritable limitation thermique ou énergétique.

Rechercher une instabilité de la carte graphique

Une instabilité du GPU peut également se manifester pendant le stress test par une interruption de la charge ou un comportement inhabituel des mesures.

Selon le problème rencontré, vous pouvez notamment observer :

• Une chute brutale de la charge GPU pendant la phase de test.
• Une baisse anormale des fréquences.
• Une température excessive.
• Une interruption ou un échec du test GPU.
• Une réinitialisation du pilote graphique.
• Un écran noir ou une perte temporaire de l’affichage.
• Des artefacts graphiques.
• Des erreurs matérielles remontées par Windows.

Ces symptômes ne signifient pas nécessairement que la carte graphique elle-même est défectueuse. Ils peuvent également provenir du pilote graphique, de l’alimentation, du refroidissement, de la mémoire vidéo ou d’un problème de stabilité du système.

L’intérêt de StressTest Malekal est donc de replacer ces anomalies dans le contexte du test : à quel moment elles apparaissent, quelle était la charge du GPU, quelle température avait été atteinte et comment les fréquences évoluaient à cet instant.

Le guide complet :

Comprendre les scénarios de charge

StressTest Malekal ne sollicite pas uniquement le CPU ou le GPU à leur maximum. Le rapport distingue plusieurs scénarios de charge afin d’observer comment le PC réagit dans différentes conditions d’utilisation.

Cette approche est importante, car un ordinateur peut se comporter correctement lorsqu’un seul composant est sollicité et montrer ses limites lorsque plusieurs ressources sont utilisées simultanément.

Comparer le comportement selon la charge

Les scénarios permettent notamment d’observer les variations de charge, températures, fréquences et consommation selon les différentes phases du test.

Ils permettent de répondre à plusieurs questions :

• Le processeur conserve-t-il ses fréquences lorsqu’il est fortement sollicité ?
• Le GPU reste-t-il stable pendant une charge graphique prolongée ?
• Les températures restent-elles maîtrisées lorsque plusieurs composants produisent de la chaleur ?
• Les performances diminuent-elles lorsqu’une charge devient plus importante ?
• Le refroidissement parvient-il à évacuer correctement la chaleur produite ?

Le rapport permet ainsi de comparer le comportement du matériel d’un scénario à l’autre plutôt que de se baser sur une seule mesure.

Pourquoi tester CPU et GPU simultanément ?

Une charge combinée CPU + GPU est particulièrement intéressante.

Lorsqu’ils fonctionnent simultanément, les deux composants augmentent la consommation électrique et la quantité de chaleur produite. Le système de refroidissement et l’alimentation sont alors davantage sollicités qu’avec un test CPU ou GPU effectué séparément.

Cette situation peut révéler un problème qui n’apparaît pas lors des tests individuels : températures plus élevées, fréquences qui diminuent, instabilité ou limitation de puissance.

C’est particulièrement pertinent sur un ordinateur portable, où le CPU et le GPU partagent souvent une partie des capacités de refroidissement et de l’enveloppe énergétique disponible. Une forte sollicitation du GPU peut alors modifier les performances que le processeur est capable de maintenir, et inversement.

Les différences entre scénarios ne sont pas forcément anormales

Il est normal que les fréquences, températures et performances varient selon le scénario exécuté.

Par exemple, un processeur peut maintenir une fréquence plus élevée lorsqu’il est sollicité seul que lorsque CPU et GPU travaillent simultanément. Cela ne signifie pas automatiquement qu’il existe un problème : le PC doit répartir ses ressources thermiques et énergétiques différemment.

L’intérêt de StressTest Malekal est justement de comparer ces situations et de rechercher un comportement réellement anormal : chute importante des performances, température excessive, throttling, interruption d’une phase ou apparition d’erreurs matérielles.

Les scénarios de charge permettent ainsi de vérifier non seulement la stabilité de chaque composant séparément, mais aussi le comportement du PC dans son ensemble lorsqu’il doit gérer plusieurs contraintes simultanément.

Vérifier l’alimentation, les tensions et la ventilation

StressTest Malekal peut également exploiter les capteurs matériels disponibles pour compléter l’analyse du comportement du PC. Selon la carte mère et les composants détectés, le rapport peut fournir des informations sur les tensions, la puissance électrique et la vitesse des ventilateurs.

Ces données sont particulièrement intéressantes pendant les scénarios de forte charge, notamment lorsque CPU et GPU sont sollicités simultanément.

Surveiller les tensions et la puissance

Lorsque les capteurs correspondants sont disponibles, StressTest Malekal permet d’observer l’évolution de certaines tensions et valeurs de puissance pendant le test.

L’objectif est surtout de rechercher des variations qui coïncident avec une anomalie : chute de fréquence, interruption du test, instabilité ou comportement inhabituel sous forte charge.

Les valeurs doivent toutefois être interprétées avec prudence. Les tensions remontées par logiciel proviennent des capteurs de la carte mère ou des composants et leur précision varie selon le matériel.

StressTest Malekal ne peut donc pas certifier à lui seul qu’une alimentation ATX est défectueuse ou parfaitement fonctionnelle. Un diagnostic précis de l’alimentation peut nécessiter des mesures ou des tests matériels spécifiques.

Observer le comportement des ventilateurs

Lorsque leur vitesse est accessible, le rapport permet également de suivre les ventilateurs du CPU, du GPU ou du boîtier.

Pendant une forte charge, un comportement attendu est généralement :

Température ↑ → ventilation ↑ → température qui se stabilise.

Puis, lors de la récupération :

Charge ↓ → température ↓ → ventilation ↓.

Ces informations permettent de vérifier si la ventilation réagit correctement à l’augmentation de la température.

Une température qui augmente fortement alors que la vitesse d’un ventilateur reste anormalement faible peut mériter une vérification. À l’inverse, des ventilateurs fonctionnant constamment à vitesse élevée peuvent simplement refléter une courbe de ventilation agressive définie dans le BIOS/UEFI ou le logiciel du constructeur.

Tous les capteurs ne sont pas toujours disponibles

L’absence d’une tension, d’une puissance ou d’une vitesse de ventilateur dans le rapport ne signifie pas que le composant ne fonctionne pas.

Les informations accessibles dépendent fortement :

• De la carte mère.
• Du processeur et de la carte graphique.
• Des contrôleurs de capteurs utilisés.
• Du BIOS/UEFI.
• Des informations que le matériel expose à Windows.

Il est donc normal qu’un rapport StressTest contienne davantage de données de capteurs sur certaines configurations que sur d’autres.

Ces mesures doivent surtout être croisées avec les scénarios de charge, les températures et les fréquences. Elles apportent un contexte supplémentaire pour comprendre pourquoi un PC chauffe, réduit ses performances ou devient instable lorsqu’il est fortement sollicité.

Comprendre les phases et graphiques du test

Les graphiques de StressTest Malekal permettent de suivre l’évolution du matériel pendant toute la durée du test. Leur principal intérêt est de replacer chaque mesure dans son contexte : une température, une fréquence ou une charge n’a pas la même signification selon la phase en cours.

Selon la configuration du PC et les tests disponibles, le rapport peut distinguer plusieurs phases :

• Repos / référence : comportement du PC avant la sollicitation.
• Charge CPU : sollicitation du processeur.
• Charge GPU : sollicitation de la carte graphique.
• Mémoire : test des performances de la RAM.
• Stockage : test des performances du SSD ou du disque.
• Récupération : retour à un fonctionnement normal après la charge.

Lire plusieurs courbes au même moment

Pour interpréter correctement un graphique, il faut surtout comparer les mesures au même instant.

Lors d’une phase CPU, par exemple, observez simultanément la charge, la température et la fréquence du processeur. Pour le GPU, appliquez la même méthode avec sa charge, sa température et ses fréquences.

Cette lecture permet notamment de repérer :

• Une fréquence qui chute alors que la charge reste élevée.
• Une température qui atteint sa limite pendant une phase précise.
• Une chute brutale de la charge CPU ou GPU.
• Une anomalie qui apparaît uniquement lors d’un scénario particulier.
• Le moment exact où les performances commencent à diminuer.

Les graphiques permettent donc de répondre à une question essentielle : que faisait le PC au moment où l’anomalie est apparue ?

Replacer les valeurs dans leur contexte

Une température maximale de 90 °C ou une baisse ponctuelle de fréquence, prise isolément, apporte peu d’informations. Le graphique permet de savoir à quel moment cette valeur a été atteinte, sous quelle charge et pendant quel scénario.

C’est cette corrélation entre les différentes courbes et les phases du test qui permet à StressTest Malekal de distinguer plus facilement un comportement normal d’une anomalie apparaissant sous charge.

Les explications détaillées sur les températures, le refroidissement, les fréquences CPU/GPU et le thermal throttling sont présentées dans les sections dédiées de ce guide..

Détecter le thermal throttling et les pertes de performances

Le thermal throttling est un mécanisme de protection qui réduit automatiquement les performances d’un processeur ou d’une carte graphique lorsque sa température devient trop élevée. Le composant diminue alors notamment ses fréquences et sa consommation afin de produire moins de chaleur et de rester dans ses limites de fonctionnement.

StressTest Malekal cherche à détecter ce phénomène en analysant simultanément la charge, les températures et l’évolution des fréquences du CPU et du GPU pendant les différentes phases du test.

Un comportement caractéristique peut être :

Charge élevée → température proche de la limite → baisse des fréquences → performances réduites.

Le PC peut donc terminer le test sans planter tout en présentant une perte de performances sous charge.

Température élevée ne signifie pas forcément throttling

Il est important de distinguer une température élevée d’un véritable thermal throttling.

Un processeur peut fonctionner à une température importante tout en maintenant correctement ses fréquences. Dans ce cas, le refroidissement est fortement sollicité, mais cela ne signifie pas nécessairement que les performances sont réduites.

À l’inverse, si les graphiques montrent que la fréquence diminue lorsque la température atteint sa limite alors que la charge reste élevée, une limitation thermique devient beaucoup plus probable.

StressTest Malekal permet justement de croiser ces différentes mesures plutôt que de considérer uniquement la température maximale.

Toutes les baisses de fréquence ne sont pas thermiques

Une diminution des fréquences pendant le test peut également provenir d’autres limitations :

• Limite de puissance ou de consommation du CPU ou du GPU.
• Profil d’alimentation de Windows.
• Paramètres du BIOS/UEFI.
• Limites définies par le constructeur, notamment sur les ordinateurs portables.
• Fonctionnement normal des mécanismes de boost.
• Partage des limites thermiques et énergétiques entre CPU et GPU sur certains portables.

Il faut donc examiner le moment où la baisse intervient et les autres mesures enregistrées au même instant avant de conclure à une surchauffe.

Que faire en cas de limitation thermique ?

Si StressTest Malekal détecte une perte de performances associée à des températures excessives, vérifiez en priorité le système de refroidissement : poussière, ventilation du boîtier, fonctionnement des ventilateurs, radiateur, pâte thermique ou montage du ventirad/watercooling.

Sur un ordinateur portable, vérifiez également que les entrées et sorties d’air ne sont pas obstruées et effectuez les tests sur une surface dure et plane.

Après correction, vous pouvez relancer le test et comparer les résultats. Une température plus basse associée à des fréquences mieux maintenues indique que l’amélioration du refroidissement a effectivement réduit la limitation des performances.

Vérifier les performances de la mémoire RAM

StressTest Malekal intègre également un benchmark de la mémoire RAM afin de mesurer ses performances et de détecter des résultats anormalement faibles.

Contrairement aux phases CPU et GPU, ce test n’a pas pour objectif principal de faire monter la température du matériel. Il permet surtout d’évaluer la vitesse à laquelle le processeur et la mémoire peuvent transférer les données.

Le rapport présente notamment les débits mémoire obtenus pendant le benchmark et permet de vérifier si les performances sont cohérentes avec la configuration du PC.

Pourquoi les performances de la RAM peuvent-elles être faibles ?

Des performances mémoire inférieures à celles attendues peuvent avoir plusieurs causes :

• RAM fonctionnant à une fréquence inférieure à celle prévue.
• Profil XMP ou EXPO non activé dans le BIOS/UEFI.
• Barrettes installées dans une configuration ne permettant pas le Dual Channel.
• Mélange de barrettes ayant des caractéristiques différentes.
• Paramètres mémoire ou BIOS/UEFI incorrects.
• Limitation liée au processeur ou au contrôleur mémoire.
• Activité importante d’autres applications pendant le benchmark.

Il faut toutefois éviter de comparer directement deux PC uniquement à partir du débit mémoire. Les résultats dépendent notamment du processeur, du contrôleur mémoire, du type de RAM, de sa fréquence, de ses timings et du nombre de canaux utilisés.

Un benchmark mémoire ne teste pas la fiabilité de la RAM

De bonnes performances mémoire ne signifient pas nécessairement que la RAM est parfaitement stable.

Le benchmark de StressTest Malekal mesure principalement les performances de la mémoire. Pour rechercher des cellules mémoire défectueuses ou une instabilité de la RAM, il faut utiliser un outil spécialisé tel que MemTest86+.

Ainsi, si votre PC présente des plantages aléatoires, des écrans bleus, des erreurs mémoire ou des corruptions de données, complétez le diagnostic par un véritable test de la RAM.

Le test mémoire intégré vérifie l’intégrité de données écrites et relues pendant que Windows fonctionne, tandis que la surveillance WHEA recherche les erreurs matérielles signalées par la plateforme. Il ne remplace pas MemTest86+, plus approfondi pour tester la RAM elle-même, mais peut révéler des instabilités qui n’apparaissent que lorsque le processeur, le contrôleur mémoire, le GPU, l’alimentation et le refroidissement sont simultanément sollicités.

Le guide complet :

Vérifier les performances du SSD ou du disque

StressTest Malekal teste également le périphérique de stockage afin de mesurer ses performances et de détecter des résultats anormalement faibles.

Le rapport permet notamment de vérifier les débits en lecture et en écriture et de déterminer si le SSD ou le disque présente des performances cohérentes avec son type : disque dur, SSD SATA ou SSD NVMe.

Des performances faibles peuvent avoir différentes causes : SSD presque plein, activité importante en arrière-plan, limitation de l’interface SATA/PCIe, température élevée ou simplement caractéristiques du modèle utilisé.

Attention toutefois : ce benchmark mesure principalement les performances du stockage et non son état de santé. Pour rechercher une usure, des erreurs ou une défaillance du SSD/disque, consultez les données SMART.

Les guides pour aller plus loin :

Détecter les erreurs matérielles WHEA

StressTest Malekal recherche également les erreurs WHEA (Windows Hardware Error Architecture) enregistrées par Windows pendant les tests. Elles peuvent signaler une anomalie concernant notamment le processeur, la mémoire RAM, le bus PCIe, la carte graphique ou le stockage.

Cette vérification est importante car un PC peut terminer le stress test sans planter tout en générant des erreurs matérielles. StressTest Malekal les prend donc en compte dans l’évaluation de la stabilité et les met en relation avec les différentes phases de charge.

Une erreur WHEA isolée ne permet pas forcément d’identifier immédiatement le composant responsable. En revanche, des erreurs répétées ou apparaissant pendant une phase précise du test méritent un diagnostic plus approfondi.

Erreurs WHEA sous Windows : causes, diagnostic et solutions : lien vers le guide dédié.

Comprendre les scores et les recommandations

À la fin des tests, StressTest Malekal synthétise les différentes mesures sous forme de scores et d’analyses afin de faciliter l’interprétation du rapport. L’objectif est de repérer rapidement les composants qui se comportent normalement et ceux qui nécessitent une vérification plus approfondie.

Les scores peuvent notamment tenir compte des performances obtenues, des températures, du comportement sous charge et des éventuelles anomalies détectées pendant le test.

Il est important de ne pas considérer uniquement la note finale. Un PC peut obtenir de bonnes performances tout en présentant, par exemple, une température excessive, une baisse de fréquence sous charge ou des erreurs WHEA.

StressTest Malekal accompagne donc les résultats de recommandations et d’explications lorsque certaines valeurs paraissent anormales. Elles peuvent orienter vers une vérification du refroidissement, des performances du stockage, de la mémoire ou vers un diagnostic matériel plus approfondi.

Les scores doivent ainsi être utilisés comme un résumé du test, tandis que les graphiques et analyses détaillées permettent de comprendre pourquoi un composant obtient un résultat plus faible ou pourquoi une anomalie a été signalée.

Partager son rapport StressTest Malekal

StressTest Malekal, OCCT ou UserDiag : lequel utiliser ?

StressTest Malekal, OCCT et UserDiag permettent tous de solliciter le matériel d’un PC, mais ils ne répondent pas exactement au même besoin.

StressTest Malekal met surtout l’accent sur l’analyse automatique du comportement du PC. Les mesures collectées pendant les différentes phases sont utilisées pour examiner les températures, les fréquences, le refroidissement, les performances et la stabilité, puis présenter les résultats dans un rapport plus facile à interpréter.

OCCT est davantage adapté aux utilisateurs qui souhaitent configurer précisément leurs stress tests et solliciter individuellement le CPU, le GPU, la mémoire ou l’alimentation. Il offre davantage de contrôle sur les tests, mais demande aussi de savoir interpréter les résultats obtenus.

UserDiag est plutôt orienté vers le diagnostic matériel général du PC. Il permet de récupérer la configuration de l’ordinateur et d’effectuer différents tests afin de rechercher un problème matériel.

Outil	À privilégier pour
StressTest Malekal	Tester le PC et obtenir une analyse automatique des températures, performances et du comportement sous charge
OCCT	Effectuer des stress tests avancés et configurables sur des composants précis
UserDiag	Réaliser un diagnostic matériel général et obtenir les caractéristiques du PC

Ces outils sont donc davantage complémentaires que concurrents. Si vous souhaitez simplement vérifier comment votre PC se comporte sous charge sans avoir à interpréter manuellement toutes les mesures, StressTest Malekal est particulièrement adapté. Pour effectuer des tests plus poussés ou reproduire une charge précise, OCCT offre davantage de possibilités.

Les guides complets :

Aller plus loin avec une analyse complète de Windows

StressTest Malekal se concentre principalement sur le comportement du matériel lorsqu’il est sollicité : températures, fréquences CPU/GPU, performances, refroidissement, throttling, stabilité et éventuelles erreurs matérielles.

Pour rechercher plutôt les problèmes liés à Windows et à sa configuration, vous pouvez compléter ce diagnostic avec AnalysePC. Le service examine de nombreux éléments du système afin de détecter les anomalies pouvant provoquer des lenteurs, des erreurs ou un mauvais fonctionnement du PC.

AnalysePC permet notamment de vérifier :

• Le démarrage de Windows et les programmes qui se lancent automatiquement.
• Les processus et services Windows.
• Les pilotes et périphériques.
• Les erreurs système et événements importants.
• Windows Update et les échecs de mise à jour.
• La configuration matérielle et les disques.
• Les paramètres pouvant affecter les performances de Windows.
• Les problèmes détectés et les actions recommandées.

Les deux services sont donc complémentaires : StressTest Malekal vérifie surtout comment le matériel se comporte sous charge, tandis qu’AnalysePC recherche les problèmes présents dans Windows et sa configuration.

Pour le découvrir et apprendre à l’utiliser, suivez ce lien :

Enfin les conseils au quotidien :

L’article StressTest Malekal : vérifier la santé et le comportement de son PC est apparu en premier sur malekal.com.

Microsoft déploie son Patch Tuesday d’août 2026 avec une importante série de mises à jour de sécurité pour Windows et ses différents produits.

Au total, Microsoft corrige environ 400 vulnérabilités, dont 42 classées critiques et 3 failles zero-day. L’une d’elles était déjà activement exploitée dans des attaques avant la publication des correctifs.

Sous Windows 11 24H2 et 25H2, la mise à jour KB5121003 apporte également de nombreuses améliorations fonctionnelles : lancement plus rapide de certaines applications, recherche Windows plus tolérante aux fautes de frappe, améliorations de l’Explorateur de fichiers, nouveau comportement du pavé tactile et évolutions de Voice Access.

Windows 10 reçoit de son côté la mise à jour KB5120249, essentiellement consacrée à la sécurité, à l’Historique des fichiers et au déploiement des nouveaux certificats Secure Boot.

Windows 11 KB5121003 : les builds 26100.9165 et 26200.9165

Pour Windows 11 24H2 et 25H2, Microsoft distribue la mise à jour cumulative obligatoire KB5121003.

Après installation :

• Windows 11 25H2 passe en Build 26200.9165 ;
• Windows 11 24H2 passe en Build 26100.9165.

La mise à jour est automatiquement proposée par Windows Update, puisqu’elle contient les correctifs de sécurité du Patch Tuesday.

Microsoft propose également les installateurs autonomes .msu dans le Catalogue Microsoft Update.

Les applications peuvent démarrer plus rapidement

L’une des nouveautés les plus intéressantes concerne le Profil à faible latence (Low Latency Profile).

Cette technologie avait commencé à être déployée sur certains composants de Windows, notamment le menu Démarrer, le Centre de notifications, les Paramètres rapides et les menus contextuels.

Son objectif est d’améliorer la réactivité en demandant au processeur d’augmenter rapidement sa fréquence lorsqu’une action nécessitant davantage de ressources est détectée.

Avec KB5121003, Microsoft étend progressivement ce mécanisme aux applications.

Sur les configurations les moins puissantes, notamment celles équipées de processeurs modestes ou de seulement 8 Go de RAM, certaines applications peuvent ainsi démarrer plus rapidement.

Il ne s’agit pas d’une augmentation permanente de la fréquence du processeur : le boost ne dure que quelques secondes afin d’améliorer la réactivité au moment où elle est nécessaire.

Le déploiement reste progressif. Tous les utilisateurs ne verront donc pas immédiatement cette amélioration après l’installation du Patch Tuesday.

Le guide avec toutes les explications :

Windows Search gère enfin mieux les fautes de frappe

Microsoft améliore également sensiblement Windows Search.

Jusqu’ici, une simple faute dans le nom d’une application pouvait suffire à empêcher la recherche locale de trouver le bon résultat, tandis que Bing comprenait souvent mieux la requête.

KB5121003 améliore la tolérance aux :

• fautes de frappe ;
• lettres manquantes ;
• caractères supplémentaires ;
• noms d’applications incomplets.

Par exemple, Windows Search peut désormais retrouver Outlook même si l’utilisateur saisit une variante mal orthographiée du nom de l’application.

Les recherches de paramètres Windows sont également mieux classées afin d’éviter que des résultats Bing prennent inutilement le dessus sur un réglage local recherché par l’utilisateur.

L’Explorateur de fichiers affiche enfin les bonnes unités

L’Explorateur de fichiers reçoit lui aussi plusieurs changements.

Dans l’affichage Détails, Windows affichait jusqu’à présent toutes les tailles en kilo-octets, même pour des fichiers de plusieurs gigaoctets.

Ainsi, une image ISO de plusieurs Go pouvait apparaître sous la forme de plusieurs millions de Ko.

Avec KB5121003, l’Explorateur choisit désormais automatiquement une unité plus adaptée :

• Ko pour les petits fichiers ;
• Mo pour les fichiers intermédiaires ;
• Go pour les fichiers volumineux.

Cette modification améliore nettement la lisibilité de la colonne Taille.

Comme plusieurs autres nouveautés de cette mise à jour, son déploiement est progressif.

Navigation et onglets améliorés dans l’Explorateur

Microsoft améliore également la barre d’adresse de l’Explorateur de fichiers, qui devrait réagir plus rapidement lorsqu’on navigue entre plusieurs chemins précédemment utilisés.

Autre changement pratique : un clic avec le bouton central de la souris sur un dossier permet désormais de l’ouvrir directement dans un nouvel onglet, comme dans un navigateur Web.

Microsoft corrige aussi :

• un flash gris pouvant apparaître lors du chargement de l’Explorateur ;
• des miniatures de mauvaise qualité dans la section Recommandé ;
• plusieurs problèmes de fiabilité d’explorer.exe.

Prise en charge ESS dans Windows Hello

Dans cette mise à jour, Microsoft ajoute la prise en charge de la fonctionnalité « Sécurité de connexion améliorée » (ESS) de Windows Hello pour les capteurs d’empreintes digitales externes.

En bref, la fonctionnalité Windows Hello standard crypte les données de connexion. Cependant, la prise en charge de la sécurité améliorée va plus loin en isolant le processus biométrique dans un espace mémoire sécurisé, distinct du système d’exploitation.

Cette option est accessible via Paramètres > Comptes > Options de connexion.

Vue des tâches, bureaux virtuels et listes de raccourcis plus fluides

Des améliorations sont également apportées à plusieurs éléments de l’interface.

La gestion des fichiers récents et des listes de raccourcis devient plus fiable lorsque vous effectuez un clic droit sur une application dans la barre des tâches.

La Vue des tâches et la navigation entre plusieurs bureaux virtuels devraient également être plus fluides, avec moins de ralentissements et de saccades.

Microsoft améliore parallèlement la fiabilité du menu Démarrer et de la barre des tâches pendant le démarrage de Windows.

Accès vocal gagne une isolation de la voix

La fonction Accès vocal bénéficie d’un nouveau mécanisme de filtrage du microphone.

Trois modes sont proposés :

• Isolation de la voix, qui réduit le bruit ambiant et tente de ne conserver que la voix de l’utilisateur ;
• Suppression du bruit de fond, qui filtre le bruit mais laisse les autres voix audibles ;
• Aucun filtre, qui utilise directement le signal du microphone.

Cette évolution doit rendre les commandes vocales plus fiables dans les environnements bruyants ou lorsque plusieurs personnes parlent à proximité.

De nouveaux réglages pour le pavé tactile

Les utilisateurs équipés d’un pavé tactile de précision disposent également de nouveaux paramètres.

Microsoft introduit notamment un défilement accéléré, qui augmente la vitesse lorsqu’un même geste est répété rapidement.

Windows permet désormais également de régler séparément :

• la vitesse du défilement ;
• la vitesse du zoom.

Ces réglages devraient surtout être utiles aux utilisateurs passant régulièrement d’un portable à un autre et souhaitant retrouver un comportement similaire du pavé tactile.

Windows Hello et écran de verrouillage

Microsoft améliore aussi Windows Hello Enhanced Sign-in Security (ESS) sur les appareils compatibles.

La mise à jour corrige notamment un problème pouvant rendre Windows Hello lent lorsque le système utilisait beaucoup de mémoire.

L’écran de verrouillage reçoit lui aussi plusieurs ajustements de performances.

Pour les nouveaux utilisateurs, Microsoft simplifie par ailleurs les Widgets affichés sur l’écran de verrouillage : seule la météo est désormais activée par défaut.

Des Widgets moins visibles

Les badges de Widgets affichés dans la barre des tâches n’utilisent plus systématiquement une couleur rouge.

Ils reprennent désormais la couleur d’accentuation de Windows, ce qui doit les rendre moins intrusifs visuellement.

Sur l’écran de verrouillage, l’expérience devrait désormais être moins distrayante, car, par défaut, les utilisateurs ne verront plus que le widget Météo.

Microsoft poursuit ainsi la simplification progressive du panneau Widgets entamée au cours des précédentes mises à jour.

Le composant de génération d’images IA devient désinstallable

Sur les Copilot+ PC, Microsoft permet désormais de supprimer le composant Image Generation AI.

Cette évolution s’inscrit dans la stratégie récente de Microsoft visant à rendre certains composants d’intelligence artificielle plus modulaires et à permettre leur suppression lorsqu’ils ne sont pas utilisés.

Plusieurs petites corrections bienvenues

KB5121003 contient également de nombreuses corrections plus discrètes.

Microsoft corrige notamment :

• des préférences du menu Démarrer qui pouvaient disparaître après un redémarrage ;
• la taille du pointeur de souris qui pouvait être réinitialisée ;
• certains paramètres d’alimentation qui n’étaient pas correctement conservés ;
• la gestion du seuil d’activation de l’économiseur d’énergie ;
• l’impact de certaines recherches Windows Update sur les performances du système..

Microsoft poursuit le remplacement des certificats Secure Boot

La mise à jour Windows 10 améliore également le ciblage des appareils devant recevoir automatiquement les nouveaux certificats Secure Boot.

Microsoft poursuit depuis plusieurs mois le remplacement progressif des anciens certificats Secure Boot arrivant à expiration en 2026.

La société précise que le déploiement continuera au travers de Windows Update sur les appareils compatibles et les PC professionnels non gérés.

Cette opération est progressive : tous les ordinateurs ne reçoivent donc pas les nouveaux certificats au même moment.

400 vulnérabilités corrigées en août 2026

Ce Patch Tuesday reste particulièrement volumineux, même s’il demeure en dessous du record du mois de juillet, où Microsoft avait corrigé 570 vulnérabilités.

Les quelque 400 failles corrigées en août se répartissent approximativement ainsi :

• 176 vulnérabilités d’élévation de privilèges ;
• 110 vulnérabilités permettant l’exécution de code à distance ;
• 86 divulgations d’informations ;
• 21 vulnérabilités d’usurpation d’identité ;
• 12 dénis de service ;
• 11 contournements de fonctions de sécurité.

Microsoft classe par ailleurs 42 vulnérabilités comme critiques, dont 37 permettent potentiellement l’exécution de code à distance et cinq une élévation de privilèges.

Le chiffre de 400 ne comprend pas certaines failles corrigées plus tôt dans le mois dans Azure, Microsoft Teams, Entra, Office, Power Apps ou encore Mariner.

Trois zero-day, dont une exploitée par le groupe Lazarus

Trois vulnérabilités zero-day retiennent particulièrement l’attention ce mois-ci.

L’une était déjà activement exploitée avant la publication du correctif, tandis que les deux autres avaient été rendues publiques.

CVE-2026-68820 : une élévation de privilèges déjà exploitée

La faille la plus préoccupante est CVE-2026-68820, qui affecte le pilote Windows Ancillary Function Driver for WinSock, également connu sous le nom AFD.sys.

Cette vulnérabilité de type « use-after-free » peut permettre à un attaquant déjà authentifié sur la machine d’exécuter une application spécialement conçue afin d’obtenir les privilèges SYSTEM, le niveau de privilège le plus élevé sous Windows. Aucune interaction de l’utilisateur n’est nécessaire.

Selon Check Point, cette zero-day a été exploitée par le groupe nord-coréen Lazarus afin de déployer une nouvelle version de son rootkit en mode noyau FudModule.

Cette vulnérabilité est donc particulièrement importante, car elle permet à un attaquant ayant déjà obtenu un premier accès à un PC de prendre ensuite le contrôle complet du système.

CVE-2026-62832 : Microsoft corrige enfin LegacyHive

Le Patch Tuesday d’août corrige également CVE-2026-62832, une vulnérabilité affectant le Windows User Profile Service.

Les caractéristiques techniques correspondent à la faille LegacyHive, rendue publique en juillet et dont nous avions déjà parlé.

Cette vulnérabilité permet à un utilisateur disposant de droits limités et des identifiants d’un autre compte local de charger la ruche du Registre d’un autre utilisateur.

Un attaquant peut ainsi accéder ou modifier certaines données et, dans certaines conditions, obtenir des privilèges administrateur sans interaction supplémentaire de la victime.

Jusqu’ici, aucun correctif Microsoft officiel n’était disponible et 0patch proposait un micropatch temporaire.

La publication de KB5121003 et des autres mises à jour d’août rend donc cette protection non officielle inutile sur les systèmes correctement mis à jour.

A lire :

CVE-2026-72971 : une faille dans Windows Container Isolation

La troisième zero-day, CVE-2026-72971, affecte le pilote Windows Container Isolation FS Filter Driver (unionfs.sys).

Cette vulnérabilité avait déjà été rendue publique avant la publication du Patch Tuesday. Elle permet à un attaquant déjà authentifié localement d’exploiter un problème de résolution de liens dans le pilote unionfs.sys afin d’altérer des données.

Elle concerne notamment les mécanismes utilisés par Windows pour isoler certains systèmes de fichiers dans les environnements conteneurisés.

Aucun problème majeur signalé pour le moment

Au moment de la publication, Microsoft et les premières observations rapportées par WindowsLatest ne font état d’aucun problème majeur généralisé lié à KB5121003.

Même constat pour KB5120249 sous Windows 10, pour laquelle aucun nouveau problème connu important n’est signalé à ce stade.

Il faudra néanmoins attendre quelques jours pour disposer d’un recul suffisant sur plusieurs millions de configurations différentes.

Conclusion

Le Patch Tuesday d’août 2026 est à nouveau particulièrement chargé.

Microsoft corrige environ 400 vulnérabilités, dont trois zero-day. La plus importante, CVE-2026-68820, était déjà utilisée par le groupe Lazarus pour obtenir les privilèges SYSTEM et déployer un rootkit en mode noyau.

La mise à jour clôt également le dossier LegacyHive, divulgué en juillet et désormais officiellement corrigé par Microsoft.

Sous Windows 11, KB5121003 ne se limite pas à la sécurité. Elle poursuit l’évolution progressive du système avec un Explorateur de fichiers plus pratique, une recherche locale plus tolérante aux erreurs, des améliorations de performances, un pavé tactile plus configurable et plusieurs optimisations de fiabilité.

Windows 10 entre quant à lui définitivement dans une logique de maintenance : KB5120249 apporte essentiellement des correctifs de sécurité, une correction de l’Historique des fichiers et la poursuite du renouvellement des certificats Secure Boot.

L’article KB5121003 de Windows 11 : 400 failles corrigées, 3 zero-day et de nombreuses améliorations est apparu en premier sur malekal.com.

Les fichiers ZIP, RAR et 7z permettent de regrouper et de compresser des données afin de faciliter leur stockage ou leur transfert. Dans la majorité des cas, leur extraction se déroule sans difficulté. Toutefois, il arrive que Windows ou un logiciel de décompression affiche un message d’erreur et refuse d’ouvrir l’archive.

Vous pouvez par exemple rencontrer les erreurs « Windows ne peut pas effectuer l’extraction », « Le dossier compressé est invalide », Erreur CRC, Data Error dans 7-Zip, fichier corrompu dans WinRAR ou encore une erreur 0x80070570. Ces messages peuvent être provoqués par une archive corrompue, un téléchargement incomplet, un logiciel de décompression incompatible ou encore un problème de disque.

Dans ce guide, vous découvrirez les causes les plus fréquentes des erreurs de décompression, les vérifications à effectuer pour identifier leur origine et les solutions adaptées selon le message affiché par Windows, 7-Zip, WinRAR ou un autre logiciel de décompression.

Pourquoi une archive ne s’extrait pas ?

Lorsqu’une archive ZIP, RAR ou 7z refuse de s’extraire, le problème ne provient pas forcément du logiciel de décompression. L’erreur peut être liée à une archive corrompue, à un téléchargement incomplet, à un manque d’espace disque ou encore à un problème de stockage sur votre ordinateur.

Le tableau ci-dessous présente les causes les plus fréquentes.

Cause	Quand se produit-elle ?	Que faire ?
Archive corrompue	L’extraction échoue immédiatement ou affiche une erreur CRC.	Télécharger de nouveau l’archive ou demander une copie valide.
Téléchargement incomplet	La taille du fichier est inférieure à celle annoncée ou le téléchargement a été interrompu.	Retélécharger complètement l’archive.
Logiciel de décompression incompatible	L’Explorateur Windows ne parvient pas à ouvrir l’archive ou ne prend pas en charge son format.	Essayer avec 7-Zip, WinRAR ou PeaZip.
Nom ou chemin de fichier trop long	L’extraction échoue sur certains fichiers uniquement.	Extraire l’archive dans un dossier proche de la racine (par exemple C:\Temp).
Manque d’espace disque	L’extraction s’interrompt en cours de copie.	Libérer de l’espace sur le disque de destination.
Archive protégée par mot de passe	Le logiciel demande un mot de passe ou signale une erreur de déchiffrement.	Vérifier que le mot de passe est correct.
Erreur du disque ou de la clé USB	Plusieurs fichiers sont illisibles ou d’autres erreurs apparaissent (CRC, 0x80070570, erreur d’entrée/sortie).	Vérifier l’état du disque et le système de fichiers.
Antivirus ou logiciel de sécurité	L’extraction se bloque ou certains fichiers sont mis en quarantaine.	Désactiver temporairement l’analyse en temps réel si le fichier provient d’une source fiable.

Vérifier si l’archive est corrompue

L’une des causes les plus fréquentes d’un échec d’extraction est une archive corrompue. Cela peut se produire après un téléchargement interrompu, une copie incomplète ou un problème sur le support de stockage.

Les symptômes les plus courants sont :

• Erreur CRC (Cyclic Redundancy Check) ;
• Data Error dans 7-Zip ;
• Le dossier compressé est invalide ;
• L’archive est endommagée ou fichier corrompu dans WinRAR ;
• extraction qui s’interrompt toujours sur le même fichier.

Le logiciel 7-Zip permet de vérifier très facilement l’intégrité d’un fichier ZIP : clic droit sur le fichier puis 7-Zip > contrôler archives

Avant de conclure que l’archive est défectueuse, effectuez les vérifications suivantes.

Vérification	Pourquoi ?
Comparer la taille du fichier avec celle indiquée sur le site de téléchargement	Permet de détecter un téléchargement incomplet.
Télécharger de nouveau l’archive	Corrige la plupart des archives corrompues pendant le téléchargement.
Essayer d’ouvrir l’archive avec un autre logiciel (7-Zip, WinRAR, PeaZip)	Vérifie si le problème provient du logiciel utilisé.
Tester l’archive sur un autre ordinateur	Permet de déterminer si le problème vient de l’archive ou de votre PC.
Vérifier le disque de stockage	Une erreur du disque peut corrompre les fichiers téléchargés ou copiés.

Si plusieurs téléchargements du même fichier produisent exactement la même erreur, il est possible que l’archive mise à disposition par son auteur soit elle-même endommagée.

Si l’erreur mentionne un CRC, une erreur d’entrée/sortie (E/S) ou le code 0x80070570, vérifiez également l’état de santé de votre disque dur ou SSD, car le problème peut provenir du support de stockage plutôt que de l’archive elle-même.

Le guide complet :

Tester avec un autre logiciel

L’outil intégré à Windows prend uniquement en charge les archives ZIP et peut parfois rencontrer des difficultés avec certaines archives volumineuses, protégées par mot de passe ou utilisant des méthodes de compression récentes.

Si l’extraction échoue avec l’Explorateur de fichiers, essayez d’ouvrir l’archive avec un autre logiciel. Celui-ci affichera souvent un message d’erreur plus précis, ce qui facilite le diagnostic.

Logiciel	À privilégier pour…
7-Zip	Les archives ZIP, 7z et la détection des erreurs CRC ou Data Error.
WinRAR	Les archives RAR, ZIP et les archives multi-volumes.
PeaZip	La prise en charge de nombreux formats d’archives avec une interface simple.

Si plusieurs logiciels affichent la même erreur, il est très probable que l’archive soit réellement corrompue ou incomplète.

En revanche, si un logiciel parvient à extraire l’archive alors qu’un autre échoue, le problème provient généralement du logiciel de décompression utilisé et non de l’archive elle-même.

Conseil : si l’Explorateur Windows affiche le message « Windows ne peut pas effectuer l’extraction », essayez d’abord 7-Zip. Il est souvent plus tolérant avec certaines archives ZIP et fournit des messages d’erreur beaucoup plus explicites.

Vérifier le disque

Si l’archive est stockée sur un disque dur, un SSD ou une clé USB présentant des erreurs, l’extraction peut échouer même si le fichier est intact. Une erreur de lecture ou d’écriture suffit à rendre certains fichiers de l’archive inaccessibles.

Les symptômes suivants peuvent indiquer un problème de stockage :

Symptôme	Cause possible
Plusieurs archives refusent de s’extraire	Erreur du système de fichiers ou problème du disque.
Erreur CRC, 0x80070570 ou Erreur d’entrée/sortie (E/S)	Secteurs défectueux ou support de stockage défaillant.
L’extraction s’interrompt toujours au même endroit	Erreur de lecture sur le disque.
Les fichiers copiés sont également corrompus	Défaillance du disque, de la clé USB ou du SSD.
Le disque est lent ou émet des bruits inhabituels	Dégradation matérielle du support de stockage.

Dans ce cas, il est recommandé de :

• vérifier l’état SMART du disque ;
• réparer les éventuelles erreurs du système de fichiers avec CHKDSK ;
• rechercher les erreurs de stockage dans l’Observateur d’événements ou avec AnalysePC.

Pour savoir si votre disque est à l’origine du problème, consultez notre guide :

Retélécharger le fichier ZIP ou restaurer le depuis une sauvegarde

Une autre source de l’erreur des dossiers compressés Windows est que le fichier ZIP est partiellement téléchargé.
Comme le fichier n’est pas entier, il est donc corrompu.
Dans le cas la meilleur solution consiste à télécharger à nouveau le fichier.
Si le fichier ZIP provient d’une copie de fichiers (disque dur externe, partage réseau), comparez les tailles de fichiers pour s’assurer que le fichier est entièrement copier.
Vous pouvez aussi comparer l’empreinte du fichier pour vous assurer que le téléchargement n’est pas corrompu.

Pour cela, suivez ce guide :

Enfin si vous avez une sauvegarde du fichier archive, n’hésitez pas à restaurer cette sauvegarde.

Une fois le fichier ZIP récupéré, tentez de le décompresser pour vérifier si l’erreur « Windows ne peut pas effectuer l’extraction » est corrigée.

Réparer un fichier ZIP corrompu ou endommagé

Enfin, si après avoir suivi toutes ces conseils, vous n’avez pu résoudre l’erreur « Windows ne peut pas effectuer l’extraction«  » est corrigée« , il est probable que le fichier ZIP soit endommagé.
Vous pouvez tenter de le réparer en suivant ce tutoriel :

Que faire selon le message d’erreur ?

Le message affiché par Windows, 7-Zip ou WinRAR permet souvent d’identifier rapidement l’origine du problème. Le tableau ci-dessous vous oriente vers le guide le plus adapté.

Message d’erreur	Cause probable	Guide recommandé
Windows ne peut pas effectuer l’extraction	Limitation de l’Explorateur Windows, chemin trop long, archive ou fichier verrouillé	Windows ne peut pas effectuer l’extraction : comment corriger l’erreur ?
Le dossier compressé est invalide	Archive ZIP corrompue ou téléchargement incomplet	Vérifier l’intégrité de l’archive et la retélécharger si nécessaire.
Erreur CRC	Archive corrompue ou erreur de lecture sur le disque	Erreur CRC : causes et solutions
Data Error (7-Zip)	Archive endommagée ou données corrompues	Vérifier l’archive et essayer un nouveau téléchargement.
CRC Failed (7-Zip)	L’intégrité des données n’a pas pu être vérifiée.
WinRAR : fichier corrompu	Archive incomplète ou endommagée	Télécharger de nouveau l’archive ou demander une copie valide.
0x80070570 : Le fichier est endommagé ou illisible	Fichier illisible, système de fichiers corrompu ou support de stockage défectueux	Erreur 0x80070570 : causes et solutions
0x80004005 : Erreur non spécifiée	Archive protégée, permissions, antivirus ou archive corrompue	Erreur 0x80004005 : causes et solutions
Erreur d’entrée/sortie (E/S)	Problème de lecture/écriture sur le disque ou la clé USB	Erreur d’entrée/sortie (E/S) : causes et solutions

L’article Résoudre les problèmes de décompression de fichiers ZIP, RAR et 7z est apparu en premier sur malekal.com.

Le problème de compatibilité entre Windows 11 et certains pilotes Intel était beaucoup plus large que prévu.

Dell a finalement confirmé qu’environ 245 modèles de PC ont été concernés par les dysfonctionnements apparus après les mises à jour Windows 11 de juin et juillet 2026. Les symptômes pouvaient aller d’une forte baisse de performances à une surchauffe, une consommation excessive de batterie et même des arrêts inattendus du système.

La bonne nouvelle est que le problème est désormais corrigé grâce à la mise à jour hors cycle KB5121767, publiée par Microsoft le 18 juillet 2026. Les PC concernés doivent toutefois disposer d’une build suffisamment récente pour être définitivement à l’abri.

Un problème apparu avec les mises à jour de juin 2026

Les premiers symptômes sont apparus après l’installation de la mise à jour facultative KB5095093, publiée le 23 juin 2026.

À l’époque, certains propriétaires de PC Dell et Alienware avaient commencé à signaler des problèmes de performances, une hausse des températures ou un comportement anormal du système.

La situation s’est aggravée avec le Patch Tuesday du 14 juillet et la mise à jour obligatoire KB5101650. Microsoft a alors bloqué temporairement son déploiement sur certains PC Dell après avoir identifié une incompatibilité susceptible de provoquer des problèmes sérieux de performances et de gestion énergétique.

Le pilote Intel Innovation Platform Framework au cœur du problème

L’origine du dysfonctionnement se trouve dans une incompatibilité entre le pilote Intel Innovation Platform Framework (IPF) Processor Participant et une nouvelle interface de Windows appelée Windows USB-C Connection Manager.

Le pilote Intel IPF joue un rôle beaucoup plus important qu’un simple pilote de périphérique.

Selon Dell, il prend notamment en charge Intel Dynamic Tuning Technology (DTT), utilisé pour gérer la consommation électrique, les performances, la température du processeur et le fonctionnement des ventilateurs. Il prend aussi en charge Intel Context Sensing Technology, notamment certaines fonctions de détection de présence.

Lorsqu’une mise à jour Windows perturbe son fonctionnement, les conséquences peuvent donc être importantes : le PC peut mal gérer ses limites de puissance, son refroidissement ou ses fréquences de fonctionnement.

Quels problèmes pouvaient apparaître ?

Microsoft indique que les appareils concernés pouvaient subir des modifications anormales des performances, de la consommation électrique ou du comportement général du système.

Dell et Windows Latest ont rapporté plusieurs symptômes possibles :

• fortes baisses de performances ;
• augmentation anormale de la température ;
• consommation excessive de la batterie ;
• fonctionnement incorrect de la gestion énergétique ;
• arrêts inattendus du PC.

Dans certains cas, le système pouvait ainsi devenir difficilement utilisable, notamment lorsque la gestion thermique et énergétique ne fonctionnait plus correctement.

Finalement, près de 245 modèles Dell sont concernés

Lors de la découverte initiale du problème, seule une petite dizaine de modèles avaient été publiquement identifiés.

Cette première liste comprenait notamment les Dell Pro Max, plusieurs Precision et les XPS 17 9720 et 9730.

Dell a désormais communiqué une liste beaucoup plus large : environ 245 modèles répartis dans presque toutes ses gammes.

On retrouve notamment :

• environ 20 modèles Alienware ;
• une trentaine d’Inspiron ;
• environ 35 Latitude ;
• une vingtaine d’OptiPlex ;
• près de 30 Precision ;
• une quinzaine de Vostro ;
• environ 16 XPS ;
• plusieurs Dell Pro, Dell Pro Max et Dell Pro Precision ;
• différents PC de bureau, mini-PC, All-in-One et modèles Rugged.

Autrement dit, le problème ne concernait pas uniquement quelques stations de travail professionnelles récentes. Des ordinateurs grand public, professionnels et gaming pouvaient également être touchés.

Alienware également concerné

La présence d’Alienware dans la liste est particulièrement notable.

Les PC gaming reposent fortement sur les mécanismes de gestion dynamique des fréquences, des températures et de la puissance. Un dysfonctionnement du pilote Intel IPF peut donc avoir un impact direct sur leurs performances et leur refroidissement.

Dell recense environ une vingtaine de modèles dans les gammes Area-51, Aurora, m-series et x-series parmi les appareils potentiellement concernés.

Microsoft a publié KB5121767 en urgence

Microsoft a corrigé le problème le 18 juillet avec la mise à jour hors cycle KB5121767 pour Windows 11 24H2 et 25H2.

Cette mise à jour cumulative contient un correctif spécifique destiné aux appareils équipés du pilote Intel IPF et concernés par cette incompatibilité. Microsoft précise qu’elle est principalement recommandée pour les appareils affectés et qu’aucune action n’est nécessaire sur les autres PC.

Après installation :

• Windows 11 25H2 passe en Build 26200.8894 ;
• Windows 11 24H2 passe en Build 26100.8894.

Dell recommande désormais d’utiliser ces builds ou une version plus récente.

Comment vérifier si votre PC est corrigé ?

Si vous utilisez un PC Dell et avez rencontré des problèmes de performances, de température ou d’autonomie depuis les mises à jour de juin ou juillet, commencez par vérifier votre version de Windows.

Ouvrez : Paramètres > Système > Informations système
puis consultez la rubrique consacrée aux spécifications de Windows.

Votre PC devrait utiliser au minimum :

• 26200.8894 sous Windows 11 25H2 ;
• 26100.8894 sous Windows 11 24H2.

Une build plus récente contient également le correctif.

Vous pouvez aussi lancer Windows Update afin d’installer les dernières mises à jour disponibles.

Faut-il encore installer KB5121767 aujourd’hui ?

Pas nécessairement.

KB5121767 était surtout une mise à jour d’urgence permettant de corriger immédiatement le problème sans attendre le cycle mensuel suivant. Microsoft indique qu’elle n’est recommandée que pour les appareils concernés.

Si votre PC possède déjà une build supérieure à 26200.8894 ou 26100.8894, le correctif est normalement déjà intégré à votre version de Windows.

Il est donc préférable de vérifier votre numéro de build plutôt que de chercher à installer manuellement KB5121767.

Un nouvel exemple des problèmes de compatibilité entre Windows et les pilotes

Cet incident montre une nouvelle fois à quel point les pilotes jouent un rôle critique dans la stabilité d’un système moderne.

Une modification relativement ciblée dans Windows, ici autour de la gestion USB-C, peut entrer en conflit avec un composant utilisé pour la gestion thermique et énergétique du PC.

Microsoft a d’ailleurs reconnu ce problème plus général de qualité des pilotes et travaille avec les constructeurs dans le cadre de sa Driver Quality Initiative. L’objectif est notamment d’améliorer les tests, de limiter les pilotes susceptibles d’interagir de manière problématique avec le noyau et de retirer de Windows Update les pilotes anciens ou devenus incompatibles.

Cela rejoint directement la stratégie récemment présentée par Microsoft pour améliorer la fiabilité de Windows et réduire les problèmes liés aux pilotes tiers.

Dell ou Microsoft : qui est responsable ?

Dell attribue clairement l’apparition du problème aux récentes mises à jour Windows, qui ont introduit l’interface Windows USB-C Connection Manager incompatible avec le pilote Intel IPF utilisé sur ses machines.

Il serait toutefois réducteur de résumer l’incident à une simple faute de Microsoft.

Le problème se situe précisément à l’intersection entre Windows, le pilote Intel et l’intégration réalisée par Dell. Une modification du système d’exploitation peut révéler une incompatibilité qui n’avait pas été détectée lors des phases de validation entre Microsoft, Intel et le constructeur.

C’est précisément ce type de scénario que Microsoft cherche désormais à éviter en renforçant les tests et les critères de validation des pilotes.

Le problème est désormais considéré comme résolu

Pour les utilisateurs, l’essentiel est que le correctif est disponible depuis plusieurs semaines.

Les ordinateurs Dell qui reçoivent normalement les mises à jour Windows devraient désormais utiliser une build contenant la correction.

Si votre PC Dell continue malgré tout à présenter une surchauffe inhabituelle, une baisse soudaine de performances ou des arrêts après les mises à jour de juin ou juillet 2026, il est conseillé de :

• installer toutes les mises à jour Windows disponibles ;
• mettre à jour les pilotes Intel et le BIOS depuis le support Dell ;
• vérifier que Windows utilise au minimum la build 26200.8894 ou 26100.8894 ;
• contrôler dans le Gestionnaire de périphériques qu’aucune erreur n’est présente sur les composants Intel IPF.

Conclusion

Ce qui semblait initialement être un problème limité à quelques PC Dell s’est finalement révélé beaucoup plus vaste.

Avec environ 245 modèles concernés, des gammes Inspiron et XPS aux Latitude, Precision, OptiPlex et Alienware, cette incompatibilité entre Windows 11 et le pilote Intel IPF constitue l’un des incidents de compatibilité les plus significatifs de ces dernières mises à jour.

Le problème est heureusement corrigé depuis la publication de KB5121767. Il souligne toutefois la difficulté de faire évoluer Windows tout en maintenant la compatibilité avec des milliers de combinaisons de pilotes, de firmwares et de matériels.

Il illustre aussi pourquoi Microsoft met aujourd’hui davantage l’accent sur la qualité des pilotes et sur la coopération avec les constructeurs : une simple incompatibilité peut avoir des conséquences très concrètes sur les performances, la consommation et même la température d’un PC.

L’article Windows 11 : Dell révèle que 245 modèles ont été touchés par le bug lié aux mises à jour de juin et juillet 2026 est apparu en premier sur malekal.com.

Sur les distributions Linux modernes utilisant systemd, les services système sont principalement administrés avec la commande systemctl. Serveur Web Nginx ou Apache, PHP-FPM, SSH, MariaDB/MySQL ou encore services réseau : lorsqu’un service ne démarre plus, s’arrête brutalement ou passe dans l’état failed, systemctl permet d’effectuer les premières vérifications.

Pour trouver pourquoi un service Linux est en échec, il faut généralement compléter le diagnostic avec journalctl, qui permet de consulter ses journaux et de retrouver les erreurs de configuration, problèmes de permissions, dépendances manquantes, ports déjà utilisés, timeouts ou crashs d’application.

Dans ce guide, découvrez comment vérifier et dépanner un service sous Linux avec systemctl et journalctl : lister les services, identifier ceux en échec, consulter leur état et leurs logs, démarrer ou redémarrer un service, vérifier ses dépendances et son fichier unit systemd, puis résoudre les erreurs empêchant son démarrage.

Lister les services Linux

Sur la plupart des distributions Linux récentes, les services sont gérés par systemd. La commande systemctl permet de les lister, vérifier leur état, les démarrer ou les arrêter et diagnostiquer les services qui rencontrent des erreurs.

Pour afficher les services actuellement chargés par systemd, utilisez :

systemctl list-units --type=service

La commande affiche notamment le nom du service, son état de chargement et son état d’exécution.

Colonne	Description
UNIT	Nom de l’unité systemd, par exemple nginx.service ou ssh.service
LOAD	Indique si le fichier de configuration du service a été correctement chargé
ACTIVE	État général du service : active, inactive, failed, etc.
SUB	État plus précis du service : running, exited, dead, failed, etc.
DESCRIPTION	Description du service

Par défaut, list-units affiche principalement les unités actuellement chargées. Pour afficher tous les services installés, y compris ceux qui ne sont pas actuellement actifs, utilisez plutôt :

systemctl list-unit-files --type=service

Cette commande permet également de connaître leur configuration au démarrage, avec des états tels que enabled, disabled, static ou masked.

Pour afficher uniquement les services actuellement actifs :

systemctl list-units --type=service --state=running

Et pour rechercher un service particulier, vous pouvez filtrer la sortie. Par exemple, pour PHP :

systemctl list-units --type=service | grep -i php

ou pour Nginx :

systemctl list-units --type=service | grep -i nginx

Enfin, si votre objectif est de rechercher directement les services rencontrant un problème, inutile de parcourir toute la liste. systemctl dispose d’une commande dédiée permettant d’afficher uniquement les unités en échec :

systemctl --failed

C’est cette commande qu’il est recommandé d’utiliser en premier lorsqu’un service ne fonctionne plus ou après un problème système.

Le guide complet :

Vérifier les services en échec

Lorsqu’une application ne fonctionne plus ou qu’un serveur présente un dysfonctionnement, commencez par vérifier si systemd a détecté des services en échec.

La commande suivante affiche toutes les unités actuellement dans l’état failed :

systemctl --failed

Vous pouvez obtenir par exemple :

UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
php8.4-fpm.service    loaded failed failed The PHP 8.4 FastCGI Process Manager

Les colonnes ACTIVE et SUB indiquent ici que le service a échoué. Cela signifie que systemd a tenté de le démarrer ou de le maintenir en fonctionnement, mais qu’une erreur l’en a empêché.

Pour limiter la recherche aux services :

systemctl --failed --type=service

Vérifier un service en particulier

Si vous connaissez le nom du service en panne, affichez directement son état avec :

systemctl status nom-du-service

Par exemple :

systemctl status php8.4-fpm

ou :

systemctl status nginx

La sortie de systemctl status fournit plusieurs informations importantes :

• Loaded : indique si l’unité systemd a été correctement chargée.
• Active : indique si le service est actif, arrêté ou en échec.
• Main PID : PID du processus principal lorsqu’il fonctionne.
• Result : raison générale de l’échec.
• Process / ExecStart : commande ayant été exécutée par systemd.
• Les derniers messages du journal associés au service.

Vous pouvez par exemple rencontrer :

Active: failed (Result: exit-code)

Cela indique que le programme lancé par systemd s’est terminé avec un code de retour indiquant une erreur. Il faut alors rechercher le message qui explique pourquoi le programme s’est arrêté.

Comprendre l’état Active

Le champ Active permet de connaître rapidement la situation du service.

État	Signification
active (running)	Le service fonctionne normalement
active (exited)	La commande du service s’est terminée correctement, mais aucun processus ne reste actif. Cela peut être normal pour certains services
inactive (dead)	Le service n’est actuellement pas démarré
failed	Le service a tenté de fonctionner mais a rencontré une erreur
activating	Le service est en cours de démarrage
deactivating	Le service est en cours d’arrêt

Un état active (exited) n’est donc pas nécessairement une erreur. Certains services de type oneshot exécutent une tâche puis se terminent normalement.

Repérer le code d’erreur

Lorsqu’un service échoue, recherchez particulièrement les lignes Result, code et status.

Par exemple :

Active: failed (Result: exit-code)

puis :

code=exited, status=1/FAILURE

Cela signifie que le programme a été lancé mais s’est terminé avec un code d’erreur.

Vous pouvez également rencontrer :

• Result: timeout : le service n’a pas terminé son démarrage ou son arrêt dans le délai prévu.
• Result: signal : le processus a été terminé par un signal.
• Result: core-dump : le processus a planté et généré un core dump.
• Result: exit-code : le programme s’est terminé avec un code d’erreur.
• Result: watchdog : le service n’a pas répondu au mécanisme watchdog dans le délai prévu.

Les dernières lignes affichées par systemctl status donnent souvent une première indication sur l’origine du problème. Toutefois, elles ne représentent qu’une partie des journaux.

Pour obtenir l’historique complet et déterminer pourquoi le service a échoué, l’étape suivante consiste à consulter ses logs avec journalctl -u.

Consulter les services qui ont échoué après le démarrage

Après un redémarrage, il peut être utile d’exécuter :

systemctl --failed

Un service secondaire en échec n’indique pas nécessairement un problème grave. En revanche, si un composant essentiel comme SSH, Nginx, Apache, PHP-FPM, MariaDB/MySQL ou un service réseau apparaît dans cette liste, son échec peut expliquer directement le dysfonctionnement rencontré.

Ne redémarrez pas systématiquement le service immédiatement. Commencez plutôt par consulter son état et ses journaux, afin de conserver les informations permettant d’identifier la cause de l’échec.

La prochaine étape consiste donc à utiliser systemctl status, puis journalctl -u pour déterminer précisément pourquoi le service ne démarre plus.

Consulter les logs d’un service

La commande journalctl permet de consulter les journaux enregistrés par systemd pour un service particulier. C’est l’une des commandes les plus importantes pour comprendre pourquoi un service ne démarre pas, s’arrête brutalement ou rencontre des erreurs.

Pour afficher les journaux d’un service, utilisez l’option -u suivie du nom de l’unité :

sudo journalctl -u nom-du-service

Par exemple, pour Nginx :

sudo journalctl -u nginx

Ou pour PHP-FPM :

sudo journalctl -u php8.4-fpm

Afficher les derniers événements

Lorsque le journal contient beaucoup d’entrées, utilisez l’option -e pour vous positionner directement à la fin :

sudo journalctl -u nginx -e

Vous pouvez également afficher uniquement les dernières lignes :

sudo journalctl -u nginx -n 50

Cela permet de retrouver rapidement les événements enregistrés juste avant l’arrêt ou l’échec du service.

Afficher les logs depuis une période précise

Pour limiter l’analyse aux événements récents :

sudo journalctl -u nginx --since "1 hour ago"

Ou depuis une date et une heure précises :

sudo journalctl -u nginx --since "2026-08-07 08:00:00"

Vous pouvez également définir une période :

sudo journalctl -u nginx --since "2026-08-07 08:00:00" --until "2026-08-07 09:00:00"

Cette méthode est particulièrement utile lorsque vous connaissez approximativement l’heure à laquelle le service est tombé en panne.

Suivre les logs en temps réel

Pour afficher les nouveaux événements au fur et à mesure qu’ils sont générés, utilisez l’option -f :

sudo journalctl -u nginx -f

Laissez cette commande ouverte puis, dans un autre terminal, redémarrez le service ou reproduisez le problème. Vous pourrez ainsi observer immédiatement les erreurs générées.

Utilisez Ctrl + C pour arrêter le suivi.

Rechercher les erreurs importantes

Portez notamment attention aux messages contenant :

• failed ou failure : échec d’une opération.
• permission denied : problème de permissions.
• address already in use : un autre processus utilise déjà le port nécessaire.
• out of memory ou killed process : manque de mémoire.
• segfault ou core dumped : plantage du programme.
• timeout : délai d’attente dépassé.
• dependency failed : une dépendance nécessaire au service est en échec.
• configuration error ou syntax error : erreur dans un fichier de configuration.

Il est également important de vérifier les logs propres à l’application. journalctl peut indiquer qu’un service a échoué sans contenir tous les détails. Nginx, Apache, PHP-FPM, MariaDB ou d’autres applications peuvent écrire des informations supplémentaires dans leurs propres fichiers sous /var/log/.

Le tutoriel :

Après avoir identifié le message d’erreur, évitez de redémarrer le service en boucle. Vérifiez d’abord sa configuration, ses permissions, ses ports et ses dépendances afin de corriger la cause réelle de l’échec.

Activer ou désactiver un service au démarrage

Par défaut, tous les services Linux ne sont pas automatiquement lancés au démarrage du système. Avec systemd, la commande systemctl permet de vérifier si un service est configuré pour démarrer automatiquement, puis d’activer ou de désactiver ce comportement.

Pour vérifier l’état d’un service au démarrage :

systemctl is-enabled nom-du-service

Par exemple :

systemctl is-enabled nginx

La commande peut notamment retourner :

• enabled : le service est activé au démarrage.
• disabled : le service existe mais n’est pas activé automatiquement.
• static : le service ne peut pas être activé directement et est généralement lancé comme dépendance d’une autre unité.
• masked : le service est complètement bloqué et ne peut pas être démarré normalement.

Activer un service au démarrage

Pour configurer un service afin qu’il démarre automatiquement avec Linux :

sudo systemctl enable nom-du-service

Par exemple :

sudo systemctl enable nginx

La commande enable n’a pas pour rôle de démarrer immédiatement le service. Elle configure systemd afin qu’il soit lancé automatiquement lors des prochains démarrages.

Si vous souhaitez à la fois activer et démarrer immédiatement le service :

sudo systemctl enable --now nginx

Vous pouvez ensuite vérifier son état :

systemctl status nginx

Désactiver un service au démarrage

Pour empêcher le démarrage automatique d’un service :

sudo systemctl disable nom-du-service

Par exemple :

sudo systemctl disable nginx

Le service ne sera plus lancé automatiquement au prochain démarrage, mais il n’est pas arrêté immédiatement.

Pour le désactiver et l’arrêter dans la même opération :

sudo systemctl disable --now nginx

Ne pas confondre disable et mask

La commande disable empêche simplement le démarrage automatique. Le service peut toujours être lancé manuellement avec :

sudo systemctl start nginx

À l’inverse, mask bloque complètement son démarrage :

sudo systemctl mask nom-du-service

Une tentative de démarrage retourne alors une erreur indiquant que l’unité est masked.

Pour lever ce blocage :

sudo systemctl unmask nom-du-service

Utilisez mask avec prudence, car un autre service peut dépendre de l’unité que vous bloquez. Pour un simple dépannage ou pour empêcher un service de démarrer avec Linux, disable est généralement suffisant.

Vérifier pourquoi un service ne démarre pas

Lorsqu’un service refuse de démarrer, évitez de le relancer plusieurs fois sans examiner la cause de l’échec. systemctl et journalctl permettent généralement d’obtenir les premières informations nécessaires au diagnostic.

Commencez par afficher l’état du service :

systemctl status nom-du-service

Par exemple :

systemctl status nginx

Examinez particulièrement les lignes Active, Result, ExecStart et les derniers messages affichés. Un état tel que :

Active: failed (Result: exit-code)

indique que le programme a bien été lancé par systemd, mais qu’il s’est terminé avec une erreur.

Consultez ensuite les journaux complets du service :

sudo journalctl -u nom-du-service -e

Pour afficher les événements du démarrage actuel :

sudo journalctl -u nom-du-service -b

Les messages d’erreur permettent généralement de déterminer dans quelle direction poursuivre le diagnostic.

Message ou symptôme	Cause probable	Vérification
Permission denied	Droits incorrects sur un fichier, répertoire ou socket	Vérifier le propriétaire et les permissions avec ls -l ou namei -l
Address already in use	Le port utilisé par le service est déjà occupé	Identifier le processus avec ss -lntup
No such file or directory	Fichier de configuration, exécutable ou autre fichier nécessaire absent	Vérifier les chemins indiqués dans les logs
Configuration error / Syntax error	Erreur dans un fichier de configuration	Utiliser l’outil de validation fourni par l’application
Dependency failed	Un service ou une unité nécessaire est en échec	Examiner les dépendances avec systemctl list-dependencies
Failed with result ‘exit-code’	Le programme s’est terminé avec un code d’erreur	Examiner systemctl status et journalctl -u
Failed with result ‘timeout’	Le service n’a pas démarré dans le délai prévu	Rechercher un blocage, une dépendance ou une ressource inaccessible
Start request repeated too quickly	Le service plante immédiatement et systemd a cessé de tenter de le redémarrer	Corriger l’erreur initiale puis utiliser systemctl reset-failed
Out of memory / Killed process	Processus arrêté à cause d’un manque de mémoire	Vérifier la RAM, le swap et l’OOM Killer
Segmentation fault / core dumped	Le programme a planté	Examiner les journaux et utiliser coredumpctl

Vérifier si un port est déjà utilisé

Pour un serveur Web, une base de données, SSH ou tout autre service réseau, vérifiez que le port nécessaire n’est pas déjà occupé :

sudo ss -lntup

Par exemple, pour rechercher le processus utilisant le port 80 :

sudo ss -lntp | grep ':80 '

Si un autre programme écoute déjà sur ce port, le nouveau service peut échouer avec une erreur Address already in use.

Vérifier les permissions

Une erreur Permission denied peut provenir des droits d’un fichier de configuration, d’un répertoire, d’un certificat, d’un socket ou d’un fichier de log.

Commencez par vérifier les permissions :

ls -l /chemin/vers/fichier

Pour contrôler également les permissions de chaque répertoire constituant le chemin :

namei -l /chemin/vers/fichier

Cette dernière commande est particulièrement pratique lorsqu’un service possède les droits sur le fichier lui-même mais ne peut pas traverser l’un des répertoires parents.

Rechercher un manque de mémoire ou un crash

Si le processus disparaît immédiatement, recherchez une intervention de l’OOM Killer :

sudo journalctl -k | grep -i -E "oom|out of memory|killed process"

En présence d’un segfault ou d’un core dump, vérifiez également :

coredumpctl list

Puis affichez les informations du crash concerné avec :

coredumpctl info

Enfin, lorsqu’un service refuse de démarrer après une modification de sa configuration, vérifiez toujours la syntaxe avant de le redémarrer. De nombreux logiciels fournissent leur propre commande de validation, ce qui permet souvent d’identifier immédiatement la ligne ou le fichier responsable de l’erreur.

Vérifier la configuration avant de redémarrer un service

Lorsqu’un service ne fonctionne plus après la modification d’un fichier de configuration, vérifiez sa syntaxe avant de le redémarrer. De nombreux logiciels Linux disposent d’une commande permettant de valider leur configuration sans interrompre le service actuellement en cours d’exécution.

Cette précaution est particulièrement importante sur un serveur distant : une simple erreur de syntaxe dans Nginx, Apache ou SSH peut empêcher le service de redémarrer et rendre le serveur ou un site inaccessible.

Voici quelques commandes courantes :

Service	Commande de vérification
Nginx	sudo nginx -t
Apache (Debian/Ubuntu)	sudo apache2ctl configtest
Apache (RHEL/Fedora)	sudo httpd -t
PHP-FPM	sudo php-fpm -t ou la commande correspondant à la version installée
OpenSSH	sudo sshd -t
Postfix	sudo postfix check
Samba	sudo testparm

Par exemple, après avoir modifié la configuration de Nginx :

sudo nginx -t

Si la configuration est correcte, vous obtenez notamment :

syntax is ok
test is successful

Vous pouvez alors recharger la configuration sans interrompre les connexions existantes :

sudo systemctl reload nginx

Si le test retourne une erreur, ne redémarrez pas le service immédiatement. Le message indique généralement le fichier et parfois la ligne contenant l’erreur. Corrigez-la, puis relancez le test.

Pour SSH, cette précaution est encore plus importante lorsque vous administrez un serveur à distance. Après avoir modifié sshd_config, vérifiez la configuration avec :

sudo sshd -t

Si aucune erreur n’est affichée, la syntaxe est valide. Gardez toutefois votre session SSH actuelle ouverte jusqu’à ce que vous ayez confirmé qu’une nouvelle connexion fonctionne correctement.

Enfin, lorsque le logiciel le permet, préférez systemctl reload à restart pour une simple modification de configuration. reload demande au service de relire sa configuration sans l’arrêter complètement, tandis que restart provoque un arrêt puis un nouveau démarrage du service.

Réinitialiser l’état failed d’un service

Lorsqu’un service échoue à plusieurs reprises, systemd peut conserver son état failed, même après avoir corrigé la cause du problème. Dans certains cas, systemd peut également cesser temporairement de tenter de démarrer le service lorsque celui-ci plante plusieurs fois en peu de temps.

Vous pouvez vérifier les services actuellement en échec avec :

systemctl --failed

Après avoir identifié et corrigé la cause du problème, réinitialisez l’état d’échec du service avec :

sudo systemctl reset-failed nom-du-service

Par exemple, pour Nginx :

sudo systemctl reset-failed nginx

Vous pouvez ensuite tenter de démarrer à nouveau le service :

sudo systemctl start nginx

Puis vérifiez son état :

systemctl status nginx

La commande reset-failed ne répare pas le service. Elle efface simplement l’état failed enregistré par systemd ainsi que certains compteurs associés aux échecs de démarrage. Il faut donc toujours corriger l’erreur initiale avant de l’utiliser.

Cette commande est notamment utile lorsque vous rencontrez un message de ce type :

Start request repeated too quickly

ou :

Failed with result 'start-limit-hit'

Cela signifie généralement que le service a échoué plusieurs fois dans un intervalle court et que systemd a atteint sa limite de tentatives de démarrage.

Dans ce cas :

• Consultez d’abord les erreurs avec systemctl status nom-du-service.
• Examinez les journaux avec journalctl -u nom-du-service.
• Corrigez la configuration, les permissions ou le problème ayant provoqué les échecs.
• Exécutez systemctl reset-failed nom-du-service.
• Tentez à nouveau de démarrer le service.

Pour réinitialiser l’état failed de toutes les unités systemd en échec, vous pouvez utiliser :

sudo systemctl reset-failed

Cette dernière commande doit surtout être utilisée après avoir vérifié les unités concernées : effacer leur état failed sans comprendre pourquoi elles ont échoué peut masquer temporairement des problèmes qui nécessitent encore une intervention.

Vérifier les dépendances d’un service

Un service Linux peut refuser de démarrer alors que sa propre configuration est correcte parce qu’une unité dont il dépend est arrêtée ou en échec. Avec systemd, ces dépendances peuvent concerner un autre service, un point de montage, un socket, un périphérique ou une cible (target).

Pour afficher les dépendances d’un service, utilisez :

systemctl list-dependencies nom-du-service

Par exemple :

systemctl list-dependencies nginx

La commande affiche l’arborescence des unités nécessaires ou associées au fonctionnement du service.

Pour afficher également les dépendances qui ne sont pas actuellement actives :

systemctl list-dependencies --all nginx

Si une unité apparaît en échec, vérifiez son état :

systemctl status nom-de-unite

Puis consultez ses journaux :

sudo journalctl -u nom-de-unite -e

Rechercher les dépendances inverses

Il peut également être utile de déterminer quels services dépendent d’une unité donnée. Utilisez pour cela :

systemctl list-dependencies --reverse nom-du-service

Par exemple :

systemctl list-dependencies --reverse mariadb

Cela permet d’identifier les unités susceptibles d’être affectées si MariaDB est arrêté ou en échec.

Comprendre les relations entre les unités

Pour obtenir des informations plus précises sur les dépendances déclarées par un service :

systemctl show nom-du-service

Vous pouvez notamment rechercher les propriétés :

• Requires : unités nécessaires au fonctionnement du service.
• Wants : dépendances souhaitées mais généralement moins strictes.
• After et Before : ordre de démarrage entre les unités.
• BindsTo : dépendance forte à une autre unité.
• PartOf : lie certaines opérations, comme l’arrêt ou le redémarrage, à une autre unité.

Par exemple :

systemctl show nginx -p Requires -p Wants -p After

Si systemctl status affiche un message tel que Dependency failed for…, ne cherchez donc pas uniquement une erreur dans le service concerné. Identifiez d’abord l’unité en échec dont il dépend, puis corrigez celle-ci avant de tenter un nouveau démarrage.

Vérifier le fichier unit systemd

Chaque service géré par systemd repose sur un fichier unit (.service) qui décrit notamment la commande à exécuter, l’utilisateur utilisé, les dépendances, les conditions de redémarrage et l’ordre de lancement.

Lorsqu’un service ne démarre plus ou se comporte de manière inattendue, il peut être utile de vérifier le fichier unit réellement utilisé par systemd, notamment si celui-ci a été personnalisé.

Pour afficher la définition complète d’un service :

systemctl cat nom-du-service

Par exemple :

systemctl cat nginx

Cette commande est préférable à l’ouverture directe d’un fichier dans /etc/systemd/system/ ou /usr/lib/systemd/system/, car elle affiche la configuration réellement assemblée par systemd, y compris les éventuels fichiers de surcharge (drop-ins).

Vous pouvez notamment y retrouver les sections suivantes :

Section / directive	Rôle
[Unit]	Informations générales et dépendances du service
After= / Before=	Ordre de démarrage par rapport aux autres unités
Requires= / Wants=	Dépendances du service
[Service]	Paramètres d’exécution du service
ExecStart=	Commande utilisée pour démarrer le service
ExecReload=	Commande utilisée lors d’un rechargement
User= / Group=	Utilisateur et groupe sous lesquels le service s’exécute
Restart=	Comportement à adopter lorsque le processus s’arrête
WorkingDirectory=	Répertoire de travail du processus
Environment=	Variables d’environnement fournies au service
[Install]	Définit notamment comment le service est activé au démarrage

Identifier l’emplacement du fichier unit

Pour connaître précisément le fichier chargé par systemd :

systemctl show nom-du-service -p FragmentPath

Par exemple :

systemctl show nginx -p FragmentPath

Vous pouvez également afficher les éventuels fichiers de surcharge :

systemctl show nginx -p DropInPaths

Les fichiers unit fournis par les paquets sont généralement stockés dans des répertoires comme /usr/lib/systemd/system/ ou /lib/systemd/system/, tandis que les personnalisations administrateur sont généralement placées dans /etc/systemd/system/.

Vérifier les personnalisations d’un service

Un service peut fonctionner avec son fichier unit d’origine mais également avec un ou plusieurs drop-ins qui remplacent certaines directives.

La commande :

systemctl cat nom-du-service

permet de visualiser ces différentes sources dans un même affichage.

C’est particulièrement utile lorsqu’un service fonctionne différemment de sa configuration par défaut après une ancienne modification, une migration ou l’ajout d’une personnalisation systemd.

Pour modifier proprement les paramètres d’un service sans éditer directement le fichier fourni par le paquet, utilisez :

sudo systemctl edit nom-du-service

systemd crée alors une surcharge dans /etc/systemd/system/ qui ne sera pas écrasée lors d’une mise à jour du paquet.

Après toute modification d’un fichier unit ou d’un drop-in, il est nécessaire de demander à systemd de recharger ses fichiers de configuration avec systemctl daemon-reload avant de redémarrer le service.

Recharger systemd après modification d’un service

Lorsque vous modifiez un fichier unit systemd (.service) ou un fichier de surcharge (drop-in), systemd ne prend pas automatiquement en compte les changements. Il faut lui demander de relire les fichiers unit avant de redémarrer le service concerné.

Pour cela, exécutez :

sudo systemctl daemon-reload

Cette commande recharge la configuration de systemd et prend notamment en compte les modifications effectuées dans :

• /etc/systemd/system/
• /usr/lib/systemd/system/
• /lib/systemd/system/
• Les fichiers de surcharge créés avec systemctl edit

Après le rechargement, redémarrez le service concerné :

sudo systemctl restart nom-du-service

Puis vérifiez son état :

systemctl status nom-du-service

Par exemple, après avoir modifié une surcharge pour Nginx :

sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl status nginx

Ne pas confondre daemon-reload, reload et restart

Ces trois commandes ont des fonctions différentes :

Commande	Action
systemctl daemon-reload	Demande à systemd de relire les fichiers unit et leurs surcharges
systemctl reload service	Demande au service lui-même de relire sa configuration, sans l’arrêter lorsque celui-ci prend en charge cette opération
systemctl restart service	Arrête puis redémarre complètement le service

Ainsi, après avoir modifié :

/etc/systemd/system/mon-service.service

ou créé une surcharge avec :

sudo systemctl edit mon-service

utilisez :

sudo systemctl daemon-reload
sudo systemctl restart mon-service

En revanche, si vous avez uniquement modifié le fichier de configuration de l’application, par exemple nginx.conf, un daemon-reload n’est généralement pas nécessaire. Après avoir vérifié la syntaxe, vous pouvez simplement recharger Nginx :

sudo nginx -t
sudo systemctl reload nginx

Retenez donc que daemon-reload concerne la configuration de systemd, tandis que reload concerne la configuration du service ou de l’application.

Tableau des commandes systemctl pour dépanner un service

Le tableau suivant récapitule les principales commandes systemctl à connaître pour vérifier, diagnostiquer et réparer un service géré par systemd.

Commande	Description
systemctl list-units --type=service	Lister les services actuellement chargés
systemctl list-unit-files --type=service	Lister tous les fichiers de services installés et leur état d’activation
systemctl --failed	Afficher les unités actuellement en échec
systemctl status service	Afficher l’état détaillé d’un service et ses derniers messages
systemctl is-active service	Vérifier rapidement si un service est actif
systemctl is-enabled service	Vérifier si un service est activé au démarrage
systemctl start service	Démarrer un service
systemctl stop service	Arrêter un service
systemctl restart service	Arrêter puis redémarrer un service
systemctl reload service	Recharger la configuration d’un service sans l’arrêter, lorsque cette fonction est prise en charge
systemctl enable service	Activer le démarrage automatique d’un service
systemctl enable --now service	Activer un service au démarrage et le démarrer immédiatement
systemctl disable service	Désactiver le démarrage automatique d’un service
systemctl disable --now service	Désactiver le service au démarrage et l’arrêter immédiatement
systemctl mask service	Bloquer complètement le démarrage d’un service
systemctl unmask service	Lever le blocage appliqué avec mask
systemctl reset-failed service	Effacer l’état failed et les compteurs d’échec d’un service
systemctl list-dependencies service	Afficher les dépendances d’un service
systemctl list-dependencies --reverse service	Afficher les unités qui dépendent du service
systemctl cat service	Afficher le fichier unit et les éventuels fichiers de surcharge (drop-ins)
systemctl show service	Afficher toutes les propriétés systemd d’un service
systemctl edit service	Créer ou modifier proprement une surcharge du fichier unit
systemctl daemon-reload	Demander à systemd de relire les fichiers unit après une modification

Pour un diagnostic rapide d’un service qui ne démarre plus, commencez généralement par ces trois commandes :

systemctl status nom-du-service
sudo journalctl -u nom-du-service -e
systemctl list-dependencies nom-du-service

Si le service a échoué plusieurs fois et que systemd refuse désormais de le relancer avec un message comme Start request repeated too quickly, corrigez d’abord l’erreur puis utilisez :

sudo systemctl reset-failed nom-du-service
sudo systemctl start nom-du-service

Enfin, n’oubliez pas que systemctl et journalctl sont complémentaires : systemctl permet surtout de connaître et modifier l’état du service, tandis que journalctl permet d’analyser ses journaux afin de déterminer pourquoi il a échoué.

L’article Vérifier et dépanner un service sous Linux avec systemctl et journalctl est apparu en premier sur malekal.com.

Un PC ou un serveur Linux qui plante, se bloque, ralentit fortement ou redémarre de manière inattendue peut avoir de nombreuses causes. Le problème peut provenir d’un processus qui monopolise le CPU ou la mémoire RAM, d’un manque de mémoire et de l’OOM Killer, d’un service en échec, d’un disque saturé, d’une erreur du système de fichiers, d’un Kernel Panic ou encore d’une défaillance matérielle.

Linux fournit heureusement de nombreux outils permettant de retrouver l’origine d’un plantage. Les commandes dmesg et journalctl permettent d’examiner les événements du noyau et du système, tandis que top, free, systemctl, coredumpctl ou encore les journaux du démarrage précédent permettent d’identifier une surcharge, un crash d’application ou un redémarrage anormal.

Dans ce guide, découvrez une méthode complète pour diagnostiquer un plantage ou un blocage sous Linux, analyser les journaux, vérifier les ressources du système et déterminer si le problème est logiciel, matériel, lié au stockage, à la mémoire ou au réseau.

Identifier le type de plantage

Avant de lancer des commandes de diagnostic, commencez par déterminer ce qui s’est réellement produit sur votre système Linux. Un ordinateur complètement figé, un serveur inaccessible en SSH ou une application qui ne répond plus peuvent donner l’impression que Linux a planté alors que les causes sont très différentes.

Par exemple, un serveur peut continuer à fonctionner normalement alors qu’un problème réseau empêche simplement d’y accéder. À l’inverse, un manque de mémoire peut provoquer l’arrêt brutal de certains processus sans entraîner le plantage complet du système.

Le tableau suivant permet d’orienter les premières recherches.

Symptôme	Causes possibles	Vérifications prioritaires
Linux est complètement figé	Kernel Panic, pilote défectueux, problème RAM, GPU ou matériel	journalctl, dmesg, Kernel Panic, RAM
Le PC ou serveur redémarre brutalement	Kernel Panic, watchdog, surchauffe, alimentation ou panne matérielle	last -x, journalctl -b -1, températures
Le serveur devient inaccessible en SSH	Réseau, pare-feu, service SSH arrêté, surcharge CPU/RAM ou système réellement bloqué	Ping, SSH, systemctl, top, journaux
Linux devient extrêmement lent	CPU saturé, manque de RAM, swap intensif, disque lent ou processus bloqués en I/O	top, free -h, vmstat, iostat
Une application ou un service s’arrête	Crash, Segmentation Fault, OOM Killer, erreur de configuration	systemctl status, journalctl -u, coredumpctl
Un processus disparaît sans raison apparente	OOM Killer, crash ou arrêt par un autre processus	journalctl, recherche de Killed process et Out of memory
Des erreurs de lecture/écriture apparaissent	Disque défectueux, SSD/NVMe en panne, système de fichiers endommagé	dmesg, journalctl, smartctl
Le système passe en lecture seule	Erreurs du système de fichiers ou du périphérique de stockage	dmesg, erreurs EXT4/XFS/Btrfs, SMART
L’interface graphique se fige ou affiche un écran noir	Pilote graphique, GPU, serveur d’affichage ou environnement de bureau	journalctl, dmesg, journaux graphiques
Le système se bloque sous forte charge	RAM insuffisante, OOM, surchauffe, alimentation ou problème matériel	free -h, top, sensors, journaux kernel

Il est également important de noter le contexte dans lequel le problème apparaît : pendant une sauvegarde, lors d’une forte charge PHP/MySQL, durant une copie importante de fichiers, après une mise à jour du noyau, au démarrage ou de manière totalement aléatoire. Ces informations permettent souvent de réduire considérablement le champ des recherches.

Après un redémarrage consécutif à un plantage, évitez de vous limiter aux journaux du démarrage actuel. Les informations les plus intéressantes se trouvent souvent dans les journaux du démarrage précédent. Nous verrons notamment comment utiliser journalctl -b -1 pour retrouver les événements qui ont précédé le crash.

La première étape consiste toutefois à vérifier si Linux a réellement redémarré et à déterminer depuis combien de temps le système fonctionne.

Vérifier les journaux du noyau avec dmesg

La commande dmesg permet de consulter les messages générés par le noyau Linux depuis le démarrage du système. Elle est particulièrement utile lorsqu’un PC ou un serveur Linux se bloque, devient instable ou rencontre un problème matériel.

Les messages du noyau peuvent notamment révéler des erreurs de disque, des problèmes de système de fichiers, un manque de mémoire, une surchauffe, un pilote défaillant ou encore une erreur matérielle.

Pour afficher les messages du noyau, ouvrez un terminal puis exécutez :

sudo dmesg

La quantité d’informations peut être importante. Pour afficher uniquement les erreurs et avertissements :

sudo dmesg --level=err,warn

Vous pouvez également utiliser l’option -T afin d’obtenir des dates et heures plus faciles à lire :

sudo dmesg -T

Pour rechercher rapidement les messages susceptibles d’indiquer un problème :

sudo dmesg -T | grep -i -E "error|fail|critical|warning"

Le guide complet :

Rechercher les erreurs de disque et de système de fichiers

Un problème de disque dur, de SSD ou de système de fichiers peut provoquer des ralentissements importants, des blocages et parfois un plantage complet de Linux.

Pour rechercher ce type d’erreur :

sudo dmesg -T | grep -i -E "i/o error|buffer i/o|nvme|ata|sata|ext4|xfs|btrfs"

Portez notamment attention aux messages contenant I/O error, Buffer I/O error, EXT4-fs error, XFS ou des erreurs associées à un périphérique NVMe/SATA.

Rechercher un manque de mémoire

Lorsque Linux manque de mémoire RAM et de swap, le noyau peut déclencher l’OOM Killer (Out Of Memory Killer) afin de terminer un ou plusieurs processus et récupérer de la mémoire.

Pour rechercher ces événements :

sudo dmesg -T | grep -i -E "oom|out of memory|killed process"

Un message contenant par exemple Out of memory suivi de Killed process indique qu’un processus a probablement été arrêté à cause d’un manque de mémoire.

Nous verrons plus loin comment diagnostiquer précisément les problèmes de RAM, swap et OOM Killer.

Rechercher les erreurs matérielles et les surchauffes

Vous pouvez également rechercher les messages susceptibles d’indiquer une défaillance matérielle :

sudo dmesg -T | grep -i -E "hardware error|mce|edac|thermal|throttling"

Des messages contenant Hardware Error, Machine Check Exception (MCE) ou EDAC peuvent signaler une erreur détectée au niveau du processeur, de la mémoire ou d’un autre composant matériel.

Les mentions thermal ou throttling peuvent quant à elles indiquer un problème de température ou une réduction automatique des performances pour protéger le matériel.

Voici quelques messages importants que vous pouvez rencontrer :

Message	Cause possible
I/O error	Erreur de disque, SSD, contrôleur ou connexion au périphérique
Buffer I/O error	Échec d’une opération de lecture ou d’écriture
EXT4-fs error / XFS / Btrfs error	Problème du système de fichiers
Out of memory	Mémoire disponible insuffisante
Killed process	Processus terminé, notamment par l’OOM Killer
segfault	Plantage d’un processus avec erreur de segmentation
Hardware Error / MCE	Erreur matérielle détectée
EDAC	Erreur liée notamment à la mémoire avec prise en charge EDAC
thermal / throttling	Température élevée ou limitation thermique
NVRM / amdgpu / i915	Message pouvant concerner le GPU ou son pilote
watchdog	Blocage ou absence de réponse détectée

Un message contenant error ou warning ne signifie toutefois pas systématiquement qu’il est responsable du plantage. Il faut surtout rechercher les événements apparus juste avant le problème et les erreurs qui se répètent.

Enfin, dmesg concerne essentiellement les messages du noyau du démarrage en cours. Si Linux a complètement planté puis redémarré, les informations qui ont précédé le crash peuvent ne plus être présentes dans le buffer actuel. Dans ce cas, il faut examiner les journaux persistants du démarrage précédent avec journalctl, notamment avec journalctl -b -1 et journalctl -k -b -1.

Le tutoriel :

Vérifier les derniers redémarrages et arrêts

Lorsqu’un serveur ou un PC Linux semble avoir planté, il est utile de déterminer s’il a réellement redémarré et si ce redémarrage a été précédé d’un arrêt normal. Un redémarrage brutal peut notamment être provoqué par un Kernel Panic, un watchdog, une coupure d’alimentation, une surchauffe ou un problème matériel.

La commande last permet de consulter l’historique des connexions, mais également des démarrages et arrêts du système grâce à l’option -x.

Exécutez :

last -x

Vous obtenez des lignes contenant notamment :

reboot   system boot  6.8.0-63-generic   Thu Aug  7 08:42   still running
shutdown system down  6.8.0-63-generic   Wed Aug  6 23:15 - 23:16

Les entrées importantes sont :

Entrée	Signification
reboot	Démarrage du système
shutdown	Arrêt normal de Linux
runlevel	Changement de niveau d’exécution ou de cible systemd
crash	Une session s’est terminée sans arrêt propre enregistré
still running	Le système ou la session concernée est toujours actif

Pour afficher uniquement les redémarrages :

last reboot

Vous pouvez également afficher uniquement les arrêts :

last -x shutdown

Repérer un redémarrage brutal

Ce qui nous intéresse particulièrement lors d’un diagnostic est la succession des événements.

Lors d’un arrêt normal, vous devez généralement retrouver une entrée shutdown avant le démarrage suivant :

shutdown system down ...
reboot   system boot ...

En revanche, si vous observez un nouveau reboot sans événement shutdown correspondant juste avant, le système peut avoir subi un redémarrage non propre.

Cela peut se produire après :

• Une coupure électrique ou un problème d’alimentation.
• Un appui prolongé sur le bouton Marche/Arrêt.
• Un reset matériel.
• Un Kernel Panic suivi d’un redémarrage automatique.
• Le déclenchement d’un watchdog.
• Une défaillance matérielle.

La commande last permet donc de confirmer qu’un redémarrage anormal a eu lieu, mais elle n’en indique généralement pas la cause.

Une fois le redémarrage suspect identifié, notez sa date et son heure puis examinez les événements qui l’ont précédé dans le journal du démarrage précédent :

journalctl -b -1

Pour vous concentrer uniquement sur les messages du noyau :

journalctl -k -b -1

C’est souvent dans les dernières secondes ou minutes précédant le redémarrage que vous trouverez les informations les plus utiles : erreur disque, OOM Killer, Kernel Panic, problème matériel, watchdog ou autre anomalie.

Examiner les journaux avec journalctl

La commande journalctl permet de consulter les journaux enregistrés par systemd-journald. Lorsqu’un PC ou un serveur Linux plante, redémarre brutalement ou devient instable, c’est l’un des premiers outils à utiliser pour rechercher les événements qui ont précédé le problème.

Contrairement à dmesg, qui permet surtout de consulter les messages du noyau du démarrage actuel, journalctl peut conserver les journaux des démarrages précédents, à condition que la journalisation persistante soit activée.

Pour afficher les événements du démarrage actuel :

sudo journalctl -b

Pour afficher uniquement les erreurs :

sudo journalctl -b -p err

Examiner le démarrage précédent après un plantage

Si Linux a planté puis redémarré, le plus intéressant est généralement d’examiner le démarrage précédent :

sudo journalctl -b -1

Commencez par regarder les dernières lignes du journal, car elles correspondent aux événements enregistrés juste avant l’arrêt ou le plantage :

sudo journalctl -b -1 -e

Pour limiter l’affichage aux erreurs du démarrage précédent :

sudo journalctl -b -1 -p err

Vous pouvez également afficher uniquement les messages du noyau Linux :

sudo journalctl -k -b -1

Cette dernière commande est particulièrement utile pour rechercher une erreur matérielle, un Kernel Panic, un problème de stockage, une erreur de pilote ou un manque de mémoire ayant précédé le plantage.

Rechercher les événements autour de l’heure du plantage

Si vous connaissez approximativement l’heure à laquelle le problème s’est produit, utilisez les options --since et --until afin de réduire considérablement le nombre de messages à analyser.

Par exemple :

sudo journalctl --since "2026-08-07 02:00:00" --until "2026-08-07 02:30:00"

Vous pouvez ainsi examiner uniquement les événements enregistrés dans les minutes précédant le crash.

Portez particulièrement attention aux messages contenant des termes tels que :

• Out of memory, OOM ou Killed process : manque de mémoire et intervention de l’OOM Killer.
• I/O error : problème d’entrée/sortie, souvent lié au stockage.
• EXT4-fs error, XFS ou Btrfs : erreur du système de fichiers.
• segfault : plantage d’un processus.
• kernel panic : erreur fatale du noyau.
• watchdog : système ou composant devenu non réactif.
• thermal ou throttling : problème de température.
• Hardware Error, MCE ou EDAC : erreur matérielle.

Enfin, ne vous focalisez pas uniquement sur la dernière erreur affichée. Un message d’erreur peut être la conséquence du plantage et non sa cause. Examinez plutôt la chronologie des événements dans les secondes ou minutes précédant le problème.

Les guides à consulter :

Rechercher un Kernel Panic

Un Kernel Panic correspond à une erreur critique du noyau Linux dont celui-ci ne peut pas se remettre normalement. Selon la configuration du système, Linux peut alors se figer complètement, afficher un message d’erreur à l’écran ou redémarrer automatiquement après quelques secondes.

Les Kernel Panic peuvent avoir de nombreuses origines : pilote défectueux, module du noyau, problème de RAM, erreur CPU, système de fichiers endommagé, périphérique de stockage défaillant ou bug du noyau.

Après un redémarrage consécutif à un plantage, commencez par examiner les messages du noyau du démarrage précédent :

sudo journalctl -k -b -1

Pour rechercher directement les occurrences de Kernel Panic :

sudo journalctl -k -b -1 | grep -i -E "kernel panic|panic|oops"

Il est également intéressant de rechercher les erreurs généralement associées à un plantage du noyau :

sudo journalctl -k -b -1 | grep -i -E "panic|oops|bug:|call trace|fatal|mce|hardware error"

Portez notamment attention aux messages suivants :

Message	Signification possible
Kernel panic – not syncing	Le noyau a rencontré une erreur fatale et ne peut plus continuer son exécution.
Oops	Erreur grave du noyau qui n’entraîne pas nécessairement immédiatement un Kernel Panic.
BUG:	Détection d’un comportement anormal dans le noyau ou un module.
Call Trace	Pile d’appels permettant d’identifier les fonctions et modules impliqués dans le crash.
Unable to mount root fs	Le noyau ne parvient pas à monter le système de fichiers racine.
Machine Check Exception (MCE)	Le processeur a détecté une erreur matérielle.
Hardware Error	Erreur matérielle remontée au noyau.

Identifier le module ou le pilote impliqué

Lorsqu’un Kernel Panic affiche une Call Trace, recherchez les noms de modules présents juste avant ou dans la trace. Ils peuvent permettre d’identifier un pilote responsable du plantage.

Par exemple, des références répétées à des modules tels que nvidia, amdgpu, i915, un pilote réseau ou un module tiers peuvent orienter le diagnostic.

Vérifiez également si le problème est apparu après :

• Une mise à jour du noyau Linux.
• L’installation ou la mise à jour d’un pilote graphique.
• L’ajout d’un module DKMS.
• Une mise à jour importante du système.
• L’installation d’un nouveau matériel.

Si le problème a commencé après une mise à jour du noyau, vous pouvez temporairement démarrer sur un noyau précédent depuis GRUB afin de vérifier si le plantage disparaît.

Que faire si aucun Kernel Panic n’est enregistré ?

Un Kernel Panic ne peut pas toujours être écrit dans les journaux. Si le noyau ou le stockage devient inutilisable immédiatement, le système peut planter avant que les dernières informations soient enregistrées sur le disque.

Ainsi, l’absence de kernel panic dans journalctl ne permet pas d’exclure totalement cette cause.

Si le système redémarre brutalement sans laisser de trace exploitable, poursuivez le diagnostic en recherchant notamment un problème de RAM, une surchauffe, une défaillance du stockage ou une erreur matérielle. Il faudra également vérifier si le redémarrage a été déclenché par un watchdog ou une panne d’alimentation.

Vérifier un manque de mémoire et l’OOM Killer

Un manque de mémoire RAM peut provoquer d’importants ralentissements, rendre un serveur presque inaccessible ou entraîner l’arrêt brutal de certains processus. Sous Linux, lorsque la mémoire disponible devient insuffisante et que le système ne peut plus satisfaire les demandes d’allocation, le noyau peut déclencher l’OOM Killer (Out Of Memory Killer).

Son rôle est de sélectionner et de terminer un ou plusieurs processus afin de libérer rapidement de la mémoire et d’éviter, lorsque cela est possible, le blocage complet du système.

Sur un serveur Web, par exemple, l’OOM Killer peut arrêter un processus PHP-FPM, MySQL/MariaDB, Java ou tout autre service consommant beaucoup de mémoire.

Vérifier l’utilisation de la RAM et du swap

Commencez par afficher l’état de la mémoire :

free -h

Vous obtenez un résultat similaire à celui-ci :

               total        used        free      shared  buff/cache   available
Mem:            15Gi        11Gi       520Mi       650Mi        3.5Gi        3.1Gi
Swap:          4.0Gi       2.8Gi       1.2Gi

Ne vous fiez pas uniquement à la colonne free. Linux utilise volontairement la mémoire inutilisée comme cache. La colonne available est généralement plus pertinente pour estimer la quantité de mémoire encore disponible pour les applications.

Portez notamment attention aux situations suivantes :

• available devient très faible.
• Le swap est fortement utilisé.
• L’utilisation du swap augmente rapidement.
• Le système devient lent alors que la RAM est presque entièrement utilisée.

Pour surveiller l’évolution de la mémoire en temps réel, utilisez également :

vmstat 2

Les colonnes si (swap in) et so (swap out) permettent de détecter une activité importante du swap. Des valeurs élevées et persistantes peuvent indiquer une pression mémoire importante.

Rechercher le déclenchement de l’OOM Killer

Après un plantage ou l’arrêt inexpliqué d’un service, recherchez les événements liés à un manque de mémoire :

sudo journalctl -k | grep -i -E "oom|out of memory|killed process"

Si le problème s’est produit avant le dernier redémarrage, examinez plutôt les messages du noyau du démarrage précédent :

sudo journalctl -k -b -1 | grep -i -E "oom|out of memory|killed process"

Vous pouvez également rechercher ces messages avec dmesg pour le démarrage actuel :

sudo dmesg -T | grep -i -E "oom|out of memory|killed process"

Un événement caractéristique ressemble à ceci :

Out of memory: Killed process 18452 (php-fpm) total-vm:...

ou :

oom-kill:constraint=CONSTRAINT_NONE...
Killed process 18452 (php-fpm)...

Dans cet exemple, le noyau a décidé de terminer un processus PHP-FPM afin de récupérer de la mémoire. Si vous retrouvez ce type de message juste avant qu’un site Web, une base de données ou un autre service devienne indisponible, l’OOM Killer est probablement directement impliqué.

Identifier les processus qui consomment le plus de mémoire

Pour afficher les processus classés par consommation de RAM :

ps aux --sort=-%mem | head -20

Vous pouvez également utiliser :

top

puis trier les processus par mémoire avec la touche M.

Cela permet d’identifier rapidement un processus dont la consommation augmente anormalement, par exemple php-fpm, mysqld, java, un serveur applicatif ou un script mal configuré.

Il faut toutefois rechercher la cause de la consommation excessive plutôt que simplement arrêter le processus concerné. Un OOM peut être provoqué par une fuite mémoire, trop de workers PHP-FPM, une base de données mal dimensionnée, une application trop gourmande, une absence de swap ou simplement une quantité de RAM insuffisante.

Si l’OOM Killer apparaît régulièrement dans les journaux, surveillez ensuite plus précisément les processus qui consomment le CPU et la mémoire, ainsi que la charge globale du système.

Identifier les processus qui consomment CPU et RAM

Une consommation excessive du processeur ou de la mémoire RAM peut fortement ralentir Linux, rendre un serveur difficilement accessible et, dans les cas extrêmes, provoquer l’arrêt de services ou le déclenchement de l’OOM Killer.

La première étape consiste donc à identifier les processus qui utilisent le plus de ressources.

Surveiller les processus avec top

La commande top affiche en temps réel l’utilisation du processeur, de la mémoire et les processus actifs :

top

Dans la liste des processus, surveillez principalement les colonnes suivantes :

Colonne	Description
PID	Identifiant du processus
USER	Utilisateur qui exécute le processus
%CPU	Pourcentage de processeur utilisé
%MEM	Pourcentage de mémoire RAM utilisé
RES	Quantité de mémoire physique actuellement utilisée par le processus
VIRT	Espace mémoire virtuel associé au processus
S	État actuel du processus
TIME+	Temps CPU total consommé par le processus

Dans top, vous pouvez notamment utiliser :

• P pour classer les processus par consommation CPU.
• M pour les classer par consommation mémoire.
• 1 pour afficher séparément l’activité de chaque cœur ou processeur logique.
• q pour quitter.

Un processus qui reste durablement en tête avec une valeur %CPU ou %MEM élevée mérite d’être examiné.

Afficher les processus consommant le plus de CPU

Vous pouvez également obtenir directement les processus les plus gourmands en processeur avec ps :

ps aux --sort=-%cpu | head -20

Pour afficher seulement les informations essentielles :

ps -eo pid,user,comm,%cpu,%mem --sort=-%cpu | head -20

Cette commande est particulièrement pratique lorsqu’un serveur présente une charge CPU anormalement élevée.

Afficher les processus consommant le plus de RAM

Pour classer les processus selon leur consommation mémoire :

ps aux --sort=-%mem | head -20

Ou avec un affichage plus compact :

ps -eo pid,user,comm,%cpu,%mem,rss --sort=-%mem | head -20

La colonne RSS correspond approximativement à la quantité de mémoire physique actuellement occupée par le processus.

Sur un serveur Web, vous pouvez par exemple constater qu’un grand nombre de processus php-fpm, mysqld, mariadbd, Apache ou Java utilisent une part importante de la RAM.

Repérer les processus bloqués en attente d’I/O

Une forte charge système ne provient pas nécessairement d’une utilisation élevée du CPU. Des processus peuvent être bloqués en attente d’une opération d’entrée/sortie, notamment lorsqu’un disque ou un système de fichiers rencontre des problèmes.

Dans top, examinez la colonne S correspondant à l’état du processus.

Un processus avec l’état :

D

est en Uninterruptible Sleep, généralement parce qu’il attend la fin d’une opération d’I/O.

Pour rechercher ces processus :

ps -eo state,pid,ppid,comm,wchan:32 | awk '$1=="D"'

Quelques processus passant brièvement dans cet état ne sont pas forcément anormaux. En revanche, de nombreux processus durablement bloqués en état D peuvent indiquer un problème de disque, de stockage réseau (NFS), de système de fichiers ou de périphérique.

Dans ce cas, vérifiez les messages du noyau avec :

sudo dmesg -T

et :

sudo journalctl -k

Ne pas se limiter au processus qui consomme le plus

Un processus utilisant momentanément 100 % d’un cœur CPU n’indique pas nécessairement un problème. Une compression, une compilation, une sauvegarde ou une requête de base de données peut légitimement solliciter fortement le processeur pendant quelques secondes ou minutes.

Ce qui doit davantage attirer votre attention est une consommation élevée et persistante, notamment lorsqu’elle coïncide avec les ralentissements ou les blocages observés.

De même, si plusieurs processus d’un même service consomment beaucoup de ressources, recherchez la cause avant de simplement les terminer. Par exemple, de nombreux workers PHP-FPM fortement sollicités peuvent être la conséquence d’un trafic important, d’un script PHP lent, d’une requête SQL bloquée ou d’une mauvaise configuration du pool PHP-FPM.

L’étape suivante consiste alors à examiner la charge système (Load Average) afin de déterminer si le processeur est réellement saturé ou si les processus attendent principalement des ressources comme le disque.

Vérifier la charge système (Load Average)

Le Load Average permet d’évaluer la charge globale d’un système Linux. Il est particulièrement utile lorsqu’un PC ou un serveur devient lent, répond difficilement ou semble se bloquer alors que l’utilisation du processeur ne paraît pas forcément très élevée.

Vous pouvez afficher le Load Average avec la commande :

uptime

Vous obtenez par exemple :

10:42:15 up 32 days, 4:18, 2 users, load average: 1.25, 2.10, 1.84

Les trois valeurs correspondent à la charge moyenne observée respectivement pendant les 1, 5 et 15 dernières minutes.

Vous retrouvez également ces valeurs en haut de l’écran avec :

top

Contrairement à une idée fréquente, le Load Average ne correspond pas directement au pourcentage d’utilisation du processeur. Il prend notamment en compte les tâches prêtes à être exécutées ainsi que certaines tâches bloquées en attente d’une ressource, notamment des opérations d’entrée/sortie (I/O).

Ainsi, un serveur peut présenter un Load Average très élevé avec un CPU relativement peu utilisé si de nombreux processus sont bloqués dans l’attente d’un disque, d’un stockage réseau ou d’un autre périphérique.

Interpréter le Load Average

Il faut comparer la charge au nombre de processeurs logiques disponibles.

Vous pouvez connaître ce nombre avec :

nproc

Par exemple, sur un système disposant de 8 CPU logiques :

Load Average	Interprétation
1	Charge faible
4	Environ la moitié de la capacité disponible est sollicitée
8	Les CPU sont globalement pleinement occupés
16	La demande dépasse fortement les ressources disponibles

Ces valeurs restent toutefois indicatives : un Load Average élevé ne signifie pas automatiquement que le processeur est saturé.

Déterminer si la charge vient du CPU ou des I/O

Commencez par examiner top.

Si le CPU est fortement utilisé et qu’un ou plusieurs processus présentent un %CPU élevé, recherchez le processus responsable.

En revanche, si le Load Average est élevé alors que le CPU reste relativement disponible, recherchez des processus en état D (Uninterruptible Sleep) :

ps -eo state,pid,ppid,comm,wchan:32 | awk '$1=="D"'

De nombreux processus durablement en état D peuvent indiquer un problème d’I/O, par exemple :

• Un disque dur ou SSD très lent ou défaillant.
• Des erreurs du système de fichiers.
• Un stockage NFS indisponible.
• Un périphérique bloqué.
• Une saturation importante des entrées/sorties.

Dans ce cas, vérifiez également les messages du noyau :

sudo dmesg -T

ainsi que les journaux :

sudo journalctl -k

Une augmentation brutale et persistante du Load Average constitue donc un indicateur important, mais il faut toujours rechercher ce qui provoque cette charge avant de conclure à un problème CPU.

Les tutoriels :

Vérifier l’espace disque

Un disque ou une partition pleine peut provoquer des ralentissements, empêcher certains services de démarrer ou rendre Linux instable. C’est particulièrement problématique lorsque les partitions /, /var ou /tmp n’ont plus d’espace disponible.

Pour vérifier rapidement l’espace disque :

df -h

Surveillez la colonne Use% et recherchez les systèmes de fichiers proches de 100 % d’utilisation.

Vérifiez également les inodes, car une partition peut ne plus accepter de nouveaux fichiers alors qu’il reste encore de l’espace disque :

df -i

Si une partition est saturée, identifiez ensuite les répertoires et fichiers qui occupent le plus d’espace avant de poursuivre le diagnostic.

Les tutoriels :

Vérifier les inodes

Même lorsqu’il reste de l’espace disque disponible, Linux peut devenir incapable de créer de nouveaux fichiers si tous les inodes sont utilisés. Ce problème peut notamment provoquer des erreurs d’écriture, empêcher la création de fichiers temporaires ou perturber certains services.

Pour vérifier l’utilisation des inodes :

df -i

Surveillez particulièrement les colonnes IUse% et IFree. Si IUse% atteint 100 %, le système de fichiers ne peut plus créer de nouveaux fichiers, même s’il dispose encore de plusieurs gigaoctets d’espace libre.

Ce problème est généralement provoqué par la présence d’un très grand nombre de petits fichiers, par exemple dans un répertoire de cache, de sessions PHP, de logs ou de fichiers temporaires.

Si les inodes sont saturés, recherchez les répertoires contenant un nombre anormalement élevé de fichiers avant de les nettoyer.

Pour aller plus loin, reportez-vous à ce guide :

Vérifier les services en échec

Un problème avec un service Linux peut parfois donner l’impression que le système entier est en panne. Sur un serveur, l’arrêt de Nginx, Apache, PHP-FPM, MariaDB/MySQL, SSH ou d’un autre service essentiel peut rendre un site ou une fonctionnalité inaccessible alors que Linux continue de fonctionner normalement.

Sur les distributions utilisant systemd, commencez par rechercher les services en échec :

systemctl --failed

Si un service apparaît avec l’état failed, vérifiez son état :

systemctl status nom-du-service

Puis consultez ses journaux :

sudo journalctl -u nom-du-service -e

Ces informations permettent généralement de déterminer si l’échec provient d’une erreur de configuration, d’un problème de permissions, d’une dépendance, d’un port déjà utilisé, d’un manque de ressources ou du plantage de l’application.

Pour aller plus loin et apprendre à diagnostiquer puis remettre en fonctionnement un service en échec :

Pour aller plus loin :

Diagnostiquer le matériel sous Linux

Si les journaux ne permettent pas d’identifier clairement l’origine du plantage, il est recommandé de vérifier l’état du matériel du PC ou du serveur Linux. Une RAM instable, un SSD défaillant, une surchauffe ou des erreurs CPU/PCIe peuvent provoquer des blocages et des redémarrages difficiles à distinguer d’un problème logiciel.

Linux fournit de nombreux outils permettant de rechercher ces anomalies directement en ligne de commandes. Vous pouvez notamment contrôler :

• La mémoire RAM et rechercher les erreurs EDAC.
• Le processeur et les erreurs MCE (Machine Check Exception).
• Les disques durs, SSD SATA et NVMe avec SMART et les journaux du noyau.
• Les températures et le thermal throttling.
• Les périphériques PCIe et les erreurs AER.
• Les erreurs matérielles enregistrées par dmesg et journalctl.

Si les plantages sont aléatoires, accompagnés de Kernel Panic, segfault, I/O error, Hardware Error, MCE, erreurs PCIe ou de redémarrages inexpliqués, poursuivez le diagnostic avec le guide dédié :

Le guide ultime à suivre :

Examiner les crashs avec coredumpctl

Lorsqu’une application se termine brutalement avec une erreur de segmentation (segfault) ou un autre signal fatal, systemd peut enregistrer un core dump contenant des informations sur l’état du processus au moment du crash.

La commande coredumpctl permet de retrouver ces plantages et constitue un outil particulièrement utile lorsqu’un programme ou un service plante régulièrement sans explication apparente.

Pour afficher les crashs enregistrés :

coredumpctl list

Vous obtenez notamment le PID, le nom de l’exécutable, l’utilisateur, le signal ayant provoqué le crash et la date de l’événement.

Pour afficher les informations détaillées du dernier crash :

coredumpctl info

Vous pouvez également cibler un programme particulier :

coredumpctl info php-fpm

ou rechercher ses différents crashs :

coredumpctl list php-fpm

Portez particulièrement attention aux champs Signal, Executable, Command Line et aux éventuelles informations de pile d’appels. Un signal SIGSEGV indique par exemple une erreur de segmentation, souvent liée à un bug du programme, une bibliothèque ou une extension défectueuse, voire plus rarement à un problème matériel.

Pour analyser plus profondément un core dump avec GDB, utilisez :

coredumpctl debug

ou pour un programme particulier :

coredumpctl debug nom-du-programme

Cette analyse est surtout destinée aux utilisateurs avancés et aux développeurs, mais elle peut permettre d’identifier précisément la bibliothèque, l’extension ou la fonction dans laquelle le programme a planté.

Si coredumpctl ne retourne aucun résultat, cela ne signifie pas nécessairement qu’aucun programme n’a crashé : la collecte des core dumps peut être désactivée ou limitée par la configuration de systemd. Dans ce cas, recherchez également les messages segfault, core dumped ou SIGSEGV dans journalctl.

Vérifier si le problème est réellement réseau

Sur un serveur Linux administré à distance, une perte de connexion SSH ou l’indisponibilité d’un site Web ne signifie pas forcément que Linux a planté. Le système peut continuer à fonctionner normalement alors qu’un problème réseau empêche simplement d’y accéder.

Avant de rechercher une panne matérielle ou un Kernel Panic, vérifiez donc si le serveur répond toujours sur le réseau.

Depuis une autre machine, commencez par tester sa connectivité :

ping adresse-ip-du-serveur

L’absence de réponse au ping n’est toutefois pas une preuve de panne, car les requêtes ICMP peuvent être bloquées par le pare-feu.

Si vous disposez d’un accès local ou d’une console fournie par l’hébergeur, vérifiez l’état des interfaces réseau :

ip addr

Puis les routes configurées :

ip route

Vérifiez également que l’interface réseau est bien active :

ip link

Vérifier le service SSH

Si seul l’accès SSH ne fonctionne plus, contrôlez d’abord l’état du serveur SSH :

systemctl status ssh

Selon la distribution, le service peut également être nommé sshd :

systemctl status sshd

Consultez ensuite ses derniers événements :

journalctl -u ssh

ou :

journalctl -u sshd

Vérifier les ports en écoute

La commande ss permet de vérifier que les services attendus écoutent toujours sur leurs ports :

sudo ss -lntup

Par exemple, vous devez normalement retrouver le port 22 pour SSH, ainsi que les ports 80 et 443 pour un serveur Web.

Si le serveur répond au réseau mais qu’un port particulier n’est plus en écoute, le problème provient probablement du service concerné plutôt que d’un plantage de Linux.

Enfin, vérifiez les journaux du noyau à la recherche d’une perte de lien ou d’une erreur du pilote réseau :

sudo journalctl -k | grep -i -E "network|link.*down|nic|eth|timeout|reset"

Si le serveur reste accessible depuis une console locale ou la console de l’hébergeur, mais plus depuis Internet, concentrez le diagnostic sur l’interface réseau, le routage, le pare-feu, le service SSH et l’infrastructure réseau. Cela évite de rechercher inutilement un problème de CPU, RAM ou stockage alors que Linux fonctionne toujours correctement.

Que vérifier après un plantage Linux ?

Après un plantage, un blocage ou un redémarrage inattendu de Linux, il est préférable de suivre une méthode de diagnostic plutôt que de rechercher des erreurs au hasard. Commencez par les journaux du système et du noyau, puis vérifiez les ressources, le stockage et enfin le matériel.

Le tableau suivant récapitule les principales vérifications à effectuer.

Priorité	Vérification	Commande principale	Ce qu’il faut rechercher
1	Vérifier les derniers arrêts et redémarrages	last -x	Redémarrage sans arrêt normal, crash ou reboot inattendu
2	Examiner le démarrage précédent	journalctl -b -1	Erreurs enregistrées juste avant le plantage
3	Examiner les erreurs du noyau	journalctl -k -b -1	Kernel Panic, pilote, I/O, matériel, watchdog
4	Rechercher un manque de mémoire	journalctl -k -b -1 | grep -i -E "oom|out of memory|killed process"	OOM Killer et processus arrêté faute de RAM
5	Vérifier les services en échec	systemctl --failed	Service arrêté ou n’ayant pas réussi à démarrer
6	Vérifier CPU et mémoire	top et free -h	Processus gourmand, RAM insuffisante, swap fortement utilisé
7	Vérifier le Load Average	uptime	Charge anormalement élevée, saturation CPU ou attente d’I/O
8	Vérifier l’espace disque	df -h	Partition pleine, notamment /, /var ou /tmp
9	Vérifier les inodes	df -i	IUse% à 100 %, empêchant la création de nouveaux fichiers
10	Rechercher les erreurs de stockage et de système de fichiers	dmesg -T	I/O error, EXT4-fs error, XFS, Btrfs, NVMe, ATA
11	Vérifier l’état SMART	smartctl -a /dev/sda	Erreurs SMART, secteurs instables, erreurs NVMe
12	Rechercher les crashs d’applications	coredumpctl list	Segfault, SIGSEGV et processus ayant généré un core dump
13	Vérifier les températures	sensors	Surchauffe et thermal throttling
14	Rechercher les erreurs matérielles	journalctl -k	MCE, EDAC, Hardware Error, PCIe/AER
15	Tester la mémoire	Memtest86+	Erreurs de RAM ou instabilité mémoire

Le moment où vous effectuez le diagnostic est important. Après un plantage suivi d’un redémarrage, privilégiez les commandes utilisant -b -1, qui permettent d’examiner le démarrage précédent. Les journaux du démarrage actuel peuvent ne plus contenir les événements qui ont provoqué le crash.

Il faut également rechercher une corrélation entre plusieurs indices. Par exemple, des erreurs I/O error dans le journal du noyau, associées à des erreurs SMART et à des processus bloqués en état D, orientent fortement vers un problème de stockage. De même, des messages Out of memory suivis de Killed process permettent d’identifier un manque de mémoire plutôt qu’un véritable plantage du noyau.

Enfin, si un serveur est uniquement devenu inaccessible à distance, vérifiez d’abord le réseau, SSH et les services concernés. Une perte d’accès ne signifie pas nécessairement que Linux a planté.

Cette check-list permet ainsi de progresser du symptôme vers la cause, en distinguant un problème logiciel, un manque de ressources, une défaillance du stockage, une erreur du noyau ou une panne matérielle.

L’article Linux plante ou se bloque : diagnostiquer les causes et trouver l’origine est apparu en premier sur malekal.com.

Lorsqu’un PC ou un serveur Linux plante, se bloque ou redémarre de manière inattendue, l’origine du problème peut être matérielle : mémoire RAM instable, disque dur ou SSD défaillant, surchauffe, erreur CPU, périphérique PCIe ou contrôleur de stockage.

Linux intègre de nombreux outils en ligne de commandes permettant d’identifier le matériel et de rechercher les signes d’une défaillance. Les journaux du noyau avec dmesg et journalctl peuvent révéler des erreurs matérielles, tandis que des outils comme smartctl, Memtest86+, sensors, lspci ou dmidecode permettent d’approfondir le diagnostic d’un composant particulier.

Dans ce guide, découvrez comment diagnostiquer le matériel sous Linux en ligne de commandes : identifier les composants, tester la mémoire RAM, vérifier la santé des disques et SSD, surveiller les températures et rechercher les erreurs CPU/MCE, EDAC, PCIe, SATA ou NVMe.

Installer les outils de diagnostic nécessaires

Sur Debian/Ubuntu :

sudo apt install smartmontools lm-sensors dmidecode

Sur Fedora/RHEL :

sudo dnf install smartmontools lm_sensors dmidecode

C’est particulièrement utile parce que le titre promet du diagnostic en ligne de commandes : le lecteur doit pouvoir reproduire les commandes.

Identifier le matériel du PC ou serveur Linux

Avant de rechercher une panne matérielle, commencez par identifier précisément les composants détectés par Linux. Plusieurs commandes permettent d’obtenir rapidement des informations sur le processeur, la mémoire RAM, les périphériques PCI/PCIe, les périphériques USB et les disques.

Le guide :

Identifier le processeur

Pour afficher les caractéristiques du processeur :

lscpu

La commande indique notamment le modèle du CPU, son architecture, le nombre de cœurs et de threads, les caches ainsi que les fonctions prises en charge.

Pour obtenir uniquement les informations principales :

lscpu | grep -E "Model name|Socket|Core|Thread|CPU\(s\)"

Le guide complet :

Identifier la mémoire RAM

Pour connaître la quantité de mémoire détectée par Linux :

lsmem

Vous pouvez compléter avec :

free -h

Pour obtenir des informations plus détaillées sur les barrettes de mémoire installées, utilisez dmidecode avec les droits administrateur :

sudo dmidecode --type memory

Vous pouvez ainsi retrouver, lorsque le BIOS/UEFI fournit ces informations, la capacité, le fabricant, la référence, la vitesse et l’emplacement de chaque barrette de RAM.

Identifier les périphériques PCI et PCIe

La commande lspci permet d’identifier les périphériques connectés aux bus PCI et PCI Express :

lspci

Vous pouvez notamment y retrouver :

• La carte graphique.
• La carte réseau Ethernet ou Wi-Fi.
• Les contrôleurs SATA/NVMe.
• Les contrôleurs USB.
• Les cartes son.
• Les autres cartes d’extension PCIe.

Pour afficher également le pilote du noyau utilisé par chaque périphérique :

lspci -k

Cette variante est particulièrement intéressante lors d’un diagnostic, car elle permet de vérifier quel pilote Linux prend en charge un composant.

Le tutoriel de cette commande Linux :

Identifier les périphériques USB

Pour afficher les périphériques USB détectés :

lsusb

Cette commande permet notamment de repérer les clés USB, disques externes, webcams, adaptateurs Bluetooth ou Wi-Fi et autres périphériques connectés en USB.

Si un périphérique n’apparaît pas dans lsusb, le problème peut se situer au niveau de la connexion, du port USB ou du matériel lui-même plutôt qu’au niveau de son pilote.

Identifier les disques et SSD

Pour afficher les périphériques de stockage :

lsblk

Pour obtenir davantage d’informations :

lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE,FSTYPE,MOUNTPOINTS

Vous pouvez ainsi identifier les disques durs, SSD SATA, SSD NVMe, partitions et points de montage présents sur le système.

Pour aller plus loin :

Cette étape permet surtout de déterminer quel périphérique examiner ensuite. Par exemple, après avoir identifié un SSD comme /dev/nvme0n1 ou un disque comme /dev/sda, vous pourrez consulter son état SMART et rechercher dans les journaux du noyau les éventuelles erreurs qui lui sont associées.

L’identification du matériel ne permet donc pas à elle seule de déterminer si un composant est défectueux. Elle constitue le point de départ pour ensuite rechercher les erreurs matérielles dans dmesg et journalctl, contrôler SMART, tester la mémoire RAM et surveiller les températures.

Rechercher les erreurs matérielles dans les journaux

Certaines instabilités ou certains plantages de Linux peuvent provenir directement du matériel : processeur, mémoire RAM, carte mère, bus PCIe ou contrôleur de stockage. Le noyau Linux peut détecter une partie de ces anomalies et les enregistrer dans ses journaux.

Commencez par rechercher les principales erreurs matérielles :

sudo journalctl -k | grep -i -E "hardware error|mce|machine check|edac|pcie|aer"

Si le PC ou le serveur a redémarré après le plantage, examinez plutôt les messages du noyau du démarrage précédent :

sudo journalctl -k -b -1 | grep -i -E "hardware error|mce|machine check|edac|pcie|aer"

Vous pouvez également effectuer la recherche dans dmesg pour le démarrage actuel :

sudo dmesg -T | grep -i -E "hardware error|mce|machine check|edac|pcie|aer"

Voici les principaux messages à surveiller :

Message	Signification possible
Hardware Error	Erreur matérielle signalée au noyau
MCE / Machine Check Exception	Erreur détectée par le processeur, pouvant concerner le CPU, la RAM ou d’autres composants
EDAC	Erreur liée à la détection/correction des erreurs mémoire, notamment avec de la RAM ECC
PCIe Bus Error	rreur signalée par le mécanisme PCIe Advanced Error Reporting
AER	Erreur signalée par le mécanisme PCIe Advanced Error Reporting
Corrected error	Erreur matérielle détectée puis corrigée, qui mérite une surveillance si elle se répète
Uncorrected / Fatal error	Erreur qui n’a pas pu être corrigée et peut provoquer une instabilité ou un plantage

Une erreur corrigée isolée n’indique pas nécessairement qu’un composant est en panne. En revanche, des erreurs matérielles répétées, surtout lorsqu’elles apparaissent juste avant les blocages ou redémarrages, doivent être prises au sérieux.

Sur un serveur, vous pouvez également utiliser rasdaemon lorsqu’il est disponible. Cet outil collecte et facilite l’analyse des événements RAS (Reliability, Availability and Serviceability), notamment les erreurs mémoire, CPU et PCIe.

Enfin, les journaux Linux ne permettent pas de détecter toutes les pannes. Si les plantages restent inexpliqués, poursuivez le diagnostic en testant séparément la RAM, le stockage, les températures et, si possible, l’alimentation et les autres composants matériels.

Vérifier l’état SMART des disques

Un disque dur, SSD ou NVMe défaillant peut provoquer des erreurs d’entrée/sortie, des ralentissements importants, des blocages et parfois un plantage complet de Linux.

Avec smartmontools, vérifiez rapidement les données SMART du disque :

sudo smartctl -a /dev/sda

Pour un SSD NVMe :

sudo smartctl -a /dev/nvme0

Portez notamment attention à l’état SMART général, aux secteurs réalloués ou instables, aux erreurs non corrigibles, aux erreurs d’intégrité NVMe et à la température du disque.

Si dmesg ou journalctl signale parallèlement des I/O error, des erreurs ATA/NVMe ou des erreurs répétées du système de fichiers, une défaillance du stockage doit être sérieusement envisagée. Dans ce cas, sauvegardez les données importantes avant d’effectuer des tests ou des réparations supplémentaires.

Les guides pour approfondir :

Rechercher les erreurs du système de fichiers

Un système de fichiers endommagé peut provoquer des erreurs d’entrée/sortie, des fichiers inaccessibles, des blocages ou le passage d’une partition en lecture seule (read-only).

Commencez par rechercher les erreurs signalées par le noyau :

sudo dmesg -T | grep -i -E "filesystem|fs error|ext4|xfs|btrfs|i/o error|read-only"

Vous pouvez également vérifier les journaux du noyau :

sudo journalctl -k | grep -i -E "filesystem|fs error|ext4|xfs|btrfs|i/o error|read-only"

Si Linux a redémarré après le plantage, examinez plutôt le démarrage précédent :

sudo journalctl -k -b -1

Des messages tels que EXT4-fs error, I/O error, Buffer I/O error ou Read-only file system doivent attirer votre attention.

Si des erreurs de système de fichiers sont détectées, utilisez l’outil de réparation adapté (fsck, xfs_repair, outils Btrfs, etc.). N’exécutez pas fsck sur un système de fichiers monté en lecture/écriture, au risque d’aggraver les dommages.

Le tutoriel :

Vérifier la mémoire RAM

Une mémoire RAM défectueuse ou instable peut provoquer des plantages difficiles à diagnostiquer : Kernel Panic, erreurs de segmentation (segfault), corruption de données, applications qui plantent aléatoirement ou redémarrages inexpliqués.

Commencez par rechercher les éventuelles erreurs mémoire détectées par le noyau Linux :

sudo journalctl -k | grep -i -E "memory error|hardware error|mce|edac"

Pour examiner les erreurs enregistrées avant le dernier redémarrage :

sudo journalctl -k -b -1 | grep -i -E "memory error|hardware error|mce|edac"

Les systèmes équipés de mémoire ECC peuvent également remonter des erreurs corrigées ou non corrigées par l’intermédiaire d’EDAC (Error Detection And Correction). Des erreurs EDAC répétées doivent être examinées, même si elles sont indiquées comme corrigées.

Tester la RAM avec Memtest86+

Les journaux Linux ne permettent pas de détecter toutes les erreurs de mémoire. Pour effectuer un véritable test de la RAM, utilisez Memtest86+, qui fonctionne indépendamment du système d’exploitation.

• Redémarrez le PC ou le serveur et lancez Memtest86+ depuis GRUB lorsqu’il est disponible, ou depuis une clé USB bootable.

• Laissez le test effectuer plusieurs passes complètes. Une seule erreur détectée est déjà anormale : une mémoire RAM fonctionnant correctement ne doit générer aucune erreur.

Si des erreurs apparaissent :

• Désactivez temporairement tout overclocking du processeur ou de la mémoire.
• Désactivez les profils XMP/EXPO et rétablissez les paramètres mémoire par défaut du BIOS/UEFI.
• Si plusieurs barrettes sont installées, testez-les une par une.
• Testez si nécessaire une même barrette dans différents emplacements mémoire afin d’écarter un problème de slot ou de carte mère.

Des erreurs mémoire ne signifient donc pas systématiquement qu’une barrette est physiquement défectueuse. Une fréquence trop élevée, des timings incorrects, une tension inadaptée ou un problème du contrôleur mémoire peuvent également provoquer une instabilité.

Si les plantages sont aléatoires et touchent des applications différentes, notamment avec des segfault, des Kernel Panic ou des fichiers qui se corrompent sans cause évidente, un test approfondi de la RAM fait partie des vérifications matérielles prioritaires.

Vous pouvez aussi utiliser Memtest86, plus de détails:

Vérifier les températures et la surchauffe

Une surchauffe du processeur, du GPU ou d’un autre composant peut provoquer des ralentissements, du thermal throttling, des blocages et, dans les cas les plus sévères, un arrêt ou un redémarrage de sécurité du système.

Sous Linux, vous pouvez surveiller les températures avec le paquet lm-sensors. Une fois installé et configuré, exécutez :

sensors

Pour surveiller les températures en continu :

watch -n 2 sensors

Observez particulièrement les températures du CPU, de la carte mère et, lorsqu’elles sont disponibles, celles du GPU et des SSD NVMe. Une température élevée n’indique pas nécessairement une panne : il faut surtout rechercher une température qui atteint régulièrement la limite critique du composant ou qui coïncide avec les blocages.

Vous pouvez également rechercher dans les messages du noyau les événements liés à une surchauffe ou à une limitation thermique :

sudo journalctl -k | grep -i -E "thermal|temperature|throttl|overheat"

Après un redémarrage inattendu, vérifiez également le démarrage précédent :

sudo journalctl -k -b -1 | grep -i -E "thermal|temperature|throttl|overheat"

Des messages faisant référence à thermal throttling, critical temperature ou à une température dépassant un seuil critique peuvent orienter vers un problème de refroidissement.

Dans ce cas, vérifiez notamment l’état des ventilateurs, l’accumulation de poussière, le radiateur et le système de refroidissement. Sur une machine ancienne, une pâte thermique dégradée peut également entraîner une augmentation importante des températures.

Enfin, gardez à l’esprit qu’un arrêt thermique brutal peut ne pas laisser de message exploitable dans les journaux, le système pouvant s’éteindre avant que l’événement soit écrit sur le disque.

Voir aussi :

Vérifier les erreurs CPU et Machine Check Exception

Le processeur peut détecter certaines erreurs matérielles et les signaler au noyau Linux par l’intermédiaire du mécanisme Machine Check Exception (MCE). Ces erreurs peuvent concerner directement le CPU, mais également les caches, le contrôleur mémoire, la RAM ou les communications avec d’autres composants.

Des erreurs MCE répétées peuvent provoquer des Kernel Panic, des blocages, des redémarrages ou des erreurs applicatives aléatoires.

Pour rechercher les erreurs matérielles enregistrées par le noyau :

sudo journalctl -k | grep -i -E "mce|machine check|hardware error"

Après un plantage suivi d’un redémarrage, examinez également le démarrage précédent :

sudo journalctl -k -b -1 | grep -i -E "mce|machine check|hardware error"

Vous pouvez effectuer la même recherche dans les messages du noyau du démarrage actuel :

sudo dmesg -T | grep -i -E "mce|machine check|hardware error"

Un message peut par exemple contenir Machine check events logged, MCE, Hardware Error, Corrected error ou Uncorrected error.

Toutes les erreurs MCE ne provoquent pas nécessairement un plantage. Une erreur corrigée (Corrected Error) a été détectée et récupérée par le matériel. Une occurrence isolée n’indique pas forcément une panne, mais des erreurs corrigées qui se répètent doivent être surveillées.

À l’inverse, une Uncorrected Error ou une erreur indiquée comme Fatal est plus préoccupante et peut être directement responsable d’un plantage.

Si des erreurs MCE apparaissent régulièrement :

• Désactivez tout overclocking ou undervolting du processeur.
• Désactivez temporairement les profils mémoire XMP/EXPO.
• Rétablissez les paramètres par défaut du BIOS/UEFI.
• Vérifiez les températures du processeur.
• Testez la mémoire RAM avec Memtest86+.
• Vérifiez si une mise à jour du BIOS/UEFI est disponible.
• Recherchez une éventuelle instabilité du CPU, de la RAM ou de la carte mère.

Sur un serveur, des outils comme rasdaemon peuvent également faciliter la collecte et l’analyse des erreurs matérielles remontées par le processeur, la mémoire et les mécanismes RAS.

Enfin, une Machine Check Exception ne signifie pas automatiquement que le processeur est défectueux. Le CPU est souvent le composant qui détecte et signale l’erreur, alors que sa véritable origine peut être la RAM, le contrôleur mémoire, la carte mère ou une configuration matérielle instable.

Vérifier les erreurs PCIe et périphériques

Les périphériques connectés au bus PCI Express (PCIe) peuvent également être à l’origine de plantages ou d’instabilités sous Linux. Cela concerne notamment les cartes graphiques, cartes réseau, contrôleurs NVMe, cartes RAID et autres cartes d’extension.

Linux peut signaler ces problèmes grâce au mécanisme AER (Advanced Error Reporting) de PCI Express.

Pour rechercher les erreurs PCIe enregistrées par le noyau :

sudo journalctl -k | grep -i -E "pcie.*error|aer.*error|uncorrected|fatal|failed|link.*down|link.*not.*active|timeout|reset"

Pour une vérification plus large (cela peut inclure des informations) :

sudo journalctl -k | grep -i -E "pcie|aer|pciehp|dpc"

Après un plantage suivi d’un redémarrage, examinez également le démarrage précédent :

sudo journalctl -k -b -1 | grep -i -E "pcie|aer|pci.*error|bus error"

Vous pouvez également utiliser dmesg :

sudo dmesg -T | grep -i -E "pcie|aer|pci.*error|bus error"

Les messages peuvent notamment contenir PCIe Bus Error, AER, Corrected error, Uncorrected error ou Fatal error.

Message	Signification	Gravité / action
AER enabled with IRQ…	Le mécanisme PCIe Advanced Error Reporting est activé pour ce port.	Informatif, ce n’est pas une erreur.
DPC error containment capabilities…	Affiche les capacités Downstream Port Containment permettant d’isoler certaines erreurs PCIe.	Informatif, ce n’est pas une erreur.
Slot(…): Card present	Un périphérique est détecté dans un slot PCIe Hot Plug.	Informatif.
Signaling PME with IRQ…	Configuration de la gestion d’énergie PCIe (Power Management Event).	Informatif.
Failed to check link status	Le pilote pciehp n’a pas réussi à déterminer l’état de la liaison PCIe.	À surveiller si le message se répète ou si un périphérique disparaît/ne fonctionne pas.
Data Link Layer Link Active not set…	La couche liaison PCIe n’est pas passée à l’état actif dans le délai attendu.	Peut accompagner un problème d’établissement de la liaison. À surveiller si répété.
PCIe Bus Error: severity=Corrected	Une erreur PCIe a été détectée puis corrigée par le matériel/AER.	Généralement non critique si occasionnelle ; à surveiller si répétée.
PCIe Bus Error: severity=Uncorrected	Une erreur PCIe n’a pas pu être corrigée.	Anormal, identifier le périphérique concerné.
severity=Fatal	Erreur PCIe fatale.	Critique, peut entraîner la perte du périphérique ou un plantage.
Link down / link is down	La liaison avec le périphérique PCIe a été perdue.	Vérifier périphérique, slot, alimentation et pilote.
timeout	Le périphérique n’a pas répondu dans le délai prévu.	Rechercher d’autres erreurs autour du même périphérique.
reset / resetting	Linux tente de réinitialiser le périphérique après un problème.	À surveiller si les resets sont répétés.

Notez que certaines « error » peuvent être seulement informatives.

Pour identifier les périphériques PCI/PCIe présents sur la machine :

lspci

Pour afficher également le pilote du noyau associé à chaque périphérique :

lspci -k

Lorsqu’un identifiant PCI apparaît dans les journaux, par exemple 0000:03:00.0, vous pouvez identifier précisément le périphérique concerné avec :

lspci -s 03:00.0 -k

Cela permet de déterminer rapidement si l’erreur concerne, par exemple, une carte graphique, un contrôleur NVMe ou une carte réseau.

Des erreurs PCIe répétées peuvent provenir du périphérique lui-même, de son pilote, d’un mauvais contact dans le connecteur PCIe, du BIOS/UEFI, de la carte mère ou parfois de l’alimentation. Sur un PC fixe, si le problème concerne une carte d’extension, vérifiez également qu’elle est correctement insérée dans son slot et que ses éventuels connecteurs d’alimentation sont correctement branchés.

Une erreur AER corrigée et occasionnelle n’est pas nécessairement synonyme de panne. En revanche, une accumulation d’erreurs, des Uncorrected/Fatal errors, des resets répétés ou la disparition d’un périphérique doivent conduire à approfondir le diagnostic.

Vérifier les périphériques de stockage NVMe/SATA

Un SSD NVMe, un disque SATA ou son contrôleur peut être à l’origine de blocages, de ralentissements importants, de systèmes de fichiers passant en lecture seule ou de plantages de Linux. Avant même que SMART ne signale une panne, le noyau peut enregistrer des timeouts, resets et erreurs d’entrée/sortie (I/O).

Commencez par identifier les périphériques de stockage :

lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE

Plus de détails sur son utilisation : La commande lsblk : utilisations et exemples

Puis recherchez les erreurs liées aux disques SATA et NVMe dans les messages du noyau :

sudo dmesg -T | grep -i -E "nvme|ata|sata|i/o error|timeout|reset|failed"

Avec journalctl :

sudo journalctl -k | grep -i -E "nvme|ata|sata|i/o error|timeout|reset|failed"

Après un plantage suivi d’un redémarrage, vérifiez surtout le démarrage précédent :

sudo journalctl -k -b -1 | grep -i -E "nvme|ata|sata|i/o error|timeout|reset|failed"

Portez notamment attention aux messages suivants :

Message	Cause possible
I/O error	Échec d’une opération de lecture ou d’écriture
Buffer I/O error	Erreur d’accès au périphérique de stockage
ataX: hard resetting link	Linux tente de réinitialiser une liaison SATA en erreur
SATA link down	Perte de communication avec le périphérique SATA
failed command	Commande ATA/SATA ayant échoué
timeout	SSD ou disque n’ayant pas répondu dans le délai attendu
nvme reset controller	Réinitialisation du contrôleur NVMe après un problème
I/O timeout	Opération d’entrée/sortie ayant dépassé le délai prévu

Sur un disque SATA, des erreurs répétées ne signifient pas nécessairement que le disque est défectueux. Un câble SATA endommagé ou mal connecté, un connecteur d’alimentation ou un contrôleur SATA peut également être responsable.

Sur un SSD NVMe, des timeouts ou resets répétés peuvent provenir du SSD, de son firmware, du contrôleur PCIe, d’une surchauffe ou d’un problème de gestion de l’énergie.

Si vous détectez ce type d’erreur, vérifiez ensuite l’état SMART du disque ou du SSD avec smartctl. En présence d’erreurs I/O répétées ou d’un état SMART dégradé, sauvegardez les données importantes avant de poursuivre les tests.

Les guides pour approfondir :

Tableau des commandes de diagnostic matériel Linux

Le tableau suivant récapitule les principales commandes permettant d’identifier le matériel et rechercher une panne sous Linux. Elles constituent une bonne base de diagnostic avant de passer à des tests plus approfondis.

Composant / vérification	Commande	Utilité
Processeur (CPU)	lscpu	Afficher le modèle, l’architecture, les cœurs, threads et caractéristiques du processeur
Mémoire RAM	lsmem	Afficher l’organisation et la quantité de mémoire détectée
Utilisation de la RAM	free -h	Vérifier la mémoire disponible, utilisée et le swap
Barrettes de RAM	sudo dmidecode --type memory	Afficher les caractéristiques des barrettes (capacité, vitesse, fabricant, emplacement)
Test de la RAM	Memtest86+	Détecter les erreurs et instabilités de la mémoire RAM
Périphériques PCI/PCIe	lspci	Identifier les cartes graphiques, réseau, contrôleurs et cartes d’extension
Pilotes PCI/PCIe	lspci -k	Identifier le pilote du noyau utilisé par chaque périphérique
Périphériques USB	lsusb	Lister les périphériques USB détectés
Disques et SSD	lsblk	Identifier les disques, SSD, partitions et points de montage
État SMART	sudo smartctl -a /dev/sda	Vérifier l’état de santé d’un disque SATA
État SMART NVMe	sudo smartctl -a /dev/nvme0	Vérifier la santé et les erreurs d’un SSD NVMe
Températures	sensors	Afficher les températures et autres capteurs matériels
Surveillance des températures	watch -n 2 sensors	Surveiller les températures en temps réel
Messages du noyau	sudo dmesg -T	Rechercher les erreurs matérielles, pilotes, stockage et périphériques
Journal du noyau	sudo journalctl -k	Consulter les événements matériels enregistrés par le noyau
Démarrage précédent	sudo journalctl -k -b -1	Rechercher une erreur matérielle ayant précédé un plantage ou redémarrage
Erreurs CPU/MCE	journalctl -k | grep -i -E "mce|machine check|hardware error"	Rechercher les erreurs matérielles remontées par le processeur
Erreurs mémoire EDAC	journalctl -k | grep -i "edac"	Rechercher les erreurs mémoire détectées par EDAC
Erreurs PCIe	sudo journalctl -k | grep -i -E "pcie.error|aer.error|uncorrected|fatal|failed|link.down|link.not.*active|timeout|reset"	Rechercher les erreurs PCI Express et AER
Erreurs SATA/NVMe	journalctl -k | grep -i -E "nvme|ata|sata|i/o error|timeout|reset"	Détecter les erreurs, timeouts et resets des périphériques de stockage
Erreurs du système de fichiers	journalctl -k | grep -i -E "ext4|xfs|btrfs|i/o error"	Rechercher les erreurs de système de fichiers et d’entrée/sortie
Erreurs RAS	ras-mc-ctl --errors	Consulter les erreurs matérielles collectées par rasdaemon

Il n’existe pas de commande unique permettant de conclure qu’un composant est défectueux. Il faut généralement croiser plusieurs indices. Par exemple, des erreurs I/O error dans journalctl, des resets NVMe répétés et des erreurs SMART sur le même SSD constituent un faisceau d’indices beaucoup plus significatif qu’un message isolé.

De même, après un plantage suivi d’un redémarrage, pensez à examiner le démarrage précédent avec journalctl -k -b -1 : les journaux du démarrage actuel peuvent ne plus montrer les événements qui ont précédé la panne.

Surveiller les erreurs matérielles dans le temps avec rasdaemon

Pour aller plus loin dans le diagnostic, notamment sur un serveur Linux fonctionnant en continu, vous pouvez utiliser rasdaemon. Cet outil collecte et conserve un historique des événements RAS (Reliability, Availability and Serviceability) remontés par le noyau Linux.

Il permet notamment de surveiller certaines erreurs mémoire ECC/EDAC, Machine Check Events (MCE) et erreurs PCIe/AER afin de déterminer si elles sont isolées ou si elles se répètent et deviennent plus fréquentes avec le temps. Cette surveillance peut aider à détecter la dégradation progressive d’un composant avant qu’elle ne provoque une panne plus importante.

Contrairement à Memtest86+ ou aux autotests SMART, rasdaemon ne teste pas directement le matériel : il enregistre les erreurs détectées pendant le fonctionnement normal du système.

Le guide complet :

L’article Diagnostiquer le matériel sous Linux en ligne de commandes est apparu en premier sur malekal.com.

Les serveurs et stations de travail Linux disposent de mécanismes permettant de détecter et signaler certaines erreurs matérielles avant qu’elles ne provoquent nécessairement une panne. Une erreur mémoire ECC corrigée, une Machine Check Exception (MCE) ou une erreur PCIe/AER peut ainsi être enregistrée alors que le système continue à fonctionner normalement.

rasdaemon est un outil Linux dédié à la collecte et à la surveillance de ces événements RAS (Reliability, Availability and Serviceability). Associé à ras-mc-ctl, il permet de conserver un historique des erreurs matérielles, d’afficher leur détail et surtout de déterminer si elles se répètent ou deviennent plus fréquentes avec le temps.

Dans ce guide, découvrez comment installer et configurer rasdaemon sous Linux, enregistrer les événements RAS et utiliser ras-mc-ctl pour surveiller les erreurs mémoire ECC/EDAC, MCE et PCIe/AER. Vous apprendrez également à distinguer les erreurs Corrected, Uncorrected et Fatal et à mettre en place une surveillance régulière du matériel d’un serveur.

Qu’est-ce que rasdaemon et RAS ?

rasdaemon est un outil Linux destiné à collecter, enregistrer et faciliter l’analyse des erreurs matérielles remontées par le noyau. Il est principalement utilisé sur les serveurs et les stations de travail pour surveiller la fiabilité du matériel et détecter des anomalies qui peuvent passer inaperçues tant qu’elles restent corrigibles.

Son nom fait référence à RAS (Reliability, Availability and Serviceability), que l’on peut traduire par fiabilité, disponibilité et facilité de maintenance. Il s’agit d’un ensemble de mécanismes matériels et logiciels permettant de détecter, signaler et parfois corriger des erreurs sans provoquer immédiatement l’arrêt du système.

Selon le matériel et les mécanismes pris en charge par le noyau, rasdaemon peut notamment collecter des événements concernant :

• La mémoire RAM ECC et EDAC (Error Detection And Correction).
• Les erreurs processeur et Machine Check Events (MCE).
• Les erreurs du bus PCI Express (PCIe/AER).
• Certaines erreurs liées au stockage ou à d’autres composants disposant de mécanismes RAS.

Le noyau Linux peut déjà afficher ce type d’informations dans dmesg ou journalctl. L’intérêt de rasdaemon est de permettre une collecte structurée et persistante des événements, afin de suivre leur évolution dans le temps.

Par exemple, une mémoire ECC peut détecter et corriger automatiquement une erreur sans provoquer de plantage. Le serveur continue donc à fonctionner normalement. Si ce type d’erreur commence toutefois à se répéter régulièrement sur une même barrette, cela peut constituer le signe d’une dégradation matérielle.

Il est donc important de distinguer plusieurs niveaux d’erreurs :

Type d’erreur	Signification
Corrected / Correctable	L’erreur a été détectée et corrigée. Le système peut continuer à fonctionner, mais des occurrences répétées doivent être surveillées.
Uncorrected / Uncorrectable	L’erreur n’a pas pu être corrigée automatiquement et peut provoquer une corruption de données ou une instabilité.
Fatal	Erreur grave pouvant entraîner la perte d’un périphérique, un Kernel Panic ou un arrêt du système.

rasdaemon n’est donc pas un outil de test matériel comparable à Memtest86+ ou à un autotest SMART. Il ne sollicite pas volontairement les composants pour rechercher une panne. Son rôle est plutôt de surveiller et enregistrer les erreurs matérielles détectées pendant le fonctionnement normal de Linux.

Il est particulièrement intéressant sur un serveur fonctionnant 24 h/24, car il permet de repérer une augmentation progressive des erreurs corrigées avant qu’elles ne se transforment éventuellement en panne plus importante.

Dans la suite de ce guide, nous allons voir comment installer rasdaemon, activer la collecte des événements RAS et analyser les erreurs enregistrées avec ras-mc-ctl.

Installer rasdaemon

Le paquet rasdaemon est disponible dans les dépôts de nombreuses distributions Linux. Son installation nécessite les droits administrateur.

Sur Debian et Ubuntu, utilisez :

sudo apt update
sudo apt install rasdaemon

Sur Fedora :

sudo dnf install rasdaemon

Sur RHEL, Rocky Linux ou AlmaLinux, recherchez d’abord si le paquet est disponible dans les dépôts activés :

dnf search rasdaemon

Puis, s’il est disponible :

sudo dnf install rasdaemon

Selon la version de la distribution, l’activation d’un dépôt supplémentaire peut être nécessaire.

Sur Arch Linux :

sudo pacman -S rasdaemon

Une fois l’installation terminée, vérifiez que l’exécutable est disponible :

rasdaemon --version

Vous pouvez également afficher les options prises en charge :

rasdaemon --help

Le paquet installe généralement deux outils importants :

• rasdaemon : le démon chargé de collecter les événements RAS remontés par le noyau.
• ras-mc-ctl : l’utilitaire permettant notamment de consulter les erreurs et informations collectées.

Vous pouvez vérifier leur présence avec :

command -v rasdaemon
command -v ras-mc-ctl

L’installation du paquet ne garantit toutefois pas que tous les types d’erreurs matérielles pourront être surveillés. Les informations disponibles dépendent du processeur, de la carte mère, de la mémoire ECC éventuelle, des pilotes et des mécanismes RAS pris en charge par le noyau Linux.

Après l’installation, l’étape suivante consiste donc à activer et démarrer le service rasdaemon, puis à vérifier que la collecte des événements fonctionne correctement.

Activer et démarrer rasdaemon

Une fois rasdaemon installé, vérifiez que son service systemd est activé et en cours d’exécution. Le démon pourra ainsi surveiller les événements RAS remontés par le noyau Linux pendant le fonctionnement de la machine.

Pour démarrer rasdaemon et l’activer automatiquement au démarrage de Linux :

sudo systemctl enable --now rasdaemon

L’option --now permet d’effectuer les deux opérations en une seule commande : activer le service au démarrage et le lancer immédiatement.

Vérifiez ensuite son état :

systemctl status rasdaemon

Si le service fonctionne correctement, vous devez notamment obtenir un état similaire à :

Active: active (running)

Vous pouvez également vérifier simplement s’il est actif :

systemctl is-active rasdaemon

La commande doit retourner :

active

Le guide complet :

Consulter les messages de rasdaemon

Pour vérifier le démarrage du démon et rechercher d’éventuelles erreurs :

sudo journalctl -u rasdaemon -e

Pour suivre ses événements en temps réel :

sudo journalctl -u rasdaemon -f

Si le service refuse de démarrer, affichez son état détaillé et ses derniers journaux :

systemctl status rasdaemon

sudo journalctl -u rasdaemon -e

Les fonctionnalités réellement disponibles dépendent du matériel, du noyau Linux et des mécanismes RAS pris en charge par la machine. L’absence de certains types d’événements ne signifie donc pas nécessairement que rasdaemon fonctionne mal.

Une fois le service actif, l’étape suivante consiste à vérifier que rasdaemon collecte correctement les événements matériels et, si nécessaire, à activer leur enregistrement persistant.

Le tutoriel :

Activer l’enregistrement des événements

Pour exploiter pleinement rasdaemon, il est recommandé d’activer l’enregistrement persistant des événements RAS. Cela permet de conserver un historique des erreurs matérielles détectées et de les consulter ultérieurement avec ras-mc-ctl.

Cette fonction est particulièrement utile sur un serveur : elle permet de déterminer si des erreurs mémoire ECC, MCE ou PCIe/AER apparaissent régulièrement ou si leur nombre augmente avec le temps.

Pour activer l’enregistrement des événements, utilisez :

sudo rasdaemon --record

L’option --record demande à rasdaemon d’enregistrer les événements collectés dans une base de données SQLite.

Toutefois, si rasdaemon fonctionne déjà comme service systemd, ne lancez pas immédiatement cette commande, car l’enregistrement peut déjà être activé par le service.

Commencez par vérifier sa configuration :

systemctl cat rasdaemon

Recherchez la directive ExecStart. Si celle-ci contient l’option --record, l’enregistrement persistant est déjà activé et aucune modification supplémentaire n’est nécessaire.

Vous pouvez également vérifier la ligne de commande du processus en cours :

ps -ef | grep '[r]asdaemon'

Afficher un résumé des erreurs avec ras-mc-ctl

Une fois rasdaemon actif et l’enregistrement des événements configuré, la commande ras-mc-ctl permet de consulter les erreurs matérielles collectées.

Pour obtenir une vue d’ensemble, utilisez :

sudo ras-mc-ctl --summary

Cette commande affiche un résumé des événements RAS enregistrés dans la base de rasdaemon. Selon le matériel, le noyau et les mécanismes pris en charge par votre machine, vous pouvez notamment retrouver des compteurs liés à :

• La mémoire et EDAC.
• Les erreurs Machine Check (MCE).
• Les erreurs PCIe/AER.
• Les erreurs matérielles corrigées ou non corrigées.
• D’autres événements RAS pris en charge par le système.

Si aucun problème matériel n’a été détecté, les compteurs concernés restent à 0 ou ras-mc-ctl indique qu’aucune erreur n’a été enregistrée. C’est un résultat normal.

Interpréter les résultats

Il est surtout important de surveiller l’évolution des compteurs dans le temps plutôt qu’une valeur isolée.

Situation	Interprétation
Aucune erreur	Aucun événement matériel pris en charge n’a été enregistré
Une erreur corrigée isolée	À surveiller, mais ne signifie pas nécessairement qu’un composant est défectueux
Erreurs corrigées qui augmentent régulièrement	Peut indiquer une dégradation ou une instabilité matérielle
Erreurs non corrigées	Anomalie plus sérieuse nécessitant d’identifier le composant concerné
Erreurs fatales	Peuvent provoquer un plantage, un Kernel Panic ou la perte d’un périphérique

Par exemple, sur un serveur équipé de mémoire ECC, quelques erreurs corrigées doivent être surveillées. Si leur nombre augmente régulièrement et qu’elles concernent toujours le même module mémoire, il devient pertinent de vérifier la barrette, son emplacement et la configuration mémoire.

De même, des erreurs PCIe/AER répétées peuvent conduire à examiner le périphérique PCIe concerné, son pilote, le slot, le BIOS/UEFI ou son alimentation.

Vous pouvez relancer périodiquement :

sudo ras-mc-ctl --summary

afin de vérifier si les compteurs évoluent.

Le résumé permet ainsi d’obtenir rapidement une vue générale de la santé matérielle remontée par les mécanismes RAS. Si des erreurs apparaissent, utilisez ensuite les fonctions détaillées de ras-mc-ctl ainsi que journalctl pour identifier plus précisément leur origine.

Surveiller les erreurs mémoire ECC et EDAC

Sur les serveurs et stations de travail équipés de mémoire ECC (Error-Correcting Code), le contrôleur mémoire peut détecter et, dans certains cas, corriger automatiquement les erreurs de mémoire. Sous Linux, ces événements peuvent être remontés par le sous-système EDAC (Error Detection And Correction) et collectés par rasdaemon.

La surveillance de ces erreurs est particulièrement intéressante sur un serveur : une barrette peut commencer à générer des erreurs corrigées tout en continuant à fonctionner normalement. Une augmentation progressive de leur nombre peut alors constituer un signe précurseur d’une défaillance mémoire.

Pour afficher un résumé des erreurs enregistrées :

sudo ras-mc-ctl --summary

Pour obtenir le détail des événements :

sudo ras-mc-ctl --errors

Vous pouvez également rechercher les événements EDAC directement dans les journaux du noyau :

sudo journalctl -k | grep -i -E "edac|ecc|memory error|corrected error|uncorrected error"

Après un plantage ou un redémarrage inattendu, examinez également le démarrage précédent :

sudo journalctl -k -b -1 | grep -i -E "edac|ecc|memory error|corrected error|uncorrected error"

Comprendre les erreurs CE et UE

Dans les événements mémoire, vous pouvez notamment rencontrer les termes CE et UE :

Type	Signification	Action
CE – Corrected Error	L’erreur mémoire a été détectée et corrigée par le mécanisme ECC.	Surveiller son évolution et le composant concerné.
UE – Uncorrected Error	L’erreur n’a pas pu être corrigée.	À prendre au sérieux : risque d’instabilité, de corruption ou de plantage.
Erreurs CE répétées	Les erreurs corrigées s’accumulent, éventuellement sur le même module.	Identifier le DIMM concerné et envisager son remplacement.

Une erreur corrigée isolée ne signifie pas nécessairement qu’une barrette de RAM est défectueuse. En revanche, si les erreurs CE augmentent régulièrement, particulièrement sur le même module ou canal mémoire, une investigation matérielle devient nécessaire.

Identifier la barrette mémoire concernée

Lorsque le matériel et le pilote EDAC fournissent suffisamment d’informations, les événements peuvent permettre d’identifier un DIMM, un canal ou un contrôleur mémoire particulier.

Vous pouvez comparer ces informations avec la configuration physique de la mémoire :

sudo dmidecode --type memory

Cette commande permet notamment d’afficher les emplacements mémoire (Locator), la capacité et, selon le matériel, le fabricant et la référence des barrettes.

Si rasdaemon ou EDAC désigne par exemple un emplacement DIMM_A1, DIMM_B2 ou un canal précis, recherchez l’emplacement correspondant dans dmidecode et dans la documentation de la carte mère ou du serveur.

Si les erreurs mémoire deviennent récurrentes, complétez le diagnostic avec un test de la RAM, par exemple Memtest86+, et vérifiez également les paramètres mémoire du BIOS/UEFI. Un overclocking, un profil XMP/EXPO ou une configuration mémoire instable peut également provoquer des erreurs sans que la barrette soit nécessairement défectueuse.

Analyser les Machine Check Events (MCE)

Les Machine Check Events (MCE) correspondent à des erreurs matérielles détectées par le processeur grâce à son mécanisme Machine Check Architecture (MCA). Contrairement à ce que leur nom peut laisser penser, une erreur MCE ne signifie pas nécessairement que le CPU est défectueux : le processeur peut signaler une anomalie provenant de la mémoire RAM, des caches, du contrôleur mémoire, de la carte mère ou d’autres composants.

rasdaemon permet de collecter ces événements et de conserver leur historique afin d’identifier les erreurs qui se répètent.

Commencez par afficher le résumé des événements enregistrés :

sudo ras-mc-ctl --summary

Puis consultez les erreurs détaillées :

sudo ras-mc-ctl --errors

Vous pouvez compléter cette analyse avec les messages du noyau :

sudo journalctl -k | grep -i -E "mce|machine check|hardware error"

Si le serveur a redémarré après un plantage, vérifiez également les événements du démarrage précédent :

sudo journalctl -k -b -1 | grep -i -E "mce|machine check|hardware error"

Interpréter une erreur MCE

Une erreur MCE peut être corrigée, non corrigée ou fatale. Son niveau de gravité et sa répétition sont donc plus importants que la simple présence du terme MCE.

Type d’événement	Signification	Action
Corrected / Correctable	Le matériel a détecté puis corrigé l’erreur.	Surveiller si elle se répète.
Uncorrected / Uncorrectable	L’erreur n’a pas pu être corrigée.	Rechercher rapidement le composant concerné.
Fatal	L’erreur empêche le système de continuer normalement.	Peut être directement liée à un Kernel Panic ou un redémarrage.
Erreurs répétées sur le même composant	Une anomalie matérielle ou une instabilité devient probable.	Approfondir le diagnostic du composant concerné.

Une erreur corrigée isolée n’indique donc pas nécessairement une panne. En revanche, des événements MCE qui apparaissent régulièrement ou dont la fréquence augmente doivent être pris au sérieux.

Rechercher l’origine d’une erreur MCE

Lorsqu’une erreur MCE est enregistrée, recherchez les informations permettant d’identifier sa provenance. Selon le processeur et le matériel, les événements peuvent notamment faire référence :

• Au CPU ou à un cœur particulier.
• Aux caches L1, L2 ou L3.
• Au contrôleur mémoire.
• À un canal ou une barrette de RAM.
• À une erreur de bus ou d’interconnexion.

Il faut ensuite croiser ces informations avec les autres événements RAS. Par exemple, des MCE associées à des erreurs EDAC/ECC sur le même canal mémoire orientent davantage vers la RAM ou le contrôleur mémoire que vers une défaillance du processeur lui-même.

Si les erreurs MCE se répètent :

• Désactivez tout overclocking ou undervolting.
• Rétablissez temporairement les paramètres par défaut du BIOS/UEFI.
• Désactivez les profils mémoire XMP/EXPO pour effectuer un test.
• Vérifiez les températures du processeur.
• Testez la mémoire RAM.
• Vérifiez si une mise à jour du BIOS/UEFI ou du microcode CPU est disponible.
• Recherchez si les événements concernent toujours le même CPU, cœur, cache ou canal mémoire.

L’intérêt de rasdaemon est ici de conserver un historique : plutôt que d’analyser uniquement une erreur ponctuelle dans dmesg, vous pouvez déterminer si les Machine Check Events se répètent ou deviennent plus fréquents, ce qui constitue un indicateur beaucoup plus pertinent d’une éventuelle dégradation matérielle.

Surveiller les erreurs PCIe/AER

Le bus PCI Express (PCIe) dispose d’un mécanisme appelé AER (Advanced Error Reporting) permettant de détecter et de signaler certaines erreurs de communication entre le processeur, le chipset et les périphériques PCIe.

Ces erreurs peuvent concerner de nombreux composants : carte graphique, SSD NVMe, carte réseau, contrôleur RAID, carte HBA ou tout autre périphérique connecté en PCI Express.

Avec rasdaemon, vous pouvez conserver un historique de ces événements afin de déterminer s’ils sont isolés ou s’ils se répètent sur le même périphérique.

Commencez par afficher le résumé des événements enregistrés :

sudo ras-mc-ctl --summary

Puis consultez les erreurs détaillées :

sudo ras-mc-ctl --errors

Vous pouvez compléter le diagnostic en recherchant les erreurs PCIe dans les journaux du noyau :

sudo journalctl -k | grep -i -E "pcie.*error|aer.*error|uncorrected|fatal|failed|link.*down|link.*not.*active|timeout|reset"

Après un plantage ou un redémarrage inattendu :

sudo journalctl -k -b -1 | grep -i -E "pcie.*error|aer.*error|uncorrected|fatal|failed|link.*down|link.*not.*active|timeout|reset"

Interpréter les messages PCIe/AER

Toutes les lignes contenant les termes PCIe, AER ou DPC ne correspondent pas à une erreur. Linux affiche également de nombreux messages informatifs lors de l’initialisation du matériel.

Message	Signification	Action
AER enabled with IRQ…	Le mécanisme Advanced Error Reporting est activé.	Informatif, aucune action nécessaire.
DPC error containment capabilities…	Le port indique ses capacités Downstream Port Containment.	Informatif, ce n’est pas une erreur détectée.
Slot(…): Card present	Un périphérique est présent dans le slot PCIe.	Informatif.
PCIe Bus Error: severity=Corrected	Une erreur a été détectée puis corrigée.	À surveiller si elle devient fréquente.
PCIe Bus Error: severity=Uncorrected	L’erreur n’a pas pu être corrigée.	Identifier le périphérique et approfondir le diagnostic.
severity=Fatal	Erreur PCIe grave.	Peut provoquer la perte du périphérique ou un plantage.
Failed to check link status	Le pilote n’a pas réussi à vérifier correctement l’état de la liaison PCIe.	À surveiller si le message se répète ou accompagne la disparition d’un périphérique.
Data Link Layer Link Active not set	La liaison PCIe n’est pas devenue active dans le délai prévu.	Rechercher d’autres erreurs concernant le même port.
Link down	La liaison PCIe avec le périphérique a été perdue.	Vérifier le périphérique, le slot, l’alimentation et le pilote.
timeout / reset	Le périphérique ne répond plus correctement et peut avoir été réinitialisé.	À investiguer si les événements sont répétés.

Cette distinction est importante : une simple ligne AER enabled ne signifie pas qu’une erreur PCIe s’est produite.

Identifier le périphérique PCIe concerné

Les événements PCIe contiennent généralement une adresse permettant d’identifier le périphérique ou le port concerné, par exemple :

0000:03:00.0

Pour identifier ce périphérique :

lspci -s 03:00.0 -k

La commande affiche le composant ainsi que le pilote du noyau utilisé.

Vous pouvez ensuite rechercher tous les événements concernant cette adresse PCIe :

sudo journalctl -k | grep -i "03:00.0"

Cela permet de déterminer si les erreurs concernent systématiquement le même périphérique ou la même liaison PCIe.

Surveiller surtout la répétition des erreurs

Comme pour les erreurs ECC ou MCE, une erreur PCIe corrigée isolée n’indique pas nécessairement une panne matérielle. En revanche, des centaines ou milliers d’erreurs corrigées, des erreurs Uncorrected/Fatal, des pertes de liaison ou des resets répétés doivent être examinés.

Selon le périphérique concerné, vérifiez alors :

• Le pilote Linux et le firmware du périphérique.
• Le BIOS/UEFI de la carte mère.
• Le branchement et le slot PCIe sur un PC ou serveur permettant cette vérification.
• L’alimentation du périphérique.
• Les températures.
• Pour un SSD NVMe, son état SMART et ses propres journaux d’erreurs.

L’intérêt de rasdaemon est surtout de pouvoir déterminer si ces événements s’accumulent au fil des jours ou des semaines. Une augmentation régulière des erreurs sur la même adresse PCIe constitue un indice beaucoup plus significatif qu’un événement isolé observé au démarrage.

Mettre en place une surveillance régulière sur un serveur

Sur un serveur fonctionnant en continu, l’intérêt de rasdaemon est surtout de pouvoir suivre l’évolution des erreurs matérielles dans le temps. Une erreur corrigée isolée peut être sans conséquence, tandis qu’une augmentation régulière des erreurs ECC/EDAC, MCE ou PCIe/AER peut révéler une dégradation progressive d’un composant.

Commencez par vérifier périodiquement le résumé des événements :

sudo ras-mc-ctl --summary

Puis, si de nouvelles erreurs apparaissent, consultez leur détail :

sudo ras-mc-ctl --errors

Vous pouvez également vérifier les événements récents du noyau :

sudo journalctl -k --since "24 hours ago" | grep -i -E "hardware error|mce|machine check|edac|pcie.*error|aer.*error|uncorrected|fatal"

Automatiser la vérification avec un script

Sur un serveur important, vous pouvez créer un petit script chargé d’enregistrer régulièrement l’état de rasdaemon.

Par exemple, créez le fichier :

sudo nano /usr/local/sbin/check-ras.sh

Ajoutez :

#!/bin/bash

LOG="/var/log/ras-monitor.log"

{
    echo "===== $(date) ====="
    ras-mc-ctl --summary
    echo
} >> "$LOG" 2>&1

Enregistrez le fichier puis rendez-le exécutable :

sudo chmod 750 /usr/local/sbin/check-ras.sh

Testez-le manuellement :

sudo /usr/local/sbin/check-ras.sh

Puis vérifiez le résultat :

sudo tail -50 /var/log/ras-monitor.log

Exécuter automatiquement la vérification

Vous pouvez ensuite exécuter ce script régulièrement avec cron ou un timer systemd. Pour une simple surveillance matérielle, une vérification quotidienne est généralement suffisante : les événements restent enregistrés par rasdaemon entre deux contrôles.

L’objectif n’est toutefois pas simplement d’accumuler des rapports. Il faut surtout pouvoir détecter l’apparition de nouvelles erreurs ou l’augmentation de leur fréquence.

Par exemple :

• Des erreurs ECC corrigées qui augmentent régulièrement sur le même DIMM peuvent indiquer une barrette mémoire à surveiller.
• Des MCE répétées peuvent orienter vers le CPU, la RAM, le contrôleur mémoire ou la carte mère.
• Des erreurs PCIe/AER répétées sur la même adresse PCIe peuvent signaler un problème de périphérique, de liaison, de slot ou de pilote.
• Une erreur Uncorrected ou Fatal doit conduire à examiner rapidement le composant concerné.

Sur un serveur critique, il est préférable de conserver l’historique des événements plutôt que de réinitialiser régulièrement la base rasdaemon. Cela permet de comparer leur fréquence sur plusieurs jours ou semaines et de détecter une éventuelle dégradation matérielle avant qu’elle ne provoque une panne.

Tableau des commandes rasdaemon et ras-mc-ctl

Le tableau suivant récapitule les principales commandes rasdaemon et ras-mc-ctl utiles pour surveiller et diagnostiquer les erreurs matérielles sous Linux.

Commande	Description
rasdaemon --version	Afficher la version de rasdaemon installée
rasdaemon --help	Afficher les options disponibles
sudo systemctl enable --now rasdaemon	Activer rasdaemon au démarrage et lancer immédiatement le service
systemctl status rasdaemon	Vérifier l’état du service rasdaemon
systemctl is-active rasdaemon	Vérifier rapidement si rasdaemon fonctionne
sudo journalctl -u rasdaemon -e	Afficher les derniers messages du service rasdaemon
sudo journalctl -u rasdaemon -f	Suivre les messages du service en temps réel
systemctl cat rasdaemon	Afficher le fichier unit systemd et vérifier les options de démarrage
sudo rasdaemon --record	Lancer rasdaemon avec l’enregistrement des événements dans sa base de données
sudo ras-mc-ctl --summary	Afficher un résumé des erreurs matérielles enregistrées
sudo ras-mc-ctl --errors	Afficher le détail des erreurs matérielles enregistrées
sudo dmidecode --type memory	Identifier les barrettes et emplacements mémoire lors de l’analyse d’erreurs ECC/EDAC
lspci	Identifier les périphériques PCI/PCIe
lspci -s 03:00.0 -k	Identifier le périphérique et le pilote correspondant à une adresse PCIe précise
sudo journalctl -k	Consulter les événements matériels enregistrés par le noyau
sudo journalctl -k -b -1	Examiner les événements du noyau du démarrage précédent après un plantage

Pour un contrôle rapide de la santé matérielle, commencez généralement par :

sudo ras-mc-ctl --summary

Si des événements apparaissent, affichez ensuite leur détail :

sudo ras-mc-ctl --errors

Puis complétez l’analyse avec les journaux du noyau :

sudo journalctl -k

Après un plantage ou un redémarrage inattendu, utilisez plutôt :

sudo journalctl -k -b -1

L’objectif est de croiser les informations : rasdaemon permet de suivre l’historique des événements RAS, tandis que journalctl fournit le contexte du noyau autour de l’erreur. Une accumulation d’erreurs ECC/EDAC, MCE ou PCIe/AER sur le même composant est généralement plus significative qu’un événement corrigé et isolé.

L’article rasdaemon : surveiller et diagnostiquer les erreurs matérielles sous Linux est apparu en premier sur malekal.com.

Votre PC sous Windows 11/10 n’est plus à la bonne heure ? L’horloge affiche une heure en avance, en retard ou se remet systématiquement à zéro après chaque démarrage ? Ce problème est plus fréquent qu’on ne le pense et peut avoir des conséquences sur le bon fonctionnement de Windows et de certaines applications.

Une heure incorrecte peut empêcher la synchronisation de fichiers, provoquer des erreurs de certificats HTTPS dans les navigateurs Web, perturber Windows Update, empêcher la connexion à certains services en ligne ou encore provoquer des dysfonctionnements avec Outlook, OneDrive, Steam ou Microsoft Store.

Les causes sont nombreuses : mauvais fuseau horaire, échec de la synchronisation avec un serveur de temps (NTP), service Temps Windows défaillant, pile CMOS déchargée, problème dans le BIOS/UEFI ou encore dual boot entre Windows et Linux.

Dans ce guide, découvrez toutes les causes possibles d’une mauvaise heure sous Windows 11/10 ainsi que les solutions pour retrouver une horloge parfaitement synchronisée.

Quelles sont les causes d’une mauvaise heure sur Windows 11/10

Une heure incorrecte sur Windows 11/10 peut avoir plusieurs origines. Dans la plupart des cas, le problème provient d’un mauvais paramétrage de Windows, d’un défaut de synchronisation avec les serveurs de temps ou d’un problème matériel comme une pile CMOS usée.

Le tableau ci-dessous présente les causes les plus fréquentes ainsi que les solutions à envisager.

Symptôme	Cause probable	Solution
L’heure est décalée d’une ou plusieurs heures	Fuseau horaire incorrect ou réglage automatique désactivé	Vérifier le fuseau horaire et les paramètres de date et d’heure
L’heure avance ou retarde de quelques minutes	Échec de la synchronisation avec un serveur de temps (NTP)	Vérifier la synchronisation automatique et relancer une synchronisation
L’heure est remise à zéro après chaque arrêt du PC	Pile CMOS déchargée	Remplacer la pile CR2032 de la carte mère
L’heure est déjà incorrecte dès l’écran du BIOS/UEFI	Mauvais réglage de l’horloge du BIOS ou pile CMOS défectueuse	Corriger l’heure dans le BIOS/UEFI et contrôler la pile
L’heure devient incorrecte après avoir utilisé Linux en double démarrage	Windows et Linux utilisent des méthodes différentes pour gérer l’horloge matérielle (UTC ou heure locale)	Configurer les deux systèmes pour utiliser le même mode
L’heure change régulièrement sur un PC d’entreprise	Synchronisation imposée par un contrôleur de domaine Active Directory	Vérifier la configuration réseau avec l’administrateur informatique
L’heure est incorrecte après une sortie de veille ou d’hibernation	Problème de reprise de l’horloge ou de synchronisation	Redémarrer Windows et vérifier le service Windows Time
L’heure est incorrecte dans une machine virtuelle	Synchronisation avec l’hôte désactivée ou mal configurée	Vérifier les paramètres de synchronisation de l’hyperviseur

Vérifier le fuseau horaire

Un mauvais fuseau horaire est l’une des causes les plus fréquentes d’une heure incorrecte sur Windows 11/10. Dans ce cas, l’horloge est généralement décalée d’une ou plusieurs heures alors que les minutes sont correctes.

Par exemple, si votre PC est configuré sur le fuseau (UTC-05:00) Est (États-Unis et Canada) au lieu de (UTC+01:00) Bruxelles, Copenhague, Madrid, Paris, l’heure affichée sera erronée même si la synchronisation avec les serveurs de temps fonctionne correctement.

Pour vérifier le fuseau horaire :

• Ouvrez les Paramètres de Windows avec le raccourci Windows + I.
• Accédez à Heure et langue > Date et heure.
• Vérifiez que le Fuseau horaire correspond bien à votre pays ou à votre région.
• Si nécessaire, activez également l’option Définir le fuseau horaire automatiquement si votre ordinateur est portable et change régulièrement de pays.

Une fois le bon fuseau horaire sélectionné, vérifiez si l’heure affichée est désormais correcte. Si ce n’est pas le cas, le problème provient probablement de la synchronisation de l’horloge ou d’un autre dysfonctionnement.

Suivez ce tutoriel :

Vérifier que la synchronisation automatique fonctionne

Windows 11/10 synchronise automatiquement l’horloge avec un serveur de temps (NTP) sur Internet. Cette opération permet de maintenir une heure précise sans intervention de votre part.

Si cette synchronisation échoue, l’horloge peut progressivement prendre de l’avance ou du retard, voire ne plus se mettre à jour du tout. Cela peut être dû à un service Windows désactivé, un serveur de temps indisponible, un pare-feu ou un problème de connexion Internet.

Pour vérifier que la synchronisation automatique est activée :

• Ouvrez les Paramètres avec Windows + I.
• Accédez à Heure et langue > Date et heure.
• Vérifiez que l’option Définir l’heure automatiquement est activée.
• Dans la section Paramètres supplémentaires, cliquez sur Synchroniser maintenant afin de lancer une synchronisation immédiate.

Si la synchronisation réussit, Windows affiche la date et l’heure de la dernière synchronisation.

En revanche, si un message d’erreur apparaît ou que la synchronisation échoue systématiquement, il est probable que le service Windows Time, le serveur NTP ou un autre composant de Windows soit en cause.

Le guide complet :

Après une synchronisation réussie, vérifiez que l’heure affichée est correcte. Si le problème réapparaît après un redémarrage ou quelques heures d’utilisation, il peut s’agir d’un problème matériel, notamment une pile CMOS déchargée ou une horloge du BIOS/UEFI mal configurée.

Synchroniser l’heure manuellement

Si l’heure de votre PC est incorrecte, vous pouvez lancer une synchronisation manuelle avec un serveur de temps afin de remettre immédiatement l’horloge à l’heure.

Cette opération est utile lorsque la synchronisation automatique ne s’est pas effectuée depuis plusieurs jours ou après avoir corrigé le fuseau horaire.

Pour synchroniser l’heure manuellement :

• Ouvrez les Paramètres avec le raccourci Windows + I.
• Accédez à Heure et langue > Date et heure.
• Faites défiler la page jusqu’à Paramètres supplémentaires.
• Cliquez sur le bouton Synchroniser maintenant.

Si l’opération réussit, Windows met immédiatement à jour la date et l’heure, puis affiche la date de la dernière synchronisation.

En revanche, si la synchronisation échoue ou qu’un message d’erreur s’affiche, cela peut indiquer un problème avec le service Windows Time, le serveur NTP ou votre connexion réseau.

Suivez ce guide pour résoudre ce problème :

Si la synchronisation manuelle ne corrige pas le problème ou si l’heure redevient incorrecte après un redémarrage, poursuivez les vérifications ci-dessous, notamment l’heure du BIOS/UEFI et l’état de la pile CMOS

Vérifier le service Windows Time

Le service Windows Time (W32Time) est chargé de synchroniser l’horloge de Windows avec un serveur de temps (NTP). S’il est arrêté, désactivé ou rencontre un dysfonctionnement, votre ordinateur ne pourra plus mettre automatiquement son horloge à jour.

Vous pouvez vérifier son état de la façon suivante :

• Appuyez sur les touches Windows + R.
• Saisissez services.msc, puis cliquez sur OK.
• Recherchez le service Temps Windows (Windows Time).
• Vérifiez que son État est En cours d’exécution.
• Vérifiez également que son Type de démarrage est réglé sur Manuel (déclenchement) ou Automatique, selon votre configuration.

Si le service est arrêté, cliquez dessus avec le bouton droit de la souris, puis choisissez Démarrer. Vous pouvez ensuite essayer de synchroniser à nouveau l’horloge depuis les paramètres de Windows.

Si le service refuse de démarrer, s’arrête immédiatement ou génère une erreur, cela peut indiquer un problème de configuration, de registre ou de fichiers système.

Le guide :

Si le service Windows Time fonctionne correctement mais que l’heure reste incorrecte, poursuivez les vérifications en contrôlant l’heure enregistrée dans le BIOS/UEFI ainsi que l’état de la pile CMOS.

Vérifier l’heure dans le BIOS/UEFI

Si l’heure reste incorrecte malgré une synchronisation réussie dans Windows, il est recommandé de vérifier l’horloge enregistrée dans le BIOS/UEFI. En effet, Windows utilise l’horloge matérielle de la carte mère au démarrage. Si celle-ci est erronée, le système peut afficher une heure incorrecte avant même d’effectuer une synchronisation avec un serveur de temps.

Cette vérification est particulièrement utile si :

• L’heure est déjà incorrecte dès le démarrage de Windows.
• L’heure est remise à zéro après un arrêt prolongé.
• Le problème réapparaît après chaque redémarrage, malgré une synchronisation réussie.

Pour vérifier l’heure dans le BIOS/UEFI :

• Redémarrez votre ordinateur.
• Pendant le démarrage, appuyez sur la touche permettant d’accéder au BIOS/UEFI (généralement Suppr, F2, F10 ou Échap, selon le fabricant).
• Recherchez la section contenant la date et l’heure système.
• Vérifiez que la date, l’heure et, si disponible, le fuseau horaire sont corrects.
• Corrigez-les si nécessaire, puis enregistrez les modifications avant de quitter le BIOS/UEFI.

Si l’heure du BIOS est correcte mais que Windows affiche une heure différente, le problème provient probablement de la configuration de Windows ou de la synchronisation avec les serveurs de temps.

En revanche, si l’heure du BIOS est également incorrecte, il est fort probable que le problème soit matériel. La cause la plus fréquente est une pile CMOS déchargée, qui ne parvient plus à conserver les paramètres de la carte mère lorsque l’ordinateur est éteint.

La section suivante explique comment reconnaître les symptômes d’une pile CMOS usée et savoir quand il est nécessaire de la remplacer.

Vérifier la pile CMOS

La pile CMOS (généralement une pile bouton CR2032) alimente la mémoire de la carte mère lorsque l’ordinateur est éteint. Elle permet notamment de conserver la date, l’heure et les paramètres du BIOS/UEFI.

Avec le temps, cette pile se décharge naturellement. Lorsqu’elle est usée, l’horloge matérielle ne fonctionne plus correctement et Windows affiche une heure ou une date incorrecte au démarrage.

Les symptômes les plus courants d’une pile CMOS déchargée sont les suivants :

• L’heure et la date sont remises à zéro après un arrêt prolongé de l’ordinateur.
• L’heure est systématiquement incorrecte au démarrage, même après une synchronisation réussie.
• Le BIOS/UEFI perd certains paramètres, comme l’ordre de démarrage ou la configuration du matériel.
• Des messages d’erreur apparaissent au démarrage, tels que CMOS Checksum Error, CMOS Battery Low ou Time-of-Day Clock Stopped.

Pour confirmer que la pile est en cause :

• Vérifiez l’heure directement dans le BIOS/UEFI avant de démarrer Windows.
• Corrigez la date et l’heure, puis enregistrez les modifications.
• Éteignez complètement le PC pendant plusieurs heures ou débranchez-le de l’alimentation.
• Redémarrez l’ordinateur et vérifiez si l’heure du BIOS est de nouveau incorrecte.

Si c’est le cas, il est très probable que la pile CMOS soit déchargée et doive être remplacée.

Le remplacement est généralement simple sur un ordinateur de bureau. Il suffit de remplacer la pile bouton par une CR2032 neuve. Sur certains ordinateurs portables, la pile CMOS peut être intégrée à la carte mère ou reliée par un connecteur, ce qui nécessite un démontage plus important.

Le guide pour vous aider :

Après avoir remplacé la pile :

• Réglez à nouveau la date et l’heure dans le BIOS/UEFI.
• Vérifiez que Windows affiche désormais la bonne heure.
• Lancez une synchronisation manuelle pour vous assurer que l’horloge est correctement mise à jour.

Si le problème persiste malgré une pile neuve, il est alors conseillé de vérifier la configuration de Windows Time, la synchronisation NTP ou un éventuel problème matériel de la carte mère.

Vérifier qu’un logiciel ne modifie pas l’heure

Si l’heure de Windows change régulièrement sans raison apparente, il est possible qu’un logiciel ou un équipement réseau la modifie automatiquement. C’est notamment le cas dans les environnements professionnels, avec certaines machines virtuelles ou des logiciels de synchronisation.

Les cas les plus fréquents sont :

• Un PC intégré à un domaine Active Directory, où l’heure est synchronisée avec un contrôleur de domaine.
• Une machine virtuelle (Hyper-V, VMware, VirtualBox, Proxmox, etc.) configurée pour récupérer l’heure de l’ordinateur hôte.
• Un logiciel de synchronisation NTP tiers, qui remplace le service Windows Time.
• Un logiciel d’administration à distance ou de supervision pouvant modifier l’heure système.
• Un VPN ou une solution de sécurité d’entreprise appliquant des stratégies de synchronisation spécifiques.

Vous pouvez également vérifier la source de synchronisation utilisée par Windows.

Pour cela :

• Ouvrez Invite de commandes ou Windows Terminal en tant qu’administrateur.
• Exécutez la commande suivante :

w32tm /query /source

Si le résultat indique Local CMOS Clock, cela signifie que Windows n’est pas synchronisé avec un serveur de temps et utilise uniquement l’horloge matérielle de l’ordinateur. Cette situation peut expliquer une dérive progressive de l’heure, notamment si la pile CMOS est déchargée.

En revanche, si un serveur NTP ou un contrôleur de domaine est affiché, cela signifie qu’une synchronisation est bien configurée.

Si vous utilisez une machine virtuelle, vérifiez également que les paramètres de l’hyperviseur ne remplacent pas régulièrement l’heure de Windows par celle de l’ordinateur hôte.

Enfin, si votre ordinateur appartient à une entreprise ou à un établissement scolaire, il est normal que l’heure soit imposée par l’administrateur réseau. Dans ce cas, les modifications manuelles sont généralement écrasées lors de la prochaine synchronisation.

Vérifier l’intégrité de Windows

Si aucune des vérifications précédentes n’a permis de résoudre le problème, il est possible que des fichiers système de Windows soient corrompus. Cela peut affecter le fonctionnement du service Windows Time ou d’autres composants chargés de la gestion de la date et de l’heure.

Windows intègre deux outils permettant de détecter et de réparer automatiquement ces fichiers : SFC (System File Checker) et DISM (Deployment Image Servicing and Management).

Pour lancer une vérification :

• Ouvrez Windows Terminal, PowerShell ou Invite de commandes en tant qu’administrateur.
• Exécutez la commande suivante :

sfc /scannow

• Patientez jusqu’à la fin de l’analyse.
• Si des erreurs sont détectées mais ne peuvent pas être réparées, exécutez ensuite la commande suivante :

DISM /Online /Cleanup-Image /RestoreHealth

• Une fois l’opération terminée, redémarrez votre ordinateur.
• Relancez si nécessaire la commande sfc /scannow afin de vérifier que toutes les réparations ont bien été effectuées.

Le guide complet :

Ces outils permettent de réparer de nombreux problèmes liés aux fichiers système de Windows, y compris ceux pouvant empêcher certains services de fonctionner correctement.

Le guide complet :

Si l’heure reste incorrecte après ces réparations, il est probable que le problème provienne d’un défaut matériel, d’une configuration du BIOS/UEFI ou d’une synchronisation réseau défaillante.

Cas du dual-boot Windows/Linux

Si votre ordinateur est configuré en dual boot avec Windows et Linux, il est normal de constater un décalage d’une ou deux heures lorsque vous passez d’un système d’exploitation à l’autre.

Ce problème provient du fait que Windows et Linux n’utilisent pas la même méthode pour interpréter l’horloge matérielle (RTC) :

• Windows considère par défaut que l’horloge du BIOS/UEFI est réglée sur l’heure locale.
• La plupart des distributions Linux considèrent que cette même horloge est réglée en Temps universel coordonné (UTC), puis appliquent le fuseau horaire pour afficher l’heure locale.

Par conséquent, lorsque vous redémarrez d’un système vers l’autre, Windows peut afficher une heure décalée d’une ou deux heures, notamment lors des changements d’heure été/hiver.

Ce problème n’est pas lié à une panne de votre ordinateur ni à un dysfonctionnement du service Windows Time. Il s’agit simplement d’une différence de fonctionnement entre les deux systèmes d’exploitation.

La solution consiste à harmoniser la gestion de l’horloge entre Windows et Linux. Il est généralement recommandé de configurer Linux pour utiliser l’heure locale, plutôt que de modifier le fonctionnement de Windows, afin d’éviter d’éventuels problèmes avec certaines applications.

Trouvez la solution dans ce guide :

Les erreurs de mise à l’heure dans Windows 11/10

Erreur	Cause probable	Solution
Échec de la synchronisation	Windows Time arrêté	Vérifier le service W32Time
Le PC perd l’heure à chaque arrêt	Pile CMOS	Remplacer la pile
Vous n’êtes pas autorisé à effectuer cette tâche	Droits insuffisants	Utiliser un compte administrateur
Le service Windows Time ne démarre pas	Configuration corrompue	Réenregistrer le service
Heure décalée d’une heure	Fuseau horaire incorrect	Corriger le fuseau
Heure fausse après Linux	Dual boot	Configurer le RTC
Heure incorrecte après sortie de veille	Synchronisation interrompue	Relancer la synchronisation
L’heure change toute seule	Hyper-V, VMware, domaine AD	Vérifier la source de synchronisation

L’article Mon PC sous Windows 11/10 n’est pas à l’heure : causes et solutions est apparu en premier sur malekal.com.