Une application se ferme brutalement et l’Observateur d’événements affiche Application Error, ID 1000 ? Ce message confirme un plantage du programme, mais il ne donne pas toujours sa cause. Le nom du module défaillant, le code d’exception et les circonstances de l’incident permettent d’orienter la recherche.

Dans ce guide pour Windows 11 et Windows 10, vous allez apprendre à lire un événement 1000, comprendre les mentions KERNELBASE.dll, ntdll.dll ou ucrtbase.dll, croiser les rapports et choisir les vérifications pertinentes. Si le diagnostic reste incertain, vous pourrez compléter les informations avec AnalysePC ou recueillir un fichier de vidage pour l’éditeur du logiciel.

Qu’est-ce que l’erreur Application Error 1000 ?

Dans le journal Application, un événement 1000 de la source Application Error décrit un crash d’application. Le logiciel peut se fermer pendant son utilisation ou immédiatement après son lancement. Cet ID doit être lu avec sa source : un numéro 1000 provenant d’un autre composant ne désigne pas forcément le même problème.

Il s’agit d’une trace du plantage, pas d’un diagnostic complet. Deux applications peuvent générer le même ID pour des raisons différentes, et un seul incident peut produire plusieurs rapports associés.

Situation	Guide à privilégier
Vous avez identifié Application Error 1000	Poursuivez ici pour interpréter le crash.
Le programme reste ouvert avec « Ne répond pas »	Le guide Application Hang 1002 concerne ce blocage.
Le programme ne s’ouvre pas, sans trace de crash identifiée	Le guide sur les applications qui ne s’ouvrent pas constitue le point de départ.
L’application se ferme et vous ne savez pas encore pourquoi	Le guide sur les fermetures inattendues présente les vérifications générales.

Si la fenêtre reste figée :

Si le programme refuse de démarrer :

Retrouver l’événement correspondant au plantage

Notez l’heure du crash et le logiciel concerné. Une erreur ancienne peut ne pas correspondre au problème que vous êtes en train d’analyser.

• Appuyez sur + R, saisissez eventvwr.msc et validez.
• Dans le volet de gauche, ouvrez Journaux Windows > Application.
• Cliquez sur Filtrer le journal actuel et limitez la période à celle du problème.
• Indiquez 1000 dans le champ des ID d’événements, puis validez.
• Sélectionnez une entrée dont la source est Application Error et vérifiez que l’application et l’heure correspondent.
• Ouvrez l’onglet Général, puis copiez les détails sous forme de texte pour les conserver.

Le filtre peut afficher des ID 1000 d’autres sources. Vérifiez toujours le couple source + ID. Si aucune entrée pertinente n’apparaît, consultez le Moniteur de fiabilité ou les rapports propres au logiciel ; toute fermeture n’est pas nécessairement enregistrée sous cette forme.

Pour consulter les autres traces et exporter un événement :

Lire les détails : application, module défaillant et code d’exception

Voici un exemple fictif et simplifié. Les valeurs servent uniquement à expliquer la lecture du message ; elles ne correspondent pas à une panne réelle ni à une version précise de Windows.

Source : Application Error
ID de l’événement : 1000
Nom de l’application défaillante : MonLogiciel.exe
Version de l’application : 3.2.0.0
Nom du module défaillant : KERNELBASE.dll
Code d’exception : 0xc0000005
Décalage d’erreur : 0x0000000000012345
Chemin de l’application : C:\Program Files\MonLogiciel\MonLogiciel.exe
Chemin du module : C:\Windows\System32\KERNELBASE.dll

Information	Comment l’utiliser ?
Application défaillante et chemin	Identifiez le programme réellement concerné, notamment si plusieurs exécutables ont des noms proches.
Version de l’application	Comparez les incidents avant et après une mise à jour du logiciel.
Module défaillant et chemin	Repérez une bibliothèque Windows, une extension ou un composant livré avec l’application.
Code d’exception	Il décrit le type d’exception, sans identifier à lui seul le responsable.
Décalage d’erreur	Il aide surtout l’éditeur ou le développeur à localiser l’endroit du crash pour une version donnée.
Identifiant du rapport, s’il est présent	Conservez-le pour rapprocher les informations de rapports associés.

Dans l’exemple, MonLogiciel.exe est le programme à examiner en premier. La présence de KERNELBASE.dll ne justifie pas de remplacer cette DLL. Pour rendre une recherche utile, associez le nom du logiciel, sa version, le module et le code ; « erreur 1000 » seul est trop général.

Quelques codes que vous pouvez rencontrer :

