Partager via


Résolution avancée des erreurs d’arrêt ou d’écran bleu

Essayez notre agent virtuel : il peut vous aider à identifier et résoudre rapidement les problèmes courants de démarrage de Windows.

Note

Si vous n’êtes pas un agent de support ou un professionnel de l’informatique, vous trouverez des informations plus utiles sur les messages d’erreur d’arrêt (« écran bleu ») dans Résoudre les erreurs d’écran bleu.

S’applique à : Versions prises en charge de Windows Server et du client Windows

Quelles sont les causes des erreurs d’arrêt ?

Lorsque Windows rencontre une condition qui compromet la sécurité du fonctionnement du système, le système s’arrête. Par exemple, un échec peut compromettre la sécurité ou entraîner une altération du système d’exploitation (SE) et/ou des données utilisateur. Lorsque l’ordinateur s’arrête pour empêcher le système d’exploitation de poursuivre dans ces conditions, c’est ce qu’on appelle une vérification des bogues (ou bugcheck). On l’appelle également communément plantage du système, erreur du noyau, écran bleu, écran bleu de la mort (BSOD) ou erreur d’arrêt. Dans les préversions de Windows, la couleur de l’écran peut être verte, et entraîne un écran vert de la mort (GSOD).

Aucune explication simple n’existe quant à la cause des erreurs d’arrêt. De nombreux facteurs différents peuvent être impliqués. Notre analyse des causes racines des incidents indique que :

  • 70 % sont causés par le code du pilote tiers.
  • 10 % sont causés par des problèmes matériels.
  • 5 % sont causés par le code Microsoft.
  • 15 % ont des causes inconnues, car la mémoire est trop endommagée pour être analysée.

Note

La cause racine des erreurs d’arrêt est rarement un processus en mode utilisateur. Même si un processus en mode utilisateur (tel que le Bloc-notes ou Slack) peut déclencher une erreur d’arrêt, il expose généralement le problème sous-jacent dans un pilote, un composant matériel ou le système d’exploitation.

Étapes de dépannage générales

Pour résoudre des messages d’erreur d’arrêt, suivez ces étapes générales :

  1. Passez en revue le code d’erreur d’arrêt que vous trouvez dans les journaux des événements. Recherchez en ligne les codes d’erreur d’arrêt spécifiques pour déterminer s’il existe des problèmes, des résolutions ou des solutions de contournement connus pour le problème.

  2. Veillez à installer les dernières mises à jour Windows, mises à jour cumulatives et correctifs cumulatifs. Pour vérifier l’état de la mise à jour, reportez-vous à l’historique de mise à jour approprié pour votre système. Par exemple :

  3. Assurez-vous que le BIOS et le microprogramme sont à jour.

  4. Exécutez tous les tests matériels et de mémoire appropriés.

  5. Exécutez Scanner de sécurité Microsoft ou tout autre programme de détection de virus qui comprend les vérifications du MBR pour les infections.

  6. Assurez-vous que l’espace libre sur le disque dur est suffisant. L’exigence exacte varie, mais nous vous recommandons 10 à 15 % d’espace disque libre.

  7. Contactez le fournisseur de matériel ou de logiciel correspondant pour mettre à jour les pilotes et les applications dans les scénarios suivants :

    • Le message d’erreur indique qu’un pilote spécifique est à l’origine du problème.
    • Vous voyez une indication d’un service qui démarre ou s’arrête avant que l’incident ne se produise. Dans ce cas, déterminez si le comportement du service est cohérent entre toutes les instances de l’incident.
    • Vous avez apporté des modifications logicielles ou matérielles.

    Note

    Si aucune mise à jour n’est disponible auprès d’un fabricant spécifique, nous vous recommandons de désactiver le service associé.

    Pour plus d’informations, consultez la page Procédure d’exécution d’un démarrage en mode minimal dans Windows.

    Vous pouvez désactiver un pilote en suivant les étapes de la procédure Comment désactiver temporairement le pilote de filtre en mode noyau dans Windows.

    Vous pouvez également envisager la possibilité de restaurer des modifications ou de rétablir le dernier état de travail connu. Pour plus d’informations, consultez Restaurer une version précédente d’un pilote de périphérique.

Collecte d’images mémoire

Pour configurer le système pour les fichiers de vidage mémoire, effectuez les étapes suivantes :

  1. Sélectionnez la zone de recherche de la barre des tâches, tapez Paramètres système avancés, puis appuyez sur Entrée.
  2. Dans l’onglet Avancé de la zone Propriétés système, sélectionnez le bouton Paramètres qui apparaît dans la section Démarrage et récupération.
  3. Dans la nouvelle fenêtre, sélectionnez la liste déroulante sous l’option Écriture des informations de débogage.
  4. Choisissez Vidage mémoire automatique.
  5. Cliquez sur OK.
  6. Redémarrez l’ordinateur pour que le paramètre prenne effet.
  7. Si le serveur est virtualisé, désactivez le redémarrage automatique après la création du fichier de vidage mémoire. Cette désactivation vous permet de prendre un instantané du serveur en état et également si le problème se répète.

Le fichier de vidage mémoire est enregistré aux emplacements suivants :

Type de fichier de vidage Emplacement
(aucun) %SystemRoot%\MEMORY.DMP (inactif ou grisé)
Petit fichier de vidage mémoire (256 Ko) %SystemRoot%\Minidump
Fichier de vidage mémoire du noyau %SystemRoot%\MEMORY.DMP
Fichier de vidage mémoire complet %SystemRoot%\MEMORY.DMP
Fichier de vidage mémoire automatique %SystemRoot%\MEMORY.DMP
Fichier de vidage mémoire actif %SystemRoot%\MEMORY.DMP

