Lire les journaux système avec Event Viewer (eventvwr) pour diagnostiquer un problème Windows

Reconnaître le problème avant d’agir

L’Observateur d’événements est utile quand le problème Windows laisse une trace dans le temps : un PC qui redémarre sans prévenir, un logiciel qui se ferme seul, un gel de quelques secondes, un message d’erreur qui disparaît trop vite ou un arrêt brutal. Dans ces cas, le but n’est pas de lire tout le journal, mais de relier un symptôme précis à une heure précise pour éviter les manipulations au hasard.

Choisir un symptôme exploitable

• Redémarrage brutal : le PC coupe ou repart sans écran d’arrêt normal.
• Plantage d’un logiciel : par exemple Word, Outlook ou un logiciel métier qui se ferme d’un coup.
• Blocage temporaire : l’écran fige, puis Windows reprend après quelques secondes.
• Erreur visible mais trop rapide : une alerte apparaît puis disparaît avant que vous puissiez la lire.
• Ralentissement associé à une action claire : ouverture d’un programme, impression, branchement d’un périphérique, sortie de veille.

La bonne méthode consiste à partir d’un fait observable, pas d’une impression vague. « Mon PC bugue » est trop large. En revanche, « redémarrage vers 14 h 32 pendant une visioconférence » ou « fermeture de Word à 09 h 18 après clic sur Imprimer » donne un point de départ solide. C’est ce repère qui permettra ensuite de vérifier dans eventvwr si un événement critique, une erreur ou une source particulière apparaît juste avant ou juste après.

Un événement isolé n’a pas beaucoup de valeur s’il ne correspond pas au moment exact du problème. Dans Event Viewer, il faudra toujours croiser plusieurs éléments : la colonne « Date et heure », la « Source », le « Niveau » et l’« ID de l’événement ». Exemple concret : si le PC a redémarré vers 14 h 32, un événement « Kernel-Power » ID 41 autour de 14 h 32 dans « Journaux Windows > Système » mérite votre attention. Le même ID repéré la veille n’explique pas forcément l’incident du jour.

Point d’attention : un avertissement ancien, répétitif ou sans lien avec votre symptôme réel peut vous faire perdre du temps. Cherchez d’abord ce qui colle au moment exact du problème.

Si vous ne savez pas encore quoi chercher, commencez par noter trois informations avant d’ouvrir l’outil : l’heure approximative, ce que vous faisiez juste avant l’incident et ce que Windows a réellement fait ensuite. Ce trio suffit souvent à distinguer un plantage logiciel d’un souci système, d’un pilote ou d’un arrêt non propre.

Après cette étape, le lecteur peut choisir un symptôme précis à analyser et noter l’heure exacte à rechercher dans Event Viewer.

Quand utiliser cette solution ?

L’Observateur d’événements est utile quand Windows fonctionne encore assez pour ouvrir ses outils, même si le problème n’arrive pas tout le temps. Le bon réflexe est de l’utiliser quand vous pouvez relier le symptôme à un moment précis : un redémarrage brutal vers 14 h 32, un logiciel qui se ferme d’un coup, un écran noir suivi d’un retour sur le Bureau, ou un message d’erreur apparu juste après une mise à jour.

• Utilisez cette méthode après un redémarrage inattendu : dans ce cas, ouvrez Win+R, tapez eventvwr.msc, puis regardez surtout Journaux Windows > Système autour de l’heure exacte du souci.
• Utilisez-la aussi si un programme plante sans raison claire : par exemple un événement Application Error, ID 1000, dans Journaux Windows > Application peut confirmer qu’un logiciel précis s’est arrêté.
• C’est un bon point de départ si le problème a commencé après l’installation d’un pilote, d’une mise à jour Windows ou d’un nouveau logiciel : les journaux servent alors à vérifier si la chronologie colle vraiment à votre piste.
• Cette lecture est particulièrement utile sur un PC de travail ou d’association, car elle permet de noter des faits concrets avant de modifier le système : source, ID d’événement, heure, message et fréquence.
• En revanche, cet outil aide peu si le PC ne démarre plus du tout, si le SSD ou le disque n’est plus détecté dans le BIOS/UEFI, ou si la machine s’éteint immédiatement sans laisser de traces exploitables.