Code	Sens général	Ce qu’il ne prouve pas
0xc0000005	Violation d’accès mémoire.	Ce n’est pas une preuve de RAM défectueuse : un problème logiciel peut provoquer une opération mémoire invalide.
0xc0000374	Corruption du tas mémoire du processus.	Il ne désigne pas automatiquement le composant qui a initialement altéré la mémoire.
0xc0000022	Accès refusé.	Il ne justifie pas de donner des permissions étendues à tous les fichiers ou de désactiver les protections.

Le code doit être confronté aux circonstances. Un crash lors du chargement d’une extension et un crash pendant l’ouverture d’un document peuvent nécessiter des tests différents, même si l’exception est identique.

KERNELBASE.dll, ntdll.dll ou ucrtbase.dll : que peut-on en déduire ?

Ces bibliothèques sont utilisées par de nombreuses applications. Un crash peut se manifester dans leur code après une erreur commise ailleurs. Le module défaillant indique où l’exception a été constatée ; il ne désigne pas systématiquement l’origine du problème.

Module	Lecture utile pour le diagnostic
KERNELBASE.dll	Une bibliothèque Windows partagée par beaucoup de programmes. Revenez au logiciel et à l’opération qui déclenchent le crash.
ntdll.dll	Un composant bas niveau de Windows qui peut apparaître lors de problèmes de fonctionnement du processus. Il faut d’autres traces pour attribuer la cause.
ucrtbase.dll	Un composant de la bibliothèque d’exécution C. Sa présence peut orienter vers le comportement du programme ou de ses dépendances, sans prouver une installation endommagée.
DLL d’une extension ou d’un logiciel tiers	Une piste plus ciblée si le crash survient après son installation ou pendant son utilisation. Testez cette piste avant de conclure.

Évitez les sites proposant de télécharger ces DLL séparément. Si une dépendance est réellement absente ou défectueuse, utilisez l’installateur officiel du programme ou le package recommandé par son éditeur. Ne réinstallez pas tous les runtimes simplement parce qu’un nom de DLL apparaît.

Croiser l’événement 1000 avec les autres rapports de plantage

Une seule ligne du journal est rarement suffisante pour comprendre un crash répétitif. Comparez les incidents entre eux et recherchez les informations disponibles pour la même tentative.

• Ouvrez le Moniteur de fiabilité avec perfmon /rel, puis consultez les détails du problème à la date correspondante.
• Dans le journal Application, recherchez un événement Windows Error Reporting 1001 proche du crash, lorsqu’il existe.
• Consultez le journal ou le rapport de crash fourni par le logiciel lui-même.
• Vérifiez les changements récents et les messages enregistrés juste avant l’incident.

Le rapport Windows Error Reporting peut correspondre au même incident que l’événement 1000. Ne comptez pas chaque trace comme un crash supplémentaire. À l’inverse, un événement 1001 d’une autre source peut décrire un autre type de problème.

Pour comparer les plantages, notez dans un petit tableau : date, application, version, module, code et action en cours. Si le même document ou la même extension déclenche systématiquement le crash, vous obtenez un test reproductible à communiquer à l’éditeur.

Pour comprendre l’historique et ses détails :

Diagnostiquer le problème lorsqu’une seule application plante

Lorsque le reste du PC fonctionne normalement, commencez par le programme concerné. Modifiez un élément à la fois et répétez la même action pour vérifier si le crash persiste.

• Vérifiez la version : installez une mise à jour officielle ou consultez les incidents connus si le problème a commencé après une mise à jour.
• Isolez le déclencheur : essayez un autre document, une autre opération ou un projet vierge.
• Testez les extensions et intégrations : utilisez le mode de dépannage prévu par le logiciel ou retirez temporairement l’extension suspectée.
• Examinez le profil de l’application : un profil de test peut aider si l’éditeur propose cette méthode. Préservez les paramètres et données avant une réinitialisation.
• Réparez l’installation si les indices le justifient : utilisez la fonction officielle de réparation ; avant une réinstallation, sauvegardez les données et paramètres nécessaires.

Pour un jeu ou une application graphique, vérifiez aussi les changements de pilote, les overlays et l’accélération matérielle si le symptôme les met en cause. Ne désactivez pas globalement la sécurité de Windows pour essayer de faire disparaître un crash.

Pour les procédures générales de correction :

Que vérifier lorsque plusieurs applications plantent ?

Des crashs dans plusieurs logiciels indépendants peuvent révéler un élément commun. Cela ne signifie pas automatiquement que Windows doit être réinstallé. Cherchez d’abord ce qui a changé et ce que les incidents ont en commun.