Vous pouvez utiliser l’outil Microsoft Crash Dump File Checker (DumpChk) pour vérifier que les fichiers de vidage mémoire ne sont pas endommagés ou non valides. Pour plus d’informations, regardez la vidéo suivante :

Pour plus d’informations sur l’utilisation de Dumpchk.exe pour vérifier vos fichiers de vidage, consultez les articles suivants :

Paramètres du fichier d’échange

Pour plus d’informations sur les paramètres du fichier d’échange, consultez les articles suivants :

Analyse du vidage mémoire

La recherche de la cause racine de l’incident peut ne pas être facile. Les problèmes matériels sont particulièrement difficiles à diagnostiquer, car ils peuvent provoquer un comportement erratique et imprévisible qui peut se manifester par différents symptômes.

Lorsqu’une erreur d’arrêt se produit, vous devez d’abord isoler les composants posant problème, puis essayer de les provoquer pour déclencher à nouveau l’erreur d’arrêt. Si vous pouvez répliquer le problème, vous pouvez généralement en déterminer la cause.

Vous pouvez utiliser les outils tels que le Kit de développement logiciel (SDK) Windows et les symboles pour diagnostiquer les journaux de vidage. La section suivante explique comment utiliser cet outil.

Procédure de résolution de problèmes avancée

Note

La résolution avancée des vidages sur incident peut être très difficile si vous n’êtes pas un expert de la programmation et des mécanismes Windows internes. Nous avons tenté de fournir ici un bref aperçu de certaines techniques utilisées, y compris quelques exemples. Toutefois, pour être efficace lors de la résolution d’un vidage sur incident, vous devez consacrer du temps à vous familiariser avec les techniques de débogage avancées. Pour obtenir une vue d’ensemble, regardez la vidéo Le débogage en mode noyau se bloque. Consultez également les références avancées répertoriées ci-dessous.

Références de débogage avancé

Étapes de débogage

  1. Vérifiez que l’ordinateur est configuré pour générer un fichier de vidage mémoire complet lorsqu’un incident se produit. Pour plus d’informations, consultez Méthode 1 : vidage mémoire.

  2. Recherchez le fichier memory.dmp dans votre répertoire Windows sur l’ordinateur qui se bloque et copiez ce fichier sur un autre ordinateur.

  3. Sur l’autre ordinateur, téléchargez le Kit de développement logiciel (SDK) Windows 10.

  4. Démarrez l’installation et choisissez Outils de débogage pour Windows. L’outil WinDbg est installé.

  5. Accédez au menu Fichier et sélectionnez Chemin du fichier de symboles pour ouvrir l’outil WinDbg et définir le chemin d’accès aux symboles.

    1. Si l’ordinateur est connecté à Internet, entrez le Serveur de symboles public Microsoft, https://msdl.microsoft.com/download/symbols, puis sélectionnez OK. Cette méthode est recommandée.
    2. Si l’ordinateur n’est pas connecté à Internet, spécifiez un chemin d’accès aux symboles local.
  6. Sélectionnez Ouvrir le vidage sur incident, puis ouvrez le fichier memory.dmp que vous avez copié.

    Capture d’écran d’un exemple de sortie dans WinDbg lors de l’ouverture d’un fichier de vidage sur incident.

  7. Sous Analyse de vérification des bogues, sélectionnez !analyze -v. La commande !analyze -v est entrée dans le prompt au bas de la page.

  8. Une analyse détaillée de la vérification des bogues s’affiche.

    Capture d’écran d’un exemple d’analyse détaillée de la vérification des bogues.

  9. Faites défiler vers le bas jusqu’à la section STACK_TEXT. Des lignes de nombres, chaque ligne étant suivie d’un signe deux-points et de texte, s’affichent. Ce texte doit vous indiquer quelle DLL provoque l’incident. Le cas échéant, il indique également quel service bloque la DLL.

  10. Pour plus d'informations sur l’interprétation de la sortie STACK_TEXT, consultez Utilisation de l’extension !analyze.

Il existe de nombreuses causes possibles à une vérification des bogues et chaque cas est unique. Dans l’exemple fourni ci-dessus, les lignes importantes qui peuvent être identifiées dans STACK_TEXT sont les lignes 20, 21 et 22 :

Note

Les données HEX sont supprimées ici et les lignes sont numérotées pour plus de clarté.

1  : nt!KeBugCheckEx
2  : nt!PspCatchCriticalBreak+0xff
3  : nt!PspTerminateAllThreads+0x1134cf
4  : nt!PspTerminateProcess+0xe0
5  : nt!NtTerminateProcess+0xa9
6  : nt!KiSystemServiceCopyEnd+0x13
7  : nt!KiServiceLinkage
8  : nt!KiDispatchException+0x1107fe
9  : nt!KiFastFailDispatch+0xe4
10 : nt!KiRaiseSecurityCheckFailure+0x3d3
11 : ntdll!RtlpHpFreeWithExceptionProtection$filt$0+0x44
12 : ntdll!_C_specific_handler+0x96
13 : ntdll!RtlpExecuteHandlerForException+0xd
14 : ntdll!RtlDispatchException+0x358
15 : ntdll!KiUserExceptionDispatch+0x2e
16 : ntdll!RtlpHpVsContextFree+0x11e
17 : ntdll!RtlpHpFreeHeap+0x48c
18 : ntdll!RtlpHpFreeWithExceptionProtection+0xda
19 : ntdll!RtlFreeHeap+0x24a
20 : FWPolicyIOMgr!FwBinariesFree+0xa7c2
21 : mpssvc!FwMoneisDiagEdpPolicyUpdate+0x1584f
22 : mpssvc!FwEdpMonUpdate+0x6c
23 : ntdll!RtlpWnfWalkUserSubscriptionList+0x29b
24 : ntdll!RtlpWnfProcessCurrentDescriptor+0x105
25 : ntdll!RtlpWnfNotificationThread+0x80
26 : ntdll!TppExecuteWaitCallback+0xe1
27 : ntdll!TppWorkerThread+0x8d0
28 : KERNEL32!BaseThreadInitThunk+0x14
29 : ntdll!RtlUserThreadStart+0x21