Exemple concret : si l’ordinateur a redémarré tout seul vers 14 h 32, Event Viewer est pertinent. Si vous trouvez dans le journal Système un événement critique Kernel-Power, ID 41, à 14:32:17, vous avez au moins une confirmation du redémarrage non propre. Cela ne donne pas automatiquement la cause, mais cela évite de chercher au hasard du côté d’un logiciel qui n’a rien à voir.

Si vous n’avez aucune heure approximative, aucun symptôme identifiable ou si le problème est purement matériel et immédiat, mieux vaut compléter avec d’autres vérifications : Moniteur de fiabilité, état du disque, mémoire, pilotes ou diagnostic matériel. Si les redémarrages deviennent fréquents, si les erreurs reviennent malgré vos corrections, ou si le poste est important pour votre activité, il est raisonnable de demander un diagnostic humain avant qu’une panne plus sérieuse ne s’aggrave.

Apres cette etape, le lecteur peut décider si eventvwr est le bon point de départ pour son problème Windows et cibler le journal à ouvrir.

Avant de commencer : sauvegarde et précautions

Avant d’ouvrir l’Observateur d’événements, le plus utile est de préparer un minimum de contexte. Sans cela, on se retrouve vite avec des centaines d’entrées sans savoir lesquelles ont un rapport avec le problème réel. Si votre PC a redémarré, figé ou affiché une erreur, notez d’abord le symptôme et l’heure la plus proche possible : par exemple « redémarrage brutal vers 14 h 32 » ou « Word s’est fermé à 09 h 18 après un clic sur Imprimer ». C’est ce repère horaire qui permettra ensuite de viser les bons journaux au lieu de lire toute l’historique.

1. Notez sur papier ou dans un bloc-notes : le symptôme exact, l’heure approximative, ce que vous faisiez juste avant et si le problème s’est produit une seule fois ou plusieurs fois.
2. N’effacez pas les journaux Windows avant le relevé. Dans Event Viewer, vider un journal supprime la chronologie utile et complique la comparaison avant/après.
3. Si le PC reste utilisable mais semble instable, sauvegardez d’abord les fichiers importants sur un support externe ou dans un cloud fiable avant toute réparation plus lourde.
4. Vérifiez que l’heure Windows est correcte. Un horodatage faux peut faire chercher au mauvais moment dans les journaux.
5. Préparez les informations à relever plus tard : journal concerné, date et heure, source, ID de l’événement, niveau et résumé du message.

Deux vérifications simples évitent beaucoup d’erreurs. La première concerne l’horloge système : ouvrez Paramètres > Heure et langue > Date et heure et contrôlez que la date, l’heure et le fuseau horaire sont justes. La seconde concerne la restauration système : si vous envisagez ensuite une correction plus intrusive, vous pouvez vérifier la protection du système avec Win+R → SystemPropertiesProtection. Si la protection est active, créez un point de restauration avant de toucher aux pilotes, aux services ou aux fichiers système.

Exemple concret : si un portable s’éteint brutalement vers 14 h 32, puis redémarre normalement, ne cherchez pas encore la cause. Commencez par noter « arrêt brutal 14 h 32, sur batterie, navigateur ouvert ». Cette précision sera plus utile qu’une recherche vague sur un ID d’événement isolé. De la même façon, si un logiciel plante toujours après la même action, notez cette action exacte : ouverture d’un fichier, impression, export PDF, lancement au démarrage, etc.

Si vous soupçonnez déjà un souci Windows plus large après la lecture des journaux, il pourra être pertinent d’enchaîner avec une vérification de l’intégrité système via DISM et SFC, mais seulement après avoir relevé les événements utiles. À ce stade, l’objectif n’est pas de réparer au hasard : il est de préserver vos données, de garder une chronologie propre et de préparer un diagnostic sérieux. Après cette étape, le lecteur peut ouvrir Event Viewer avec une heure de référence fiable et relever les événements utiles sans brouiller le diagnostic.

Comprendre rapidement ce que montre l’Observateur d’événements

