Bug Check 0x1E : KMODE_EXCEPTION_NOT_HANDLED

L’indicateur d’erreur KMODE_EXCEPTION_NOT_HANDLED a une valeur de 0x0000001E. L’indicateur d’erreur indique qu’un programme en mode noyau a généré une exception que le gestionnaire d’erreurs n’a pas interceptée.

Paramètres de KMODE_EXCEPTION_NOT_HANDLED

Cause

Pour interpréter cet indicateur d’erreur, vous devez identifier quelle exception a été générée.

Les codes d’exception courants incluent :

• 0x80000002 : STATUS_DATATYPE_MISALIGNMENT

  Une référence de données non alignée a été rencontrée.

• 0x80000003 : STATUS_BREAKPOINT

  Un point d’arrêt ou un ASSERT a été rencontré alors qu’aucun débogueur noyau n’était attaché au système.

• 0xC0000005 : STATUS_ACCESS_VIOLATION

  Une violation d’accès à la mémoire s’est produite. (Le paramètre 4 de l’indicateur d’erreur est l’adresse que le pilote a tenté d’accéder).

Pour une liste complète des codes d’exception, veuillez consulter la section Valeurs NTSTATUS. Les codes d’exception sont définis dans ntstatus.h, un fichier d’en-tête qui se trouve dans le Kit de pilotes Windows. Pour plus d’informations, veuillez consulter la section Fichiers d’en-tête dans le Kit de pilotes Windows.

Notes

Si vous n’êtes pas équipé pour déboguer ce problème, vous pouvez utiliser quelques techniques de dépannage de base qui sont décrites dans la section Analyser les données d’écran bleu d’indicateur d’erreur. Si un pilote est identifié dans le message de bug check, désactivez le pilote ou vérifiez auprès du fabricant les mises à jour du pilote.

Incompatibilité matérielle

Assurez-vous que tout nouveau matériel installé est compatible avec la version de Windows installée. Par exemple, vous pouvez obtenir des informations sur le matériel requis sur les Spécifications de Windows 10.

Pilote de périphérique défectueux ou service système

Un pilote de périphérique défectueux ou un service système pourrait causer cette erreur. Des problèmes matériels, tels que des incompatibilités de BIOS, des conflits de mémoire et des conflits IRQ, peuvent également générer cette erreur.

Si un pilote est mentionné par son nom dans le message d’indicateur d’erreur, désactivez ou supprimez ce pilote. Désactivez ou supprimez tous les pilotes ou services récemment ajoutés. Si l’erreur survient lors de la séquence de démarrage et que la partition du système est formatée en tant que système de fichiers NTFS, vous pourriez être en mesure d’utiliser le mode sans échec pour désactiver le pilote dans le Gestionnaire de périphériques.

Vérifiez le journal du système dans l’observateur d’événements pour d’autres messages d’erreur qui pourraient vous aider à identifier le périphérique ou le pilote qui cause l’indicateur d’erreur 0x1E. Exécutez également des diagnostics matériels fournis par le fabricant du système, en particulier le scanner de mémoire. Pour plus d’informations sur ces étapes de dépannage, consultez le manuel d’utilisation de votre ordinateur.

L’erreur qui génère ce message peut se produire après le premier redémarrage lors de l’installation de Windows ou après la fin de l’installation. Une cause possible de l’erreur est une incompatibilité du BIOS du système. Vous pouvez résoudre les problèmes de BIOS en mettant à jour la version du BIOS du système.

Résolution

Vous pourriez avoir du mal à obtenir une trace d’appels lorsque vous déboguez ce problème. L’adresse d’exception (paramètre 2) devrait identifier le pilote ou la fonction qui a causé le problème.

Le code d’exception 0x80000003 indique qu’un point d’arrêt ou une assertion codée en dur a été atteint, mais que le système a été démarré avec l’option /NODEBUG. Ce problème devrait se produire rarement. S’il se produit de manière répétée, assurez-vous qu’un débogueur noyau est connecté et que le système est démarré avec l’option /DEBUG.

Si le code d’exception 0x80000002 se produit, le cadre de piégeage fournit plus d’informations.

Cause inconnue

Si la cause spécifique de l’exception est inconnue, envisagez d’utiliser la procédure suivante pour obtenir une trace d’appels.

Obtenez une trace d’appels

Pour obtenir une trace d’appels si les procédures normales de traçage de la pile échouent :

1. Utilisez la commande kb (afficher la trace d’appels de la pile) pour afficher les paramètres dans la trace d’appels. Recherchez l’appel à NT!PspUnhandledExceptionInSystemThread. (Si cette fonction n’est pas répertoriée, consultez la note précédente).