Ce problème est dû au service mpssvc, qui est un composant du Pare-feu Windows. Le problème a été réparé en désactivant temporairement le pare-feu, puis en réinitialisant les stratégies de pare-feu.

Pour plus d’exemples, consultez Exemples de débogage.

Ressources vidéos

Les vidéos suivantes illustrent différentes techniques de résolution des problèmes pour l’analyse des fichiers de vidage.

Résolution de problèmes avancée à l’aide du vérificateur de pilotes

Nous estimons qu’environ 75 % de toutes les erreurs d’arrêt sont causées par des pilotes défectueux. L’outil Vérificateur de pilotes fournit plusieurs méthodes pour vous aider à résoudre les problèmes. Il s’agit notamment d’exécuter des pilotes dans un pool de mémoire isolé (sans partager de mémoire avec d’autres composants), de générer une sollicitation extrême de la mémoire et de valider des paramètres. Si l’outil rencontre des erreurs dans l’exécution du code du pilote, il crée de manière proactive une exception. Il peut ensuite examiner plus en détail cette partie du code.

Avertissement

Vérificateur de pilotes consomme le processeur de manière intensive et peut ralentir considérablement l’ordinateur. Vous pouvez également rencontrer des incidents supplémentaires. Le vérificateur désactive les pilotes défectueux après une erreur d’arrêt et continue à le faire jusqu’à ce que vous puissiez redémarrer le système et accéder au bureau. Vous pouvez également vous attendre à voir plusieurs fichiers de vidage créés.

N’essayez pas de vérifier tous les pilotes à la fois. Cette action peut dégrader les performances et rendre le système inutilisable. Elle limite également l’efficacité de l’outil.

Utilisez les instructions suivantes lorsque vous utilisez Vérificateur de pilotes :

  • Testez les pilotes « suspects ». Par exemple, les pilotes récemment mis à jour ou connus pour poser problème.
  • Si vous continuez à rencontrer des incidents non analysables, essayez d’activer la vérification sur tous les pilotes tiers et non signés.
  • Activez la vérification simultanée sur des groupes de 10 à 20 pilotes.
  • En outre, si l’ordinateur ne peut pas démarrer dans le bureau à cause de Vérificateur de pilotes, vous pouvez désactiver l’outil en démarrant en mode sans échec. Cette solution est due au fait que l’outil ne peut pas s’exécuter en mode sans échec.

Pour plus d’informations, consultez Type de débogage.

Erreurs d’arrêt Windows courantes

Cette section ne contient pas la liste de tous les codes d’erreur. Toutefois, de nombreux codes d’erreur ayant les mêmes résolutions potentielles, la meilleure option consiste à suivre les étapes ci-dessous pour résoudre votre erreur. Pour obtenir la liste complète des codes d’erreur d’arrêt, consultez Référence du code de vérification des bogues.

Les sections suivantes répertorient les procédures de résolution des problèmes générales des codes d’erreur d’arrêt courants.

VIDEO_ENGINE_TIMEOUT_DETECTED ou VIDEO_TDR_TIMEOUT_DETECTED

Code d’erreur d’arrêt : 0x00000141 ou 0x00000117

Contactez le fournisseur du pilote d’affichage répertorié pour obtenir une mise à jour appropriée pour ce pilote.

DRIVER_IRQL_NOT_LESS_OR_EQUAL

Code d’erreur d’arrêt : 0x0000000D1

Appliquez les dernières mises à jour du pilote en appliquant les dernières mises à jour cumulatives pour le système via le site Web du catalogue Microsoft Update. Mettez à jour un pilote réseau obsolète. Les systèmes VMware virtualisés exécutent souvent « Intel(R) PRO/1000 MT Network Connection » (e1g6032e.sys). Vous pouvez télécharger ce pilote à partir du site Web Téléchargement de pilotes et de logiciels d’Intel. Contactez le fournisseur du matériel pour mettre à jour le pilote réseau en vue d’une résolution. Pour les systèmes VMware, utilisez le pilote réseau intégré VMware au lieu du pilote e1g6032e.sys d’Intel. Par exemple, utilisez les types VMware VMXNET, VMXNET2 ou VMXNET3.

PAGE_FAULT_IN_NONPAGED_AREA

Code d’erreur d’arrêt : 0x000000050

Si un pilote est identifié dans le message d’erreur d’arrêt, contactez le fabricant en vue d’une mise à jour. Si aucune mise à jour n’est disponible, désactivez le pilote et surveillez la stabilité du système. Exécutez chkdsk /f /r pour détecter et réparer les erreurs de disque. Redémarrez le système avant le début de l’analyse du disque sur une partition système. Contactez les fabricants des outils de diagnostic qu’ils peuvent fournir pour le sous-système de disque dur. Essayez de réinstaller une application ou un service récemment installé ou mis à jour. Il est possible que l’incident ait été déclenché pendant le démarrage des applications par le système et la lecture du Registre pour les paramètres de préférence. La réinstallation de l’application peut corriger les clés de Registre endommagées. Si le problème persiste et que vous avez exécuté une sauvegarde récente de l’état du système, essayez de restaurer les ruches du Registre à partir de la sauvegarde.