Comprendre rapidement ce que montre l’Observateur d’événements

L’Observateur d’événements sert à relier un symptôme précis à ce que Windows a enregistré au même moment. Pour aller vite, trois emplacements suffisent dans la plupart des dépannages : Vues personnalisées > Événements administratifs pour un premier tri, Journaux Windows > Système pour ce qui touche à Windows, aux pilotes, aux services, au démarrage ou à l’alimentation, et Journaux Windows > Application pour les logiciels qui plantent ou se ferment seuls.

Le journal Système est le bon point de départ si le PC redémarre sans prévenir, fige, perd un périphérique ou affiche un souci lié au démarrage. Le journal Application est plus utile si un programme précis se ferme, si une mise à jour applicative échoue ou si un composant comme .NET provoque une erreur. La vue Événements administratifs mélange plusieurs journaux mais permet de repérer rapidement les entrées critiques et erreurs récentes sans lire des centaines de lignes.

• Date et heure : c’est le repère principal. Commencez toujours par vérifier si l’événement correspond vraiment au moment du problème.
• Niveau : critique et erreur méritent une vérification en priorité ; un avertissement isolé n’est pas forcément la cause du symptôme.
• Source : elle indique quel composant a généré l’entrée, par exemple Kernel-Power, Service Control Manager ou Application Error.
• ID de l’événement : il aide à regrouper les occurrences similaires, mais il ne suffit jamais seul pour poser un diagnostic.
• Catégorie de la tâche : elle donne un contexte complémentaire, utile surtout quand plusieurs événements proches se ressemblent.

Exemple concret : si un PC redémarre brutalement vers 14 h 32, ouvrez Journaux Windows > Système et regardez les événements critiques ou erreurs autour de cette heure. Une entrée Source : Kernel-Power avec ID : 41 confirme un arrêt ou redémarrage non propre. Cela ne désigne pas automatiquement la pièce fautive, mais cela valide que le symptôme a bien été vu par Windows au bon moment.

Autre cas d’usage : un logiciel se ferme seul sans message clair. Dans Journaux Windows > Application, une entrée Source : Application Error avec ID : 1000 peut montrer quel exécutable a planté et à quelle heure. Si l’heure, le nom du programme et le message correspondent à ce que vous avez observé, vous tenez une piste exploitable pour la suite : mise à jour du logiciel, test sans module complémentaire, ou vérification plus large de Windows si plusieurs applications tombent de la même manière.

La règle pratique est simple : privilégiez l’événement qui colle au symptôme, à l’heure exacte et qui se répète, plutôt qu’un avertissement ancien ou isolé. Après cette lecture, le lecteur peut distinguer rapidement quel journal ouvrir et quelles colonnes relever pour avancer vers un diagnostic utile.

Comment faire étape par étape

La méthode la plus fiable avec l’Observateur d’événements consiste à partir d’un symptôme précis, puis à remonter à l’heure où il s’est produit. Si vous ouvrez Event Viewer pour lire des centaines de lignes sans repère, vous risquez surtout de perdre du temps. Ici, l’objectif est d’isoler quelques événements utiles, pas d’interpréter tout Windows.