2. Le premier paramètre de NT!PspUnhandledExceptionInSystemThread est un pointeur vers une structure. Le pointeur contient des pointeurs vers une instruction except :

   typedef struct _EXCEPTION_POINTERS {
       PEXCEPTION_RECORD ExceptionRecord;
       PCONTEXT ContextRecord;
       } EXCEPTION_POINTERS, *PEXCEPTION_POINTERS;
   
   ULONG PspUnhandledExceptionInSystemThread(
       IN PEXCEPTION_POINTERS ExceptionPointers
       )
   

   Utilisez la commande dd (afficher la mémoire) sur cette adresse pour afficher les données dont vous avez besoin.

3. La première valeur récupérée est un enregistrement d’exception. Pour l’enregistrement d’exception, utilisez la commande .exr (afficher l’enregistrement d’exception).

   La deuxième valeur est un enregistrement de contexte. Pour l’enregistrement de contexte, utilisez la commande .cxr (afficher l’enregistrement de contexte).

4. Après l’exécution de la commande .cxr, utilisez la commande kb pour afficher une trace d’appels basée sur les informations de l’enregistrement de contexte. Cette trace d’appels indique la pile d’appels où l’exception non gérée s’est produite.

Exemple d’indicateur d’erreur

L’exemple suivant montre un indicateur d’erreur 0x1E sur un processeur x86 :

kd> .bugcheck                 get the bug check data
Bugcheck code 0000001e
Arguments c0000005 8013cd0a 00000000 0362cffff

kd> kb                        start with a stack trace 
FramePtr  RetAddr   Param1   Param2   Param3   Function Name 
8013ed5c  801263ba  00000000 00000000 fe40cb00 NT!_DbgBreakPoint 
8013eecc  8013313c  0000001e c0000005 8013cd0a NT!_KeBugCheckEx+0x194
fe40cad0  8013318e  fe40caf8 801359ff fe40cb00 NT!PspUnhandledExceptionInSystemThread+0x18
fe40cad8  801359ff  fe40cb00 00000000 fe40cb00 NT!PspSystemThreadStartup+0x4a
fe40cf7c  8013cb8e  fe43a44c ff6ce388 00000000 NT!_except_handler3+0x47
00000000  00000000  00000000 00000000 00000000 NT!KiThreadStartup+0xe

kd> dd fe40caf8 L2            dump EXCEPTION_POINTERS structure
0xFE40CAF8  fe40cd88 fe40cbc4                   ..@...@.

kd> .exr fe40cd88             first DWORD is the exception record
Exception Record @ FE40CD88:
   ExceptionCode: c0000005
  ExceptionFlags: 00000000
  Chained Record: 00000000
ExceptionAddress: 8013cd0a
NumberParameters: 00000002
   Parameter[0]: 00000000
   Parameter[1]: 0362cfff

kd> .cxr fe40cbc4             second DWORD is the context record
CtxFlags: 00010017
eax=00087000 ebx=00000000 ecx=03ff0000 edx=ff63d000 esi=0362cfff edi=036b3fff
eip=8013cd0a esp=fe40ce50 ebp=fe40cef8 iopl=0         nv dn ei pl nz ac po cy
vip=0    vif=0
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010617
0x8013cd0a  f3a4             rep movsb

kd> kb                        kb gives stack for context record
ChildEBP RetAddr  Args to Child
fe40ce54 80402e09 ff6c4000 ff63d000 03ff0000 NT!_RtlMoveMemory@12+0x3e
fe40ce68 80403c18 ffbc0c28 ff6ce008 ff6c4000 HAL!_HalpCopyBufferMap@20+0x49
fe40ce9c fe43b1e4 ff6cef90 ffbc0c28 ff6ce009 HAL!_IoFlushAdapterBuffers@24+0x148
fe40ceb8 fe4385b4 ff6ce388 6cd00800 ffbc0c28 QIC117!_kdi_FlushDMABuffers@20+0x28
fe40cef8 fe439894 ff6cd008 ffb6c820 fe40cf4c QIC117!_cqd_CmdReadWrite@8+0x26e
fe40cf18 fe437d92 ff6cd008 ffb6c820 ff6e4e50 QIC117!_cqd_DispatchFRB@8+0x210
fe40cf30 fe43a4f5 ff6cd008 ffb6c820 00000000 QIC117!_cqd_ProcessFRB@8+0x134
fe40cf4c 80133184 ff6ce388 00000000 00000000 QIC117!_kdi_ThreadRun@4+0xa9
fe40cf7c 8013cb8e fe43a44c ff6ce388 00000000 NT!_PspSystemThreadStartup@8+0x40