Indice observé	Vérification à privilégier
Début des crashs après un pilote ou une mise à jour précise	Consultez les problèmes connus et vérifiez une correction ou un retour arrière adapté.
Plusieurs applications utilisant la même extension ou intégration	Testez le composant partagé et sa version.
Erreurs Disk/Ntfs ou fichiers devenus illisibles	Préservez les données et vérifiez le stockage.
WHEA, écrans bleus ou instabilité après des réglages matériels	Examinez les réglages et effectuez un diagnostic matériel ciblé.
Erreurs de composants Windows et corruption confirmée	Une vérification des fichiers système peut être pertinente.

La mémoire, le stockage ou un réglage matériel instable peuvent produire des crashs variables. En revanche, un événement 1000 isolé, même avec une violation d’accès mémoire, ne suffit pas à justifier le remplacement d’une barrette.

Si les traces orientent vers une corruption de Windows :

Si les symptômes orientent vers le matériel :

Pour interpréter les autres sources d’erreurs :

Compléter le diagnostic avec AnalysePC

AnalysePC interprète un rapport généré par Malekal Optimisation Center (MOC). Il permet de compléter les événements de crash par des informations sur Windows, les pilotes, les services, le stockage et la configuration du PC.

Utilisez-le pour repérer des anomalies à examiner et partager le contexte technique. Rapprochez ses recommandations de la date et des symptômes : une anomalie détectée peut être indépendante du crash. AnalysePC ne remplace pas l’analyse du fonctionnement interne d’une application par son éditeur.

Pour générer le diagnostic et partager son résultat :

Si la cause reste inconnue : recueillir un fichier de vidage et demander de l’aide

Si le crash est reproductible mais que les journaux ne suffisent pas, un fichier de vidage du processus peut aider l’éditeur ou une personne habituée au débogage. Il contient un état du programme à un moment donné ; c’est un outil d’analyse, pas une réparation.

Windows peut être configuré pour recueillir ces fichiers avec WER LocalDumps, mais cette collecte n’est pas activée par défaut. Un dossier CrashDumps absent n’a donc rien d’anormal. Un dump d’application diffère d’un dump système d’écran bleu.

Pour un test ponctuel sur une application de bureau, ProcDump, un outil Microsoft Sysinternals, permet de surveiller un processus et de capturer une exception non gérée. Utilisez de préférence les instructions de l’éditeur s’il dispose déjà d’un outil de collecte.

L’outil officiel :

• Téléchargez et décompressez ProcDump dans un dossier de votre choix.
• Créez le dossier C:\CrashReports pour cet exemple.
• Ouvrez PowerShell dans le dossier de ProcDump, en tant qu’administrateur si le processus l’exige.
• Fermez l’application, puis lancez la commande ci-dessous en remplaçant MonLogiciel.exe par son véritable nom de processus.

.\procdump.exe -ma -e -w MonLogiciel.exe C:\CrashReports

-ma demande un dump complet, -e déclenche la capture sur une exception non gérée et -w attend le démarrage du processus s’il n’est pas lancé. Acceptez la licence affichée, ouvrez le logiciel et reproduisez le problème. Gardez la console ouverte jusqu’à la capture ; Ctrl + C arrête la surveillance.

Si plusieurs processus portent le même nom, ou si le logiciel utilise son propre système de crash, une autre méthode peut être nécessaire. Un programme qui se ferme normalement, même de façon inattendue pour vous, ne déclenche pas forcément cette capture. Ne multipliez pas les options sans comprendre le déclencheur recherché.

Un dump complet peut être volumineux et contenir des informations présentes dans la mémoire du programme, notamment du contenu de documents. Transmettez-le par un canal privé à la personne qui l’analyse et nettoyez les fichiers après le diagnostic.

Pour demander de l’aide, préparez :

• Le nom et la version du logiciel, ainsi que la version de Windows.
• Le texte complet d’Application Error 1000 et les rapports associés disponibles.
• Les actions qui reproduisent le crash et les changements récents.
• Les essais déjà effectués et leur résultat.
• Le lien du rapport AnalysePC ; signalez l’existence d’un dump sans le publier directement.

Pour faire examiner les informations :

Si le crash concerne un logiciel précis, son éditeur reste un interlocuteur utile : un exemple reproductible et un dump peuvent lui permettre de rechercher un défaut que les journaux Windows ne détaillent pas.

L’article Erreur « Application Error » 1000 : diagnostiquer un plantage sur Windows 11/10 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.

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.