1. Ouvrez l’outil avec le chemin exact : Win+R → tapez eventvwr.msc → Entrée. Si certains journaux s’ouvrent mal ou semblent incomplets, refaites l’ouverture depuis un compte administrateur.
2. Commencez par Vues personnalisées → Événements administratifs. Cette vue rassemble déjà les événements critiques, erreurs et avertissements importants. C’est le moyen le plus simple pour repérer une piste sans parcourir tous les journaux un par un.
3. Choisissez ensuite le journal adapté au symptôme. Allez dans Journaux Windows → Système pour un redémarrage brutal, un gel, un souci de pilote, un problème d’alimentation ou un service Windows qui échoue. Allez dans Journaux Windows → Application si un logiciel se ferme seul, plante au lancement ou affiche une erreur récurrente.
4. Dans le panneau de droite, cliquez sur Filtrer le journal actuel…. Cochez d’abord Critique et Erreur. Si vous connaissez l’heure du problème, limitez aussi la période. Cette étape évite de se disperser sur des événements anciens ou sans rapport.
5. Triez par Date et heure et concentrez-vous sur la minute du problème, puis sur ce qui s’est passé juste avant et juste après. Exemple : si le PC a redémarré vers 14 h 32, cherchez autour de 14:32 dans le journal Système, pas trois heures plus tôt.
6. Ouvrez chaque événement suspect en double-cliquant dessus. Relevez au minimum la Source, l’ID de l’événement, le Niveau et le texte de l’onglet Général. Un événement isolé a peu de valeur s’il n’est pas cohérent avec le symptôme réel.
7. Cas concret : dans Journaux Windows → Système, un événement Kernel-Power avec l’ID 41 confirme qu’un arrêt ou redémarrage n’a pas été propre. Cela aide à dater l’incident, mais cela ne prouve pas à lui seul si la cause vient de l’alimentation, d’un pilote, d’un plantage matériel ou d’un appui forcé sur le bouton d’alimentation.
8. Autre cas concret : dans Journaux Windows → Application, un événement Application Error avec l’ID 1000 indique qu’un programme précis a planté. Si le même logiciel revient avec la même source et à des heures proches du symptôme, vous tenez une piste exploitable : mise à jour du logiciel, réparation, désinstallation ou test sans ce programme.
9. Si le problème revient régulièrement, vous pouvez faire un clic droit sur un événement récurrent puis utiliser Attacher une tâche à cet événement…. Ce n’est pas indispensable pour un diagnostic ponctuel, mais c’est utile pour surveiller un incident intermittent sur un poste de travail.

Comment lire un événement sans se tromper

• Date et heure : vérifiez que l’événement colle au moment exact du symptôme. Une erreur très ancienne est souvent hors sujet.
• Source : c’est souvent l’indice le plus utile. Elle indique quel composant, service ou logiciel a généré l’événement.
• ID de l’événement : il sert à regrouper les incidents similaires, mais il ne doit jamais être interprété seul.
• Niveau : un Critique ou une Erreur mérite d’être lu en priorité. Un Avertissement n’est pas forcément grave.
• Onglet Général : lisez le message complet avant de tirer une conclusion. C’est souvent là que le nom du programme, du service ou du module fautif apparaît.

Ce qu’il faut noter pour la suite du diagnostic

• Le journal concerné : Système, Application ou Événements administratifs.
• La source exacte de l’événement.
• L’ID de l’événement.
• L’heure précise de l’incident.
• Le message affiché dans l’onglet Général.
• Le fait que l’événement soit isolé ou répétitif.
• L’action faite juste avant : ouverture d’un logiciel, mise en veille, branchement d’un périphérique, mise à jour, impression, etc.

Si plusieurs événements pointent vers Windows lui-même plutôt que vers un logiciel précis, la suite logique peut être une réparation ciblée des fichiers système avec SFC ou DISM. Si ce cas correspond à ce que vous voyez dans les journaux, vous pouvez ensuite consulter ce guide sur DISM et SFC pour vérifier Windows sans lancer des réparations au hasard.

Points d’attention utiles : ne videz pas les journaux avant d’avoir pris vos notes, méfiez-vous des erreurs anciennes qui n’ont aucun lien avec votre panne, et vérifiez que l’horloge de Windows est correcte. Si la date ou l’heure du PC est fausse, toute la lecture des événements devient trompeuse.

Apres cette etape, le lecteur peut relever les evenements utiles, les relier au symptome reel et choisir une piste de diagnostic concrete.

Comment savoir si ça a marché

La lecture des journaux est utile si elle vous permet de passer d’un symptôme flou à une piste vérifiable. Le bon résultat n’est donc pas seulement de voir moins d’erreurs dans l’Observateur d’événements, mais d’identifier un événement cohérent avec le problème réel, puis de constater qu’il disparaît ou change après une action ciblée.