SYSTEM_SERVICE_EXCEPTION

Code d’erreur d’arrêt : c000021a {Erreur système irrécupérable} Le processus système Sous-système Windows s’est terminé de façon inattendue avec l’état 0xc0000005. Le système a été arrêté.

Utilisez l’outil Vérificateur de fichiers système pour réparer les fichiers système manquants ou corrompus. Le Vérificateur des fichiers système permet aux utilisateurs de rechercher des altérations dans les fichiers système de Windows et de restaurer les fichiers endommagés. Pour plus d’informations, consultez Utiliser l’outil Vérificateur des fichiers système.

NTFS_FILE_SYSTEM

Code d’erreur d’arrêt : 0x000000024

Cette erreur d’arrêt est généralement causée par une altération dans le système de fichiers NTFS ou des blocs (secteurs) incorrects sur le disque dur. Les pilotes endommagés pour les disques durs (SATA ou IDE) peuvent également affecter la capacité du système à lire et à écrire sur le disque. Exécutez les diagnostics matériels fournis par le fabricant du sous-système de stockage. Utilisez l’utilitaire de vérification des disques pour confirmer qu’il n’y a pas d’erreurs de système de fichiers. Pour effectuer cette étape, cliquez avec le bouton droit sur le lecteur que vous souhaitez analyser, sélectionnez Propriétés, Outils, puis le bouton Vérifier maintenant. Mettez à jour le pilote du système de fichiers NTFS (Ntfs.sys). Appliquez les dernières mises à jour cumulatives pour le système d’exploitation actuel qui rencontre le problème.

KMODE_EXCEPTION_NOT_HANDLED

Code d’erreur d’arrêt : 0x0000001E

Si un pilote est identifié dans le message d’erreur d’arrêt, désactivez ou supprimez ce pilote. Désactivez ou supprimez tous les pilotes ou services récemment ajoutés.

Si l’erreur se produit pendant la séquence de démarrage et que la partition système est formatée à l’aide du système de fichiers NTFS, vous pourrez peut-être utiliser le mode sans échec pour désactiver le pilote dans le Gestionnaire de périphériques. Pour désactiver le pilote, procédez comme suit :

  1. Accédez à Paramètres>Mise à jour et sécurité>Récupération.
  2. Sous Démarrage avancé, sélectionnez Redémarrer maintenant.
  3. Une fois que votre PC redémarre sur l’écran Choisir une option, sélectionnez Résoudre les problèmes>Options avancées>Paramètres de démarrage>Redémarrer.
  4. Après le redémarrage de l’ordinateur, une liste d’options s’affiche. Appuyez sur la touche 4 ou F4 pour démarrer l’ordinateur en mode sans échec. Si vous envisagez d’utiliser Internet en mode sans échec, appuyez sur la touche 5 ou F5 pour l’option Mode sans échec avec prise en charge réseau.

DPC_WATCHDOG_VIOLATION

Code d’erreur d’arrêt : 0x00000133

Ce code d’erreur d’arrêt est causé par un pilote défectueux qui, dans certaines conditions, ne termine pas son action dans le délai imparti. Pour atténuer cette erreur, collectez le fichier de vidage mémoire à partir du système, puis utilisez le Débogueur Windows pour rechercher le pilote défectueux. Si un pilote est identifié dans le message d’erreur d’arrêt, désactivez le pilote pour isoler le problème. Vérifiez auprès du fabricant les mises à jour du pilote. Dans le journal système de l’observateur d’événements, recherchez d’autres messages d’erreur susceptibles de vous aider à identifier l’appareil ou le pilote à l’origine de l’erreur d’arrêt 0x133. Vérifiez que les nouveaux matériels installés sont compatibles avec la version installée de Windows. Par exemple, vous pouvez obtenir des informations sur le matériel requis sur les Spécifications de Windows 10. Si le Débogueur Windows est installé et que vous avez accès aux symboles publics, vous pouvez charger le fichier c:\windows\memory.dmp dans le débogueur. Reportez-vous ensuite à Détermination de la source des erreurs de vérification des bogues 0x133 (DPC_WATCHDOG_VIOLATION) sur Windows Server 2012 pour rechercher le pilote qui pose problème dans le vidage mémoire.

USER_MODE_HEALTH_MONITOR

Code d’erreur d’arrêt : 0x0000009E

Cette erreur d’arrêt indique qu’un contrôle d’intégrité en mode utilisateur a échoué d’une manière qui empêche un arrêt approprié. Windows restaure les services critiques en redémarrant ou en activant le basculement d’application vers d’autres serveurs. Le service de clustering intègre un mécanisme de détection qui peut détecter l’absence de réponse dans les composants en mode utilisateur.

Cette erreur d’arrêt se produit généralement dans un environnement en cluster, et le pilote défectueux indiqué est RHS.exe. Vérifiez les journaux des événements pour détecter les échecs de stockage afin d’identifier le processus défaillant. Essayez de mettre à jour le composant ou le processus indiqué dans les journaux des événements. Vous devez voir l’événement enregistré suivant :

  • ID d’événement : 4870
  • Source : Microsoft-Windows-FailoverClustering
  • Description : le monitoring de l’intégrité en mode utilisateur a détecté que le système ne répond pas. L’adaptateur virtuel du cluster de basculement a perdu le contact avec le processus Cluster Server associé à l’ID de processus « %1 » pendant « %2 » secondes. Une action de récupération va être effectuée. Passez en revue les journaux du cluster pour identifier le processus et examiner les éléments susceptibles de provoquer le blocage du processus.