Exemple concret : votre PC a redémarré brutalement vers 14 h 32 et vous avez relevé dans Journaux Windows > Système un événement Kernel-Power avec l’ID 41. Si vous corrigez ensuite une piste plausible, comme un pilote défectueux ou un problème d’alimentation sur un portable, la vérification consiste à regarder si le redémarrage se reproduit et si le même événement réapparaît à nouveau autour de l’heure du symptôme. Pour un logiciel qui se ferme seul, le même principe s’applique dans Journaux Windows > Application avec un événement comme Application Error, ID 1000.

Vérification pratique après une correction

1. Notez votre point de départ avant toute modification : journal concerné, source, ID de l’événement, heure exacte et fréquence. Sans cette référence, il est difficile de savoir si la situation s’améliore vraiment.
2. Appliquez une seule correction à la fois. Par exemple : mise à jour d’un pilote, désinstallation d’un logiciel fautif, réparation Windows si les indices pointent vers le système.
3. Refaites le test seulement si c’est sans risque. Si le problème apparaît à l’ouverture d’un logiciel, relancez ce logiciel. S’il survient au démarrage, redémarrez normalement l’ordinateur.
4. Ouvrez à nouveau l’outil avec Win+R → eventvwr.msc, puis revenez dans le même journal que lors du premier relevé : Journaux Windows > Système ou Journaux Windows > Application.
5. Utilisez Filtrer le journal actuel… pour afficher au minimum les niveaux Critique et Erreur, puis vérifiez les événements à l’heure du nouveau test.
6. Comparez précisément l’avant et l’après : même source, même ID, même message, même moment, même fréquence ou disparition complète de l’événement.
7. Si l’événement a disparu et que le symptôme aussi, la piste est probablement bonne. Si le symptôme reste présent avec les mêmes événements, la correction n’a pas réglé la cause. Si les événements changent mais que le problème reste, vous avez peut-être traité une conséquence au lieu de la source.

Ce qui confirme une vraie amélioration

• Le problème ne se reproduit plus dans les mêmes conditions.
• Le même événement ne revient plus dans le journal au moment du test.
• L’événement existe encore, mais il n’est plus suivi du symptôme visible pour l’utilisateur.
• La fréquence baisse nettement : par exemple plusieurs erreurs par jour avant correction, puis aucune pendant plusieurs jours d’usage normal.
• Vous pouvez relier une action précise à un changement observable, au lieu de supposer que « ça a l’air mieux ».

Un bon diagnostic doit déboucher sur une décision concrète. Si le journal n’affiche plus l’erreur après une mise à jour de pilote, vous pouvez continuer à surveiller. Si un plantage applicatif revient avec la même source et le même ID, la suite logique est de tester ou réparer ce logiciel. Si les événements pointent plutôt vers Windows lui-même, un contrôle avec SFC ou DISM peut devenir pertinent. Si les erreurs évoquent l’alimentation, le disque ou la mémoire, il faut passer à des vérifications matérielles au lieu de rester bloqué dans Event Viewer.

Point d’attention : une longue liste d’erreurs ne signifie pas forcément que tout va mal. Ce qui compte, c’est la correspondance entre l’heure, la source, l’ID et le symptôme observé. Une erreur ancienne, isolée ou sans rapport direct avec le problème du jour ne doit pas orienter toute votre recherche.

Si vous n’arrivez pas à établir ce lien malgré plusieurs essais, ou si le PC redémarre souvent, se fige sans prévenir ou sert à une activité importante, mieux vaut préparer un relevé propre des événements et passer à un diagnostic plus large. Apres cette etape, le lecteur peut confirmer si la piste reperee dans Event Viewer est utile, la surveiller dans le temps ou choisir une autre action de depannage plus adaptee.

Solutions alternatives si le journal ne parle pas clairement

Si l’Observateur d’événements n’affiche rien de vraiment exploitable, ce n’est pas forcément un échec. Certains problèmes Windows laissent des traces trop vagues, arrivent trop vite pour être bien journalisés, ou pointent vers autre chose qu’un simple événement système. Dans ce cas, l’objectif n’est plus de lire plus de lignes, mais de croiser une autre source d’information avec l’heure exacte du symptôme.

Utiliser le Moniteur de fiabilité pour retrouver une chronologie plus lisible

1. Appuyez sur Win+R, tapez perfmon /rel, puis validez.
2. Repérez le jour et l’heure du plantage, du redémarrage ou du gel.
3. Cliquez sur la croix rouge ou l’avertissement du moment concerné.
4. Ouvrez le détail de l’incident et comparez le nom du programme, la date et le type de panne avec ce que vous avez vu dans eventvwr.

Cet outil est souvent plus simple à lire qu’Event Viewer quand le problème concerne un logiciel. Exemple concret : si Word s’est fermé seul vers 09 h 18 et que le journal Application reste trop verbeux, le Moniteur de fiabilité peut afficher directement « Microsoft Word a cessé de fonctionner » le bon jour. À partir de là, la piste devient plus claire : complément Office, mise à jour récente, profil utilisateur ou réparation d’Office, au lieu de chercher dans tout le journal.

Vérifier les pilotes et périphériques liés au symptôme

Quand le journal Système ne montre qu’une erreur générale ou un redémarrage brutal, vérifiez le périphérique qui correspond au moment de la panne. Ouvrez Win+R → devmgmt.msc. Dans le Gestionnaire de périphériques, regardez en priorité la carte graphique si l’écran se fige, le contrôleur de stockage si le PC ralentit ou se bloque, et la carte réseau si les coupures internet coïncident avec le problème. Un triangle jaune, un périphérique désactivé ou un pilote revenu à une ancienne version après mise à jour donne une piste bien plus utile qu’un ID isolé.

• Après une mise à jour Windows : vérifier si le pilote a changé juste avant l’apparition du bug.
• Après ajout d’un écran, d’une imprimante ou d’un dock USB : contrôler le périphérique nouvellement installé.
• Après un gel en jeu ou en visio : commencer par la carte graphique et l’audio, puis observer si le problème revient au même usage.

Contrôler l’intégrité de Windows si plusieurs indices pointent vers le système

Si vous relevez des erreurs dispersées sur des composants Windows, des services qui démarrent mal, ou des comportements incohérents sans logiciel précis en cause, la suite logique est de vérifier les fichiers système. Vous pouvez alors passer à SFC et DISM, qui sont détaillés dans cet article : DISM et SFC : réparer Windows sans tout réinstaller. Cette étape est pertinente quand les journaux ne donnent pas une cause unique mais suggèrent une corruption du système plutôt qu’un simple bug applicatif.

Écarter une piste matérielle avant de corriger au hasard

Un événement absent ou trop vague peut aussi cacher un souci matériel. Si le PC redémarre sans message, coupe net, gèle complètement ou devient anormalement lent, testez au moins la mémoire et le stockage. Pour la mémoire, ouvrez Win+R → mdsched.exe afin de lancer l’outil de diagnostic mémoire au redémarrage. Si vous suspectez un disque fatigué, observez aussi les symptômes concrets : lenteurs soudaines, fichiers qui s’ouvrent mal, démarrage très long, bruits inhabituels sur un disque mécanique. Sur une machine ancienne, les pistes SSD, RAM ou alimentation sont parfois plus crédibles qu’une erreur logicielle. Si ce contexte vous parle, cet article peut aider à recadrer le diagnostic : Vieux PC lent : il n’est peut-être pas bon pour la casse.

Si aucun événement utile n’apparaît malgré ces vérifications, pensez à trois causes fréquentes : l’heure Windows est fausse, le problème est trop ancien et noyé dans l’historique, ou la panne se produit en dehors de ce que Windows peut journaliser correctement. C’est fréquent lors d’une coupure d’alimentation, d’un défaut de RAM, d’un SSD en fin de vie ou d’un plantage très brutal.

Pour savoir si cette étape vous a vraiment fait avancer, vous devez pouvoir nommer une piste principale et laisser de côté les autres. Par exemple : « le plantage correspond surtout à Word », « le pilote graphique est suspect depuis la dernière mise à jour », ou « rien de logiciel n’est convaincant, je dois tester la RAM et le disque ». Si vous n’arrivez toujours pas à dégager une piste après croisement entre perfmon /rel, devmgmt.msc et un contrôle système, il vaut mieux passer à un diagnostic plus large ou demander de l’aide, surtout sur un PC de travail ou si les redémarrages se répètent. Apres cette etape, le lecteur peut choisir la bonne suite de diagnostic sans multiplier les manipulations au hasard.