Pour plus d’informations, consultez Erreur d’arrêt « 0x0000009E » sur les nœuds de cluster dans un environnement de cluster de basculement à plusieurs nœuds Windows Server. Regardez également la vidéo Microsoft suivante : Que faire en cas d’erreur 9E.

Exemples de débogage

Exemple 1

Cette vérification des bogues est due au blocage d’un pilote pendant la mise à niveau, ce qui entraîne une vérification des bogues D1 dans NDIS.sys, qui est un pilote Microsoft. IMAGE_NAME indique le pilote défaillant. Toutefois, ce pilote étant un pilote Microsoft, il ne peut pas être remplacé ou supprimé. La méthode de résolution consiste à désactiver l’appareil réseau dans le Gestionnaire des périphériques et à réessayer la mise à niveau.

2: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 000000000011092a, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, value 0 = read operation, 1 = write operation
Arg4: fffff807aa74f4c4, address which referenced memory
Debugging Details:
------------------

KEY_VALUES_STRING: 1
STACKHASH_ANALYSIS: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 400
SIMULTANEOUS_TELSVC_INSTANCES:  0
SIMULTANEOUS_TELWP_INSTANCES:  0
BUILD_VERSION_STRING:  16299.15.amd64fre.rs3_release.170928-1534
SYSTEM_MANUFACTURER:  Alienware
SYSTEM_PRODUCT_NAME:  Alienware 15 R2
SYSTEM_SKU:  Alienware 15 R2
SYSTEM_VERSION:  1.2.8
BIOS_VENDOR:  Alienware
BIOS_VERSION:  1.2.8
BIOS_DATE:  01/29/2016
BASEBOARD_MANUFACTURER:  Alienware
BASEBOARD_PRODUCT:  Alienware 15 R2
BASEBOARD_VERSION:  A00
DUMP_TYPE:  2
BUGCHECK_P1: 11092a
BUGCHECK_P2: 2
BUGCHECK_P3: 1
BUGCHECK_P4: fffff807aa74f4c4
WRITE_ADDRESS: fffff80060602380: Unable to get MiVisibleState
Unable to get NonPagedPoolStart
Unable to get NonPagedPoolEnd
Unable to get PagedPoolStart
Unable to get PagedPoolEnd
000000000011092a 
CURRENT_IRQL:  2
FAULTING_IP: 
NDIS!NdisQueueIoWorkItem+4 [minio\ndis\sys\miniport.c @ 9708]
fffff807`aa74f4c4 48895120        mov     qword ptr [rcx+20h],rdx
CPU_COUNT: 8
CPU_MHZ: a20
CPU_VENDOR:  GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 5e
CPU_STEPPING: 3
CPU_MICROCODE: 6,5e,3,0 (F,M,S,R)  SIG: BA'00000000 (cache) BA'00000000 (init)
BLACKBOXPNP: 1 (!blackboxpnp)
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
BUGCHECK_STR:  AV
PROCESS_NAME:  System
ANALYSIS_SESSION_HOST:  SHENDRIX-DEV0
ANALYSIS_SESSION_TIME:  01-17-2019 11:06:05.0653
ANALYSIS_VERSION: 10.0.18248.1001 amd64fre
TRAP_FRAME:  ffffa884c0c3f6b0 -- (.trap 0xffffa884c0c3f6b0)
NOTE: The trap frame doesn't contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff807ad018bf0 rbx=0000000000000000 rcx=000000000011090a
rdx=fffff807ad018c10 rsi=0000000000000000 rdi=0000000000000000
rip=fffff807aa74f4c4 rsp=ffffa884c0c3f840 rbp=000000002408fd00
r8=ffffb30e0e99ea30  r9=0000000001d371c1 r10=0000000020000080
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na pe nc
NDIS!NdisQueueIoWorkItem+0x4:
fffff807`aa74f4c4 48895120        mov     qword ptr [rcx+20h],rdx ds:00000000`0011092a=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff800603799e9 to fffff8006036e0e0

STACK_TEXT:  
ffffa884`c0c3f568 fffff800`603799e9 : 00000000`0000000a 00000000`0011092a 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx [minkernel\ntos\ke\amd64\procstat.asm @ 134] 
ffffa884`c0c3f570 fffff800`60377d7d : fffff78a`4000a150 ffffb30e`03fba001 ffff8180`f0b5d180 00000000`000000ff : nt!KiBugCheckDispatch+0x69 [minkernel\ntos\ke\amd64\trap.asm @ 2998] 
ffffa884`c0c3f6b0 fffff807`aa74f4c4 : 00000000`00000002 ffff8180`f0754180 00000000`00269fb1 ffff8180`f0754180 : nt!KiPageFault+0x23d [minkernel\ntos\ke\amd64\trap.asm @ 1248] 
ffffa884`c0c3f840 fffff800`60256b63 : ffffb30e`0e18f710 ffff8180`f0754180 ffffa884`c0c3fa18 00000000`00000002 : NDIS!NdisQueueIoWorkItem+0x4 [minio\ndis\sys\miniport.c @ 9708] 
ffffa884`c0c3f870 fffff800`60257bfd : 00000000`00000008 00000000`00000000 00000000`00269fb1 ffff8180`f0754180 : nt!KiProcessExpiredTimerList+0x153 [minkernel\ntos\ke\dpcsup.c @ 2078] 
ffffa884`c0c3f960 fffff800`6037123a : 00000000`00000000 ffff8180`f0754180 00000000`00000000 ffff8180`f0760cc0 : nt!KiRetireDpcList+0x43d [minkernel\ntos\ke\dpcsup.c @ 1512] 
ffffa884`c0c3fb60 00000000`00000000 : ffffa884`c0c40000 ffffa884`c0c39000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a [minkernel\ntos\ke\amd64\idle.asm @ 166] 

RETRACER_ANALYSIS_TAG_STATUS:  Failed in getting KPCR for core 2
THREAD_SHA1_HASH_MOD_FUNC:  5b59a784f22d4b5cbd5a8452fe39914b8fd7961d
THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  5643383f9cae3ca39073f7721b53f0c633bfb948
THREAD_SHA1_HASH_MOD:  20edda059578820e64b723e466deea47f59bd675
FOLLOWUP_IP: 
NDIS!NdisQueueIoWorkItem+4 [minio\ndis\sys\miniport.c @ 9708]
fffff807`aa74f4c4 48895120        mov     qword ptr [rcx+20h],rdx
FAULT_INSTR_CODE:  20518948
FAULTING_SOURCE_LINE:  minio\ndis\sys\miniport.c
FAULTING_SOURCE_FILE:  minio\ndis\sys\miniport.c
FAULTING_SOURCE_LINE_NUMBER:  9708
FAULTING_SOURCE_CODE:  
  9704:     _In_ _Points_to_data_      PVOID                       WorkItemContext
  9705:     )
  9706: {
  9707: 
> 9708:     ((PNDIS_IO_WORK_ITEM)NdisIoWorkItemHandle)->Routine = Routine;
  9709:     ((PNDIS_IO_WORK_ITEM)NdisIoWorkItemHandle)->WorkItemContext = WorkItemContext;
  9710: 
  9711:     IoQueueWorkItem(((PNDIS_IO_WORK_ITEM)NdisIoWorkItemHandle)->IoWorkItem,
  9712:                     ndisDispatchIoWorkItem,
  9713:                     CriticalWorkQueue,

SYMBOL_STACK_INDEX:  3
SYMBOL_NAME:  NDIS!NdisQueueIoWorkItem+4
FOLLOWUP_NAME:  ndiscore
MODULE_NAME: NDIS
IMAGE_NAME:  NDIS.SYS
DEBUG_FLR_IMAGE_TIMESTAMP:  0
IMAGE_VERSION:  10.0.16299.99
DXGANALYZE_ANALYSIS_TAG_PORT_GLOBAL_INFO_STR:  Hybrid_FALSE
DXGANALYZE_ANALYSIS_TAG_ADAPTER_INFO_STR:  GPU0_VenId0x1414_DevId0x8d_WDDM1.3_Active;
STACK_COMMAND:  .thread ; .cxr ; kb
BUCKET_ID_FUNC_OFFSET:  4
FAILURE_BUCKET_ID:  AV_NDIS!NdisQueueIoWorkItem
BUCKET_ID:  AV_NDIS!NdisQueueIoWorkItem
PRIMARY_PROBLEM_CLASS:  AV_NDIS!NdisQueueIoWorkItem
TARGET_TIME:  2017-12-10T14:16:08.000Z
OSBUILD:  16299
OSSERVICEPACK:  98
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK:  784
PRODUCT_TYPE:  1
OSPLATFORM_TYPE:  x64
OSNAME:  Windows 10
OSEDITION:  Windows 10 WinNt TerminalServer SingleUserTS Personal
OS_LOCALE:  
USER_LCID:  0
OSBUILD_TIMESTAMP:  2017-11-26 03:49:20
BUILDDATESTAMP_STR:  170928-1534
BUILDLAB_STR:  rs3_release
BUILDOSVER_STR:  10.0.16299.15.amd64fre.rs3_release.170928-1534
ANALYSIS_SESSION_ELAPSED_TIME:  8377
ANALYSIS_SOURCE:  KM
FAILURE_ID_HASH_STRING:  km:av_ndis!ndisqueueioworkitem
FAILURE_ID_HASH:  {10686423-afa1-4852-ad1b-9324ac44ac96}
FAILURE_ID_REPORT_LINK: https://go.microsoft.com/fwlink/?LinkID=397724&FailureHash=10686423-afa1-4852-ad1b-9324ac44ac96
Followup:     ndiscore
---------

Exemple 2

Dans cet exemple, un pilote non-Microsoft a provoqué une erreur de page. Nous n’avons donc pas de symboles pour ce pilote. Toutefois, en examinant IMAGE_NAME et/ou MODULE_NAME, on constate que WwanUsbMP.sys est à l’origine du problème. Une déconnexion de l’appareil et une nouvelle tentative de mise à niveau est une solution possible.

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This can't be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: 8ba10000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 82154573, If non-zero, the instruction address which referenced the bad memory
                address.
Arg4: 00000000, (reserved)

Debugging Details:
------------------

*** WARNING: Unable to verify timestamp for WwanUsbMp.sys
*** ERROR: Module load completed but symbols could not be loaded for WwanUsbMp.sys

KEY_VALUES_STRING: 1
STACKHASH_ANALYSIS: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 400
BUILD_VERSION_STRING:  16299.15.x86fre.rs3_release.170928-1534
MARKER_MODULE_NAME:  IBM_ibmpmdrv
SYSTEM_MANUFACTURER:  LENOVO
SYSTEM_PRODUCT_NAME:  20AWS07H00
SYSTEM_SKU:  LENOVO_MT_20AW_BU_Think_FM_ThinkPad T440p
SYSTEM_VERSION:  ThinkPad T440p
BIOS_VENDOR:  LENOVO
BIOS_VERSION:  GLET85WW (2.39 )
BIOS_DATE:  09/29/2016
BASEBOARD_MANUFACTURER:  LENOVO
BASEBOARD_PRODUCT:  20AWS07H00
BASEBOARD_VERSION:  Not Defined
DUMP_TYPE:  2
BUGCHECK_P1: ffffffff8ba10000
BUGCHECK_P2: 0
BUGCHECK_P3: ffffffff82154573
BUGCHECK_P4: 0
READ_ADDRESS: 822821d0: Unable to get MiVisibleState
8ba10000 
FAULTING_IP: 
nt!memcpy+33 [minkernel\crts\crtw32\string\i386\memcpy.asm @ 213
82154573 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
MM_INTERNAL_CODE:  0
CPU_COUNT: 4
CPU_MHZ: 95a
CPU_VENDOR:  GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 3c
CPU_STEPPING: 3
CPU_MICROCODE: 6,3c,3,0 (F,M,S,R)  SIG: 21'00000000 (cache) 21'00000000 (init)
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXPNP: 1 (!blackboxpnp)
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
BUGCHECK_STR:  AV
PROCESS_NAME:  System
CURRENT_IRQL:  2
ANALYSIS_SESSION_HOST:  SHENDRIX-DEV0
ANALYSIS_SESSION_TIME:  01-17-2019 10:54:53.0780
ANALYSIS_VERSION: 10.0.18248.1001 amd64fre
TRAP_FRAME:  8ba0efa8 -- (.trap 0xffffffff8ba0efa8)
ErrCode = 00000000
eax=8ba1759e ebx=a2bfd314 ecx=00001d67 edx=00000002 esi=8ba10000 edi=a2bfe280
eip=82154573 esp=8ba0f01c ebp=8ba0f024 iopl=0         nv up ei pl nz ac pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010216
nt!memcpy+0x33:
82154573 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
Resetting default scope
LOCK_ADDRESS:  8226c6e0 -- (!locks 8226c6e0)
Cannot get _ERESOURCE type
Resource @ nt!PiEngineLock (0x8226c6e0)    Available
1 total locks
PNP_TRIAGE_DATA: 
                Lock address  : 0x8226c6e0
                Thread Count  : 0
                Thread address: 0x00000000
                Thread wait   : 0x0

LAST_CONTROL_TRANSFER:  from 82076708 to 821507e8

STACK_TEXT:  
8ba0ede4 82076708 00000050 8ba10000 00000000 nt!KeBugCheckEx [minkernel\ntos\ke\i386\procstat.asm @ 114] 
8ba0ee40 8207771e 8ba0efa8 8ba10000 8ba0eea0 nt!MiSystemFault+0x13c8 [minkernel\ntos\mm\mmfault.c @ 4755] 
8ba0ef08 821652ac 00000000 8ba10000 00000000 nt!MmAccessFault+0x83e [minkernel\ntos\mm\mmfault.c @ 6868] 
8ba0ef08 82154573 00000000 8ba10000 00000000 nt!_KiTrap0E+0xec [minkernel\ntos\ke\i386\trap.asm @ 5153] 
8ba0f024 86692866 a2bfd314 8ba0f094 0000850a nt!memcpy+0x33 [minkernel\crts\crtw32\string\i386\memcpy.asm @ 213] 
8ba0f040 866961bc 8ba0f19c a2bfd0e8 00000000 NDIS!ndisMSetPowerManagementCapabilities+0x8a [minio\ndis\sys\miniport.c @ 7969] 
8ba0f060 866e1f66 866e1caf adfb9000 00000000 NDIS!ndisMSetGeneralAttributes+0x23d [minio\ndis\sys\miniport.c @ 8198] 
8ba0f078 ac50c15f a2bfd0e8 0000009f 00000001 NDIS!NdisMSetMiniportAttributes+0x2b7 [minio\ndis\sys\miniport.c @ 7184] 
WARNING: Stack unwind information not available. Following frames may be wrong.
8ba0f270 ac526f96 adfb9000 a2bfd0e8 8269b9b0 WwanUsbMp+0x1c15f
8ba0f3cc 866e368a a2bfd0e8 00000000 8ba0f4c0 WwanUsbMp+0x36f96
8ba0f410 867004b0 a2bfd0e8 a2bfd0e8 a2be2a70 NDIS!ndisMInvokeInitialize+0x60 [minio\ndis\sys\miniport.c @ 13834] 
8ba0f7ac 866dbc8e a2acf730 866b807c 00000000 NDIS!ndisMInitializeAdapter+0xa23 [minio\ndis\sys\miniport.c @ 601] 
8ba0f7d8 866e687d a2bfd0e8 00000000 00000000 NDIS!ndisInitializeAdapter+0x4c [minio\ndis\sys\initpnp.c @ 931] 
8ba0f800 866e90bb adfb64d8 00000000 a2bfd0e8 NDIS!ndisPnPStartDevice+0x118 [minio\ndis\sys\configm.c @ 4235] 
8ba0f820 866e8a58 adfb64d8 a2bfd0e8 00000000 NDIS!ndisStartDeviceSynchronous+0xbd [minio\ndis\sys\ndispnp.c @ 3096] 
8ba0f838 866e81df adfb64d8 8ba0f85e 8ba0f85f NDIS!ndisPnPIrpStartDevice+0xb4 [minio\ndis\sys\ndispnp.c @ 1067] 
8ba0f860 820a7e98 a2bfd030 adfb64d8 8ba0f910 NDIS!ndisPnPDispatch+0x108 [minio\ndis\sys\ndispnp.c @ 2429] 
8ba0f878 8231f07e 8ba0f8ec adf5d4c8 872e2eb8 nt!IofCallDriver+0x48 [minkernel\ntos\io\iomgr\iosubs.c @ 3149] 
8ba0f898 820b8569 820c92b8 872e2eb8 8ba0f910 nt!PnpAsynchronousCall+0x9e [minkernel\ntos\io\pnpmgr\irp.c @ 3005] 
8ba0f8cc 820c9a76 00000000 820c92b8 872e2eb8 nt!PnpSendIrp+0x67 [minkernel\ntos\io\pnpmgr\irp.h @ 286] 
8ba0f914 8234577b 872e2eb8 adf638b0 adf638b0 nt!PnpStartDevice+0x60 [minkernel\ntos\io\pnpmgr\irp.c @ 3187] 
8ba0f94c 82346cc7 872e2eb8 adf638b0 adf638b0 nt!PnpStartDeviceNode+0xc3 [minkernel\ntos\io\pnpmgr\start.c @ 1712] 
8ba0f96c 82343c68 00000000 a2bdb3d8 adf638b0 nt!PipProcessStartPhase1+0x4d [minkernel\ntos\io\pnpmgr\start.c @ 114] 
8ba0fb5c 824db885 8ba0fb80 00000000 00000000 nt!PipProcessDevNodeTree+0x386 [minkernel\ntos\io\pnpmgr\enum.c @ 6129] 
8ba0fb88 8219571b 85852520 8c601040 8226ba90 nt!PiRestartDevice+0x91 [minkernel\ntos\io\pnpmgr\enum.c @ 4743] 
8ba0fbe8 820804af 00000000 00000000 8c601040 nt!PnpDeviceActionWorker+0xdb4b7 [minkernel\ntos\io\pnpmgr\action.c @ 674] 
8ba0fc38 8211485c 85852520 421de295 00000000 nt!ExpWorkerThread+0xcf [minkernel\ntos\ex\worker.c @ 4270] 
8ba0fc70 82166785 820803e0 85852520 00000000 nt!PspSystemThreadStartup+0x4a [minkernel\ntos\ps\psexec.c @ 7756] 
8ba0fc88 82051e07 85943940 8ba0fcd8 82051bb9 nt!KiThreadStartup+0x15 [minkernel\ntos\ke\i386\threadbg.asm @ 82] 
8ba0fc94 82051bb9 8b9cc600 8ba10000 8ba0d000 nt!KiProcessDeferredReadyList+0x17 [minkernel\ntos\ke\thredsup.c @ 5309] 
8ba0fcd8 00000000 00000000 00000000 00000000 nt!KeSetPriorityThread+0x249 [minkernel\ntos\ke\thredobj.c @ 3881] 


RETRACER_ANALYSIS_TAG_STATUS:  Failed in getting KPCR for core 1
THREAD_SHA1_HASH_MOD_FUNC:  e029276c66aea80ba36903e89947127118d31128
THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  012389f065d31c8eedd6204846a560146a38099b
THREAD_SHA1_HASH_MOD:  44dc639eb162a28d47eaeeae4afe6f9eeccced3d
FOLLOWUP_IP: 
WwanUsbMp+1c15f
ac50c15f 8bf0            mov     esi,eax
FAULT_INSTR_CODE:  f33bf08b
SYMBOL_STACK_INDEX:  8
SYMBOL_NAME:  WwanUsbMp+1c15f
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: WwanUsbMp
IMAGE_NAME:  WwanUsbMp.sys
DEBUG_FLR_IMAGE_TIMESTAMP:  5211bb0c
DXGANALYZE_ANALYSIS_TAG_PORT_GLOBAL_INFO_STR:  Hybrid_FALSE
DXGANALYZE_ANALYSIS_TAG_ADAPTER_INFO_STR:  GPU0_VenId0x1414_DevId0x8d_WDDM1.3_NotActive;GPU1_VenId0x8086_DevId0x416_WDDM1.3_Active_Post;
STACK_COMMAND:  .thread ; .cxr ; kb
BUCKET_ID_FUNC_OFFSET:  1c15f
FAILURE_BUCKET_ID:  AV_R_INVALID_WwanUsbMp!unknown_function
BUCKET_ID:  AV_R_INVALID_WwanUsbMp!unknown_function
PRIMARY_PROBLEM_CLASS:  AV_R_INVALID_WwanUsbMp!unknown_function
TARGET_TIME:  2018-02-12T11:33:51.000Z
OSBUILD:  16299
OSSERVICEPACK:  15
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK:  272
PRODUCT_TYPE:  1
OSPLATFORM_TYPE:  x86
OSNAME:  Windows 10
OSEDITION:  Windows 10 WinNt TerminalServer SingleUserTS
OS_LOCALE:  
USER_LCID:  0
OSBUILD_TIMESTAMP:  2017-09-28 18:32:28
BUILDDATESTAMP_STR:  170928-1534
BUILDLAB_STR:  rs3_release
BUILDOSVER_STR:  10.0.16299.15.x86fre.rs3_release.170928-1534
ANALYSIS_SESSION_ELAPSED_TIME:  162bd
ANALYSIS_SOURCE:  KM
FAILURE_ID_HASH_STRING:  km:av_r_invalid_wwanusbmp!unknown_function
FAILURE_ID_HASH:  {31e4d053-0758-e43a-06a7-55f69b072cb3}
FAILURE_ID_REPORT_LINK: https://go.microsoft.com/fwlink/?LinkID=397724&FailureHash=31e4d053-0758-e43a-06a7-55f69b072cb3

Followup:     MachineOwner
---------

ReadVirtual: 812d1248 not properly sign extended

References

Référence du Code de vérification de bogue