Limites / que faire si cela ne suffit pas ?

L’Observateur d’événements aide à relier un symptôme à un moment précis, mais il ne donne pas toujours la cause finale. Un événement peut être la conséquence d’un autre problème plus profond. Exemple concret : dans Win+R → eventvwr.msc → Journaux Windows → Système, un Kernel-Power, ID 41 confirme qu’un arrêt ou redémarrage a été brutal, mais il ne prouve pas à lui seul si la cause vient de l’alimentation, d’un pilote, d’une surchauffe ou d’un plantage matériel.

Le point qui piège le plus souvent est l’interprétation d’un ID d’événement isolé. Pour qu’un journal soit vraiment utile, il faut toujours croiser au minimum quatre éléments : l’heure exacte, la source, le message et le symptôme observé. Une erreur ancienne, répétée depuis des semaines mais sans lien avec le problème du jour, peut faire perdre beaucoup de temps.

Cas où les journaux Windows ne suffisent pas

• Le PC se coupe trop vite pour laisser une trace exploitable dans Windows.
• L’horloge système est fausse : les événements existent, mais ils ne correspondent pas à la bonne heure.
• Le journal est trop verbeux et mélange des avertissements habituels avec le vrai incident.
• Le problème est matériel et intermittent : SSD fatigué, RAM instable, alimentation défaillante, surchauffe.
• L’événement visible n’est qu’un effet secondaire. Par exemple, un plantage logiciel dans Journaux Windows → Application peut être causé en amont par un pilote ou un fichier système corrompu.

Que faire ensuite, de façon logique

1. Relevez trois événements maximum autour de l’heure du problème, pas davantage : source, ID, heure, message.
2. Gardez seulement ceux qui collent vraiment au symptôme. Si le PC a redémarré à 14 h 32, ignorez les erreurs sans rapport apparues à 9 h ou la veille.
3. Si les indices pointent vers Windows lui-même, passez à une vérification système avec DISM et SFC.
4. Si cela évoque un pilote ou un périphérique, contrôlez le matériel concerné dans Win+R → devmgmt.msc et vérifiez les mises à jour ou retours arrière récents.
5. Si aucun événement clair n’apparaît, utilisez le Moniteur de fiabilité pour obtenir une chronologie plus lisible des plantages.
6. Si le doute porte sur le matériel, faites un diagnostic plus large : mémoire, état du disque, température, alimentation.

La bonne réaction n’est pas de multiplier les réparations en même temps. Si vous changez un pilote, lancez SFC, désinstallez un logiciel et modifiez l’alimentation dans la même journée, vous ne saurez plus quelle action a eu un effet. Choisissez une seule piste, testez, puis revenez dans Event Viewer pour voir si le même événement réapparaît.

Quand demander l’aide d’un professionnel

• Les redémarrages ou gels deviennent fréquents.
• Le PC sert au travail, à une association ou à une activité qui ne peut pas se permettre des essais hasardeux.
• Les mêmes erreurs reviennent malgré les corrections déjà tentées.
• Vous suspectez un SSD, de la RAM, l’alimentation ou la carte mère.
• Vous avez relevé les événements, mais leur interprétation reste trop incertaine pour agir sans risque.

Action utile tout de suite : ouvrez eventvwr.msc, relevez les trois événements les plus proches de l’heure du problème, comparez leur source et leur ID avec votre symptôme réel, puis choisissez une seule piste de correction. Si cette piste touche à la stabilité du système ou au matériel, mieux vaut passer à un diagnostic assisté plutôt que d’insister au hasard. Apres cette etape, le lecteur peut decider s’il a une piste fiable a tester seul ou s’il doit demander une aide professionnelle.

À lire aussi

• DISM et SFC : les commandes miracles pour réparer Windows sans tout réinstaller
• PC bloqué sans raison apparente : attention aux logiciels de sécurité mal configurés
• Quand Avast protège… puis complique : comprendre les problèmes fréquents et les alternatives possibles

FAQ — Questions fréquentes