Vérificateur d’application - Codes d’arrêt - Concepts de base

Les codes d’arrêt suivants sont contenus dans l’ensemble de bases des tests.

Détails de l’arrêt des exceptions

Essayez d’exécuter du code en mémoire non exécutable (première chance).

Cet arrêt est généré si l’application tente d’exécuter du code à partir d’une adresse qui n’est pas exécutable ou gratuite. Pour déboguer cet arrêt :

• u <parameter2> - désassembler le code coupable
• .exr <parameter3> - afficher les informations d’exception
• .cxr <parameter4> - afficher les informations de contexte d’exception
• kb : affiche la trace de pile pour l’heure à laquelle l’exception a été levée.

• Paramètre 1 - Adresse accessible.
• Paramètre 2 - Code effectuant un accès non valide.
• Paramètre 3 -Enregistrement d’exception . Utilisez .exr pour l’afficher.
• Paramètre 4 - Enregistrement de contexte. Utilisez .cxr pour l’afficher.

• Couche de test : Exceptions
• ID d’arrêt : FIRST_CHANCE_ACCESS_VIOLATION_CODE
• Arrêter le code : 650
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Gère les détails de l’arrêt

Exception de handle non valide pour la trace de pile actuelle.

Cet arrêt est généré si la fonction située en haut de la pile a passé un handle non valide aux routines système. En règle générale, une commande « kb » simple révèle la valeur du handle passé (il doit s’agir de l’un des paramètres , généralement le premier). Si la valeur est null, cela est clairement incorrect. Si la valeur semble correcte, vous devez utiliser l’extension de débogueur « !htrace » pour obtenir un historique des opérations relatives à cette valeur de handle. Dans la plupart des cas, la valeur de handle est utilisée après avoir été fermée.

• paramètre 1 - Non utilisé.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Poignées
• ID d’arrêt : INVALID_HANDLE
• Arrêter le code : 300
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Index TLS non valide utilisé pour la trace de pile actuelle.

Cet arrêt est généré si la fonction située en haut de la pile a passé un index TLS non valide aux routines système TLS. En règle générale, une commande « kb » simple révélera ce qui ne va pas. Le bogue typique ici consiste à supposer une certaine valeur pour un index TLS au lieu d’appeler « TlsAlloc ». Cela peut se produire en supposant que vous obtenez toujours la valeur N et, par conséquent, aucun besoin d’appeler « TlsAlloc ». Plus fréquemment, il s’agit d’une variable non initialisée.

• Paramètre 1 -Index  TLS non valide.
• Paramètre 2 -Partie  inférieure attendue de l’index.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Poignées
• ID d’arrêt : INVALID_TLS_VALUE
• Arrêter le code : 301
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Paramètres non valides pour l’appel WaitForMultipleObjects.

Cet arrêt est généré si la fonction située en haut de la pile appelée « WaitForMultipleObjects » a la valeur NULL comme adresse du tableau de handles à attendre ou avec zéro comme nombre de handles. Une commande « kb » simple révèle la fonction appelant cette API de manière incorrecte.

• Paramètre 1 - Address of object handles vector.
• Paramètre 2 - Nombre de handles.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Poignées
• ID d’arrêt : INCORRECT_WAIT_CALL
• Arrêter le code : 302
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Handle NULL passé en tant que paramètre. Un handle valide doit être utilisé.

Cet arrêt est généré si la fonction située en haut de la pile a passé un handle NULL aux routines système. En règle générale, une commande « kb » simple révèle la valeur du handle passé (il doit s’agir de l’un des paramètres, généralement le premier).

• Paramètre 1 - Utilisation du handle NULL
• Paramètre 2 - Non utilisé
• Paramètre 3 - Non utilisé
• Paramètre 4 - Non utilisé

• Couche de test : Poignées
• ID d’arrêt : NULL_HANDLE
• Arrêter le code : 303
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Attente d’un handle de thread dans DllMain.

Cet arrêt est généré si le thread actuel exécute actuellement du code à l’intérieur de la fonction « DllMain » de l’une des DLL chargées dans le processus actuel et qu’il appelle « WaitForSingleObject » ou « WaitForMultipleObjects » pour attendre sur un handle de thread dans le même processus. Cela entraîne probablement un blocage, car le handle de thread ne sera pas signalé, sauf si ce deuxième thread se termine. Lorsque le deuxième thread appelle « ExitThread », il tente d’acquérir le verrou du chargeur DLL, puis appelle « DllMain » (DLL_THREAD_DETACH) pour toutes les DLL du processus actuel. Étant donné que le verrou du chargeur appartient au premier thread (celui qui attend le handle de thread), les deux threads sont bloqués.

• Paramètre 1 - Handle de thread.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Poignées
• ID d’arrêt : WAIT_IN_DLLMAIN
• Arrêter le code : 304
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Type d’objet incorrect pour handle.

Cet arrêt est généré si le thread actuel appelle une API avec un handle vers un objet avec un type d’objet incorrect. Par exemple, l’appel de « SetEvent » avec un handle sémaphore en tant que paramètre génère cet arrêt. Pour déboguer cet arrêt :

• kb : pour afficher la trace de pile actuelle. Le coupable est probablement la DLL qui appelle dans verifier.dll
• du <parameter2> : pour afficher le type réel du handle. La valeur de handle est parameter1. Dans l’exemple précédent, cela affiche « Sémaphore ».
• du <parameter3> : pour afficher le type d’objet attendu par l’API. Dans l’exemple précédent, ce nom est « Event ».
• !htrace <parameter1> : peut être utile, car il affiche la trace de pile pour les opérations d’ouverture/fermeture récentes sur ce handle.

• Paramètre 1 - Handle value.
• Paramètre 2 - Nom du type d’objet. Utiliser du pour l’afficher
• Paramètre 3 - Nom du type d’objet attendu. Utiliser du pour l’afficher
• Paramètre 4 - Non utilisé.

• Couche de test : Poignées
• ID d’arrêt : INCORRECT_OBJECT_TYPE
• Arrêter le code : 305
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Détails de l’arrêt des tas

Erreur inconnue.

Ce message peut se produire si l’erreur rencontrée ne peut pas être classifiée d’une autre manière. Pas utilisé pour l’instant.

• Paramètre 1 - Non utilisé
• Paramètre 2 - Non utilisé
• Paramètre 3 - Non utilisé
• Paramètre 4 - Non utilisé

• Couche de test : Tas
• ID d’arrêt : UNKNOWN_ERROR
• Arrêter le code : 0x1
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Exception de violation d’accès.

Il s’agit de l’arrêt du vérificateur d’application le plus courant. En règle générale, il est dû à une erreur de dépassement de mémoire tampon. Le vérificateur de tas place une page non accessible à la fin d’une allocation de tas et un dépassement de mémoire tampon entraîne une exception en touchant cette page. Pour déboguer cet arrêt, identifiez l’adresse d’accès qui a provoqué l’exception, puis utilisez la commande de débogueur suivante :

• !tas -p -a ACCESS_ADDRESS - Cette commande fournit des détails sur la nature de l’erreur et le bloc de tas qui est dépassé. Il fournit également la trace de pile pour l’allocation de blocs. Il existe d’autres causes pour cet arrêt, par exemple l’accès à un bloc de tas après avoir été libéré. La même commande de débogueur est utile pour ce cas.

• Paramètre 1 - Adresse non valide à l’origine de l’exception
• Paramètre 2 - Adresse de code exécutant l’accès non valide
• Paramètre 3 -Enregistrement d’exception 
• Paramètre 4 - Enregistrement de contexte

• Couche de test : Tas
• ID d’arrêt : ACCESS_VIOLATION
• Arrêter le code : 0x2
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Accès multithread dans un tas créé avec HEAP_NO_SERIALIZE indicateur.

Un tas créé avec HEAP_NO_SERIALIZE indicateur n’est pas censé être accessible simultanément à partir de deux threads. Si une telle situation est détectée, vous recevez ce message. La façon typique de cette situation s’insinue dans un programme consiste à établir une liaison avec une version monothread du runtime C. Visual C++, par exemple, peut lier statiquement une telle bibliothèque lorsque des indicateurs appropriés sont utilisés. Les développeurs oublient ensuite ces détails et utilisent plusieurs threads. Le bogue est très difficile à déboguer dans la vie réelle, car il s’affiche comme des altérations mystérieuses des données.

• Paramètre 1 - Tas dans lequel l’opération se produit.
• Paramètre 2 - ID de thread pour le propriétaire actuel de la section critique du tas.
• Paramètre 3 - ID de thread du thread actuel essayant d’entrer le tas.
• Paramètre 4 - Non utilisé

• Couche de test : Tas
• ID d’arrêt : UNSYNCHRONIZED_ACCESS
• Arrêter le code : 0x3
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Demande de taille extrême.

Ce message est généré si, dans une opération « HeapAlloc » ou « HeapReAlloc », la taille du bloc est supérieure à toute valeur raisonnable. En règle générale, cette valeur est 0x80000000 sur les plateformes 32 bits et beaucoup plus grandes sur les plateformes 64 bits.

• Paramètre 1 - Tas dans lequel l’opération se produit.
• Paramètre 2 - Taille demandée
• Paramètre 3 - Non utilisé
• Paramètre 4 - Non utilisé

• Couche de test : Tas
• ID d’arrêt : EXTREME_SIZE_REQUEST
• Arrêter le code : 0x4
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Handle de tas avec signature incorrecte.

Les structures de tas sont étiquetées avec une valeur magique. Si le handle de tas utilisé dans l’appel à une interface de tas n’a pas ce modèle, cet arrêt sera généré. Ce bogue peut se produire si la structure de tas interne a été endommagée (corruption aléatoire) ou simplement une valeur factice est utilisée comme handle de tas. Pour obtenir la liste des valeurs de handle de tas valides, utilisez la commande de débogueur suivante :

• !heap -p

Notez que si vous changez simplement de handle de tas valide avec un autre handle valide dans une opération de tas, vous n’obtiendrez pas cet arrêt (le handle semble valide après tout). Toutefois, le vérificateur de tas détecte cette situation et le signale avec SWITCHED_HEAP_HANDLE’arrêt.

• Paramètre 1 - Handle de tas utilisé dans l’appel à une interface de tas
• Paramètre 2 - Non utilisé
• Paramètre 3 - Non utilisé
• Paramètre 4 - Non utilisé

• Couche de test : Tas
• ID d’arrêt : BAD_HEAP_HANDLE
• Arrêter le code : 0x5
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Pointeur de tas endommagé ou utilisation d’un tas incorrect.

Cela se produit généralement si un bloc est alloué dans un tas et libéré dans un autre. Utilisez la commande de débogueur « !heap -p » pour obtenir la liste de toutes les valeurs de handle de tas valides. L’exemple le plus courant est une allocation msvcrt à l’aide de « malloc » jumelée à un deallocation kernel32 à l’aide de « HeapFree ».

• Paramètre 1 - Handle de tas utilisé dans l’appel.
• Paramètre 2 - Bloc de tas impliqué dans l’opération.
• Paramètre 3 - Taille du bloc de tas.
• Paramètre 4 - Tas où le bloc a été initialement alloué.

• Couche de test : Tas
• ID d’arrêt : SWITCHED_HEAP_HANDLE
• Arrêter le code : 0x6
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Bloc de tas déjà libéré.

Cette situation se produit si le bloc est libéré deux fois. Les blocs libérés sont marqués d’une manière spéciale et sont conservés pendant un certain temps dans une file d’attente gratuite retardée. Si un programme buggy tente de libérer à nouveau le bloc, cela sera intercepté , en supposant que le bloc n’a pas été mis à la file d’attente libre retardée et sa mémoire réutilisée pour d’autres allocations. La profondeur de la file d’attente gratuite de retard est dans l’ordre de milliers de blocs, il y a donc de bonnes chances que la plupart des doubles libres seront interceptés.

• Paramètre 1 - Handle de tas pour le tas propriétaire du bloc.
• Paramètre 2 - Bloc de tas libéré à nouveau.
• Paramètre 3 - Taille du bloc de tas.
• Paramètre 4 - Non utilisé

• Couche de test : Tas
• ID d’arrêt : DOUBLE_FREE
• Arrêter le code : 0x7
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Bloc de tas endommagé.

Il s’agit d’une erreur générique émise si la corruption dans le bloc de tas ne peut pas être placée dans une catégorie plus spécifique.

• Paramètre 1 - Handle de tas utilisé dans l’appel.
• Paramètre 2 - Bloc de tas impliqué dans l’opération.
• Paramètre 3 - Taille du bloc de tas.
• Paramètre 4 - Réservé

• Couche de test : Tas
• ID d’arrêt : CORRUPTED_HEAP_BLOCK
• Arrêter le code : 0x8
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Essayez de détruire le tas de processus.

Il s’agit d’une erreur pour essayer de détruire le tas de processus par défaut (celui retourné par l’interface « GetProcessHeap() ».

• Paramètre 1 - Poignée de tas utilisée avec HeapDestroy.
• Paramètre 2 - Non utilisé
• Paramètre 3 - Non utilisé
• Paramètre 4 - Non utilisé

• Couche de test : Tas
• ID d’arrêt : DESTROY_PROCESS_HEAP
• Arrêter le code : 0x9
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Exception inattendue levée dans le code du tas.

Cet arrêt est généré si, lors de l’exécution du code du gestionnaire de tas, une violation d’accès est déclenchée dans des situations illégales. Il existe quelques situations où cela est correct, par exemple lors de l’appel de « HeapValidate() » ou « HeapSize() ». Les informations d’enregistrement d’exception (troisième paramètre) peuvent être utilisées pour rechercher le contexte exact de l’exception. Utilisez les commandes de débogueur suivantes pour ceci :

• dd parameter2 L2
• .exr first_dword
• .cxr second_dword

En règle générale, cet arrêt se produit s’il y a une altération aléatoire dans les structures de tas internes.

• Paramètre 1 - Tas impliqué dans l’opération.
• Paramètre 2 -Enregistrement d’exception .
• Paramètre 3 - Enregistrement de contexte.
• Paramètre 4 - Code d’exception (C0000005 - violation d’accès)

• Couche de test : Tas
• ID d’arrêt : UNEXPECTED_EXCEPTION
• Arrêter le code : 0xA
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Exception levée lors de la vérification de l’en-tête de bloc de tas.

Cette situation se produit si nous ne pouvons vraiment pas déterminer un type particulier de corruption pour le bloc. Par exemple, lorsque l’adresse de bloc de tas passée à une opération libre de tas pointe vers une zone de mémoire non accessible (pointeur endommagé, pointeur non initialisé, etc.).

• Paramètre 1 - Handle de tas pour le tas propriétaire du bloc.
• Paramètre 2 - Bloc de tas endommagé.
• Paramètre 3 - Taille du bloc ou zéro si la taille ne peut pas être déterminée.
• Paramètre 4 - Non utilisé.

• Couche de test : Tas
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_EXCEPTION_RAISED_FOR_HEADER
• Arrêter le code : 0xB
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Exception levée lors de la vérification du bloc de tas.

Cette situation se produit si nous ne pouvons vraiment pas déterminer un type particulier de corruption pour le bloc. Par exemple, vous obtiendrez cela si, pendant une opération gratuite de tas, vous passez une adresse qui pointe vers une zone de mémoire non accessible. Cela peut également se produire pour des situations doubles gratuites si nous ne trouvons pas le bloc parmi les blocs de tas de pages complètes et nous le sondeons en tant que bloc de tas de pages clair.

• Paramètre 1 - Handle de tas utilisé dans l’appel.
• Paramètre 2 - Bloc de tas impliqué dans l’opération.
• Paramètre 3 - Taille du bloc de tas.
• Paramètre 4 - Réservé.

• Couche de test : Tas
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_EXCEPTION_RAISED_FOR_PROBING
• Arrêter le code : 0xC
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Bloc de tas endommagé après avoir été libéré.

Cette situation se produit si un bloc de mémoire est écrit après avoir été libéré.

• Paramètre 1 - Handle de tas pour le tas propriétaire du bloc.
• Paramètre 2 - Bloc de tas endommagé.
• Paramètre 3 - Taille du bloc ou zéro si la taille ne peut pas être déterminée.
• Paramètre 4 - Non utilisé.

• Couche de test : Tas
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_HEADER
• Arrêter le code : 0xD
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Modèle de correction endommagé pour le bloc de tas libéré.

Les blocs libérés sont parfois marqués comme non accessibles et un programme qui les touche violera (un autre arrêt du vérificateur). Dans d’autres cas (par exemple un tas de pages clair), le bloc est marqué avec un motif magique et sera conservé pendant un certain temps. Finalement, à la mode FIFO, les blocs sont vraiment libérés. À ce stade, le modèle de correction est vérifié et s’il a été modifié, vous obtiendrez ce saut. La pile au moment de l’arrêt n’est pas pertinente. Vous devez déterminer la nature du bloc et du code qui peuvent être incorrects.

• Paramètre 1 - Handle de tas pour le tas propriétaire du bloc.
• Paramètre 2 - Bloc de tas libéré.
• Paramètre 3 - Taille du bloc de tas.
• Paramètre 4 - Réservé.

• Couche de test : Tas
• ID d’arrêt : CORRUPTED_FREED_HEAP_BLOCK
• Arrêter le code : 0xE
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Modèle de suffixe endommagé pour le bloc de tas.

La plupart du temps, cela se produit pour les erreurs de dépassement de mémoire tampon. Parfois, le vérificateur d’application place des pages non accessibles à la fin de l’allocation et des dépassements de mémoire tampon entraîne une violation d’accès et parfois le bloc de tas est suivi d’un modèle magique. Si ce modèle est modifié lorsque le bloc est libéré, vous obtiendrez ce saut. Ces pauses peuvent être très difficiles à déboguer, car vous n’avez pas le moment réel où la corruption s’est produite. Vous venez d’avoir accès au moment libre (c’est-à-dire « arrêter arrivé ici ») et à la trace de la pile d’allocation (' !heap -p -a HEAP_ADDRESS')

• Paramètre 1 - Handle de tas utilisé dans l’appel.
• Paramètre 2 - Bloc de tas impliqué dans l’opération.
• Paramètre 3 - Taille du bloc de tas.
• Paramètre 4 - Réservé.

• Couche de test : Tas
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_SUFFIX
• Arrêter le code : 0xF
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Tampon de démarrage endommagé pour le bloc de tas.

Cela se produit pour les sous-exécutions de mémoire tampon.

• Paramètre 1 - Handle de tas utilisé dans l’appel.
• Paramètre 2 - Bloc de tas impliqué dans l’opération.
• Paramètre 3 - Taille du bloc de tas.
• Paramètre 4 -Valeur  d’empreinte endommagée.

• Couche de test : Tas
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_START_STAMP
• Arrêter le code : 0x10
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Empreinte de fin endommagée pour le bloc de tas.

Cela se produit pour les sous-exécutions de mémoire tampon.

• Paramètre 1 - Handle de tas utilisé dans l’appel.
• Paramètre 2 - Bloc de tas impliqué dans l’opération.
• Paramètre 3 - Taille du bloc de tas.
• Paramètre 4 -Valeur  d’empreinte endommagée.

• Couche de test : Tas
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_END_STAMP
• Arrêter le code : 0x11
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Modèle de préfixe endommagé pour le bloc de tas.

Cela se produit pour les sous-exécutions de mémoire tampon.

• Paramètre 1 - Handle de tas utilisé dans l’appel.
• Paramètre 2 - Bloc de tas impliqué dans l’opération.
• Paramètre 3 - Taille du bloc de tas.
• Paramètre 4 - Réservé.

• Couche de test : Tas
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_PREFIX
• Arrêter le code : 0x12
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Première violation d’accès de chance pour la trace de pile actuelle.

Il s’agit de l’arrêt du vérificateur d’application le plus courant. En règle générale, il est dû à une erreur de dépassement de mémoire tampon. Le vérificateur de tas place une page non accessible à la fin d’une allocation de tas et un dépassement de mémoire tampon entraîne une exception en touchant cette page. Pour déboguer cet arrêt, identifiez l’adresse d’accès qui a provoqué l’exception, puis utilisez la commande de débogueur suivante :

• !tas -p -a ACCESS_ADDRESS

Cette commande donne des détails sur la nature de l’erreur et le bloc de tas qui est dépassé. Elle donnera également la trace de pile pour l’allocation de blocs. Il existe plusieurs autres causes pour cet arrêt, par exemple l’accès à un bloc de tas après avoir été libéré. La même commande de débogueur sera utile pour ce cas.

• Paramètre 1 - Adresse non valide à l’origine de l’exception.
• Paramètre 2 - Adresse de code exécutant l’accès non valide.
• Paramètre 3 -Enregistrement d’exception .
• Paramètre 4 - Enregistrement de contexte.

• Couche de test : Tas
• ID d’arrêt : FIRST_CHANCE_ACCESS_VIOLATION
• Arrêter le code : 0x13
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Nombre de listes de tas de processus non valides.

Ce message peut se produire si, lors de l’appel de GetProcessHeaps, le gestionnaire de tas de pages détecte certaines incohérences internes. Cela peut être dû à une altération aléatoire dans l’espace de processus.

• Paramètre 1 - Nombre réel de tas.
• Paramètre 2 - Nombre de tas de pages.
• Paramètre 3 - Non utilisé
• Paramètre 4 - Non utilisé

• Couche de test : Tas
• ID d’arrêt : CORRUPTED_HEAP_LIST
• Arrêter le code : 0x14
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Détails de l’arrêt des fuites

Une allocation de tas a été divulguée.

Cet arrêt est généré si la dll propriétaire de l’allocation a été déchargée dynamiquement lors de la propriété des ressources.

• Paramètre 1 - Adresse de l’allocation divulguée. Exécutez !heap -p -a <adresse> pour obtenir des informations supplémentaires sur l’allocation.
• Paramètre 2 - Adresse à la trace de la pile d’allocation. Exécutez l’adresse< dps >pour afficher la pile d’allocation.
• Paramètre 3 - Adresse du nom de la dll propriétaire. Exécutez l’adresse< du >fichier pour lire le nom de la dll.
• Paramètre 4 - Base de la dll propriétaire. Exécutez .reload <dll_name> = <adresse> pour recharger la dll propriétaire. Utilisez « lm » pour obtenir plus d’informations sur les modules chargés et déchargés.

• Couche de test : Fuite
• ID d’arrêt : ALLOCATION
• Arrêter le code : 0x900
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Un HANDLE a été fui.

Cet arrêt est généré si la dll propriétaire du handle a été déchargée dynamiquement lors de la gestion des ressources. Pour déboguer cet arrêt : Exécuter !htrace parameter1 pour obtenir des informations supplémentaires sur le handle.

• Paramètre 1 - Valeur du handle fuite. Exécutez !htrace <handle> pour obtenir des informations supplémentaires sur le handle si le suivi de handle est activé.
• Paramètre 2 - Adresse à la trace de la pile d’allocation. Exécutez l’adresse< dps >pour afficher la pile d’allocation.
• Paramètre 3 - Adresse du nom de la dll propriétaire. Exécutez l’adresse< du >fichier pour lire le nom de la dll.
• Paramètre 4 - Base de la dll propriétaire. Exécutez .reload <dll_name> = <adresse> pour recharger la dll propriétaire. Utilisez « lm » pour obtenir plus d’informations sur les modules chargés et déchargés.

• Couche de test : Fuite
• ID d’arrêt : MANCHE
• Arrêter le code : 0x901
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Une clé HKEY a été divulguée.

Cet arrêt est généré si la dll propriétaire de la clé de Registre a été déchargée dynamiquement lors de la gestion des ressources.

• Paramètre 1 - Valeur du HKEY fuite.
• Paramètre 2 - Adresse à la trace de la pile d’allocation. Exécutez l’adresse< dps >pour afficher la pile d’allocation.
• Paramètre 3 - Adresse du nom de la dll propriétaire. Exécutez l’adresse< du >fichier pour lire le nom de la dll.
• Paramètre 4 - Base de la dll propriétaire. Exécutez .reload <dll_name> = <adresse> pour recharger la dll propriétaire. Utilisez « lm » pour obtenir plus d’informations sur les modules chargés et déchargés.

• Couche de test : Fuite
• ID d’arrêt : REGISTRE
• Arrêter le code : 0x902
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Une réservation virtuelle a été divulguée.

Cet arrêt est généré si la dll propriétaire de la réservation virtuelle a été déchargée dynamiquement lors de la gestion des ressources.

• Paramètre 1 - Adresse de réservation divulguée.
• Paramètre 2 - Adresse à la trace de la pile d’allocation. Exécutez l’adresse< dps >pour afficher la pile d’allocation.
• Paramètre 3 - Adresse du nom de la dll propriétaire. Exécutez l’adresse< du >fichier pour lire le nom de la dll.
• Paramètre 4 - Base de la dll propriétaire. Exécutez .reload <dll_name> = <adresse> pour recharger la dll propriétaire. Utilisez « lm » pour obtenir plus d’informations sur les modules chargés et déchargés.

• Couche de test : Fuite
• ID d’arrêt : VIRTUAL_RESERVATION
• Arrêter le code : 0x903
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Une BSTR a été divulguée.

Cet arrêt est généré si la dll propriétaire de SysString a été déchargée dynamiquement lors de la propriété des ressources.

• Paramètre 1 - Adresse de la BSTR divulguée. Exécutez !heap -p -a <adresse> pour obtenir des informations supplémentaires sur l’allocation.
• Paramètre 2 - Adresse à la trace de la pile d’allocation. Exécutez l’adresse< dps >pour afficher la pile d’allocation.
• Paramètre 3 - Adresse du nom de la dll propriétaire. Exécutez l’adresse< du >fichier pour lire le nom de la dll.
• Paramètre 4 - Base de la dll propriétaire. Exécutez .reload <dll_name> = <adresse> pour recharger la dll propriétaire. Utilisez « lm » pour obtenir plus d’informations sur les modules chargés et déchargés.

• Couche de test : Fuite
• ID d’arrêt : SYSSTRING
• Arrêter le code : 0x904
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Une notification d’alimentation n’a pas été annulée.

Cet arrêt est généré si la dll inscrite pour la notification d’alimentation et a été déchargée dynamiquement sans désinscrire.

• Paramètre 1 - Adresse de l’inscription de notification d’alimentation.
• Paramètre 2 - Adresse à la trace de la pile d’inscription. Exécutez l’adresse< dps >pour afficher la pile d’allocation.
• Paramètre 3 - Adresse du nom de la dll propriétaire. Exécutez l’adresse< du >fichier pour lire le nom de la dll.
• Paramètre 4 - Base de la dll propriétaire. Exécutez .reload <dll_name> = <adresse> pour recharger la dll propriétaire. Utilisez « lm » pour obtenir plus d’informations sur les modules chargés et déchargés.

• Couche de test : Fuite
• ID d’arrêt : POWER_NOTIFICATION
• Arrêter le code : 0x905
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Verrouiller les détails de l’arrêt

Le thread ne peut pas posséder de section critique.

Cet arrêt est généré si un thread (l’ID de thread est paramètre1) est arrêté, suspendu ou dans un état (le thread de travail a terminé un élément de travail) dans lequel il ne peut pas contenir de section critique. Le thread actuel est le coupable. Pour déboguer cet arrêt, utilisez les commandes de débogueur suivantes :

• kb : pour obtenir la trace de la pile actuelle. Si le thread actuel est le propriétaire de la section critique, il appelle probablement ExitThread. Le thread actuel doit avoir libéré la section critique avant de quitter. Si le thread actuel appelle TerminateThread ou SuspendThread, il ne doit pas le faire pour un thread contenant une section critique.
• !cs -s <parameter2> : informations de vidage sur cette section critique.
• paramètre ln2>< : pour afficher les symboles près de l’adresse de la section critique. Cela doit vous aider à identifier la section critique divulguée.
• paramètre dps4>< : pour vider la trace de pile pour l’initialisation de cette section critique.

• Paramètre 1 - ID de thread.
• Paramètre 2 - Adresse de section critique.
• Paramètre 3 - Adresse des informations de débogage de section critique.
• Paramètre 4 -Suivi de la pile d’initialisation  de section critique.

• Couche de test : Serrures
• ID d’arrêt : EXIT_THREAD_OWNS_LOCK
• Arrêter le code : 0x200
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Déchargement de DLL contenant une section critique active.

Cet arrêt est généré si une DLL a une variable globale contenant une section critique et que la DLL est déchargée, mais que la section critique n’a pas été supprimée. Pour déboguer cet arrêt, utilisez les commandes de débogueur suivantes :

• du <parameter3> : pour vider le nom de la DLL coupable.
• .reload dllname ou .reload dllname = <parameter4> - pour recharger les symboles de cette DLL.
• !cs -s <parameter1> : informations de vidage sur cette section critique.
• ln <parameter1> : pour afficher les symboles près de l’adresse de la section critique. Cela doit vous aider à identifier la section critique divulguée.
• paramètre dps2>< : pour vider la trace de la pile pour l’initialisation de cette section critique.

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 -Suivi de la pile d’initialisation  de section critique.
• Paramètre 3 - Adresse du nom de la DLL.
• Paramètre 4 - Adresse de base DLL.

• Couche de test : Serrures
• ID d’arrêt : LOCK_IN_UNLOADED_DLL
• Arrêter le code : 0x201
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Libérer le bloc de tas contenant une section critique active.

Cet arrêt est généré si une allocation de tas contient une section critique, l’allocation est libérée et la section critique n’a pas été supprimée. Pour déboguer cet arrêt, utilisez les commandes de débogueur suivantes :

• !cs -s <(paramètre1)> : informations de vidage sur cette section critique.
• ln <parameter1> : pour afficher les symboles près de l’adresse de la section critique. Cela doit vous aider à identifier la section critique divulguée.
• paramètre dps2>< : pour vider la trace de la pile pour l’initialisation de cette section critique.
• < parameter3> et <parameter4> peuvent aider à comprendre où ce bloc de tas a été alloué (la taille de l’allocation est probablement significative).

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 -Suivi de la pile d’initialisation  de section critique.
• Paramètre 3 - Adresse de bloc de tas.
• Paramètre 4 -Taille  du bloc de tas.

• Couche de test : Serrures
• ID d’arrêt : LOCK_IN_FREED_HEAP
• Arrêter le code : 0x202
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Section critique double initialisée ou endommagée.

En règle générale, cet arrêt est généré si une section critique a été initialisée plusieurs fois. Dans ce cas, paramètre3 et paramètre4 sont les adresses de trace de pile pour deux de ces initialisations. Parfois, il est possible d’arrêter cette opération si la section critique ou sa structure d’informations de débogage a été endommagée. Dans ce deuxième cas, il est possible que le paramètre3 et le paramètre4 ne soient pas valides et inutiles. Pour déboguer cet arrêt :

• !cs -s -d <paramètre2> : informations de vidage sur cette section critique.
• ln <parameter1> : pour afficher les symboles près de l’adresse de la section critique. Cela peut aider à identifier la section critique s’il s’agit d’une variable globale.
• paramètre dps3>< et paramètre dps4>< : pour identifier les deux chemins de code pour initialiser cette section critique.

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 - Adresse de la structure d’informations de débogage trouvée dans la liste active.
• Paramètre 3 -Première  trace de pile d’initialisation.
• Paramètre 4 - Deuxième trace de pile d’initialisation.

• Couche de test : Serrures
• ID d’arrêt : LOCK_DOUBLE_INITIALIZE
• Arrêter le code : 0x203
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Mémoire libre contenant une section critique active.

Cet arrêt est généré si la mémoire contenant une section critique a été libérée, mais que la section critique n’a pas été supprimée à l’aide de DeleteCriticalSection. Pour déboguer cet arrêt, utilisez les commandes de débogueur suivantes :</p.>

• !cs -s -d <paramètre2> : informations de vidage sur cette section critique.
• paramètre dps3>< : pour identifier le chemin du code pour l’initialisation de cette section critique.

Dans la plupart des cas, le vérificateur de verrou détecte les sections critiques immédiatement divulguées contenues dans une allocation de tas, une plage DLL, une allocation de mémoire virtuelle ou une plage de mémoire mappée MapViewOfFile et émet des arrêts différents dans ces cas. Il y a donc très peu de cas laissés pour cet arrêt de vérificateur. Le verrou doit se trouver dans une plage de mémoire libérée par du code en mode noyau ou libérée par des API telles que VirtualFreeEx. Le plus souvent, cet arrêt est rencontré si un arrêt précédent (par exemple, LOCK_IN_FREED_HEAP ou LOCK_IN_UNLOADED_DLL) a été poursuivi en appuyant sur « g » dans la console du débogueur.

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 - Adresse des informations de débogage de section critique.
• Paramètre 3 -Suivi de la pile d’initialisation  de section critique.
• Paramètre 4 - Non utilisé.

• Couche de test : Serrures
• ID d’arrêt : LOCK_IN_FREED_MEMORY
• Arrêter le code : 0x204
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Section critique endommagée.

Cet arrêt est généré si le champ DebugInfo de la section critique pointe vers la mémoire libérée. En règle générale, une autre structure DebugInfo valide se trouve dans la liste des sections critiques actives. Sans corruption, les deux pointeurs doivent être identiques. Pour déboguer cet arrêt, utilisez les commandes de débogueur suivantes :

• !cs -s -d <paramètre3> - informations de vidage sur cette section critique basées sur le contenu actuel de la structure d’informations de débogage trouvée dans la liste active (cette structure est rarement endommagée, donc généralement ces informations sont fiables).
• !cs -s <paramètre1> : informations de vidage sur cette section critique basées sur le contenu actuel de la structure de section critique (la structure est déjà endommagée si parfois ces informations ne sont pas fiables).
• paramètre dps4>< : pour identifier le chemin d’accès du code pour l’initialisation de cette section critique.

Videz la section critique au paramètre1> de l’adresse < et recherchez le modèle d’altération. Avec de bons symboles pour ntdll.dl, vous pouvez utiliser les commandes suivantes :

• dt ntdll !_RTL_CRITICAL_SECTION LOCK_ADDRESS
• dt ntdll !_RTL_CRITICAL_SECTION_DEBUG DEBUG_ADDRESS

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 - Adresse des informations de débogage non valides de cette section critique.
• Paramètre 3 - Adresse des informations de débogage trouvées dans la liste active.
• Paramètre 4 - Suivi de la pile d’initialisation.

• Couche de test : Serrures
• ID d’arrêt : LOCK_CORRUPTED
• Arrêter le code : 0x205
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Thread de propriétaire de section critique non valide.

Cet arrêt est généré si l’ID de thread propriétaire n’est pas valide dans le contexte actuel. Pour déboguer cet arrêt :

• !cs -s <parameter1> : informations de vidage sur cette section critique.
• ln <parameter1> : pour afficher les symboles près de l’adresse de la section critique. Cela doit vous aider à identifier la section critique.

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 - Propriétaire du thread.
• Paramètre 3 -Thread  propriétaire attendu.
• Paramètre 4 - Adresse d’informations de débogage de section critique.

• Couche de test : Serrures
• ID d’arrêt : LOCK_INVALID_OWNER
• Arrêter le code : 0x206
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Nombre de récursivités de section critique non valide.

Cet arrêt est généré si le champ de nombre de récursivités de la structure de section critique n’est pas valide dans le contexte actuel. Pour déboguer cet arrêt :

• !cs -s <parameter1> : informations de vidage sur cette section critique.
• ln <parameter1> : pour afficher les symboles près de l’adresse de la section critique. Cela doit vous aider à identifier la section critique.

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 - Nombre de récursivités.
• Paramètre 3 - Nombre de récursivités attendues.
• Paramètre 4 - Adresse d’informations de débogage de section critique.

• Couche de test : Serrures
• ID d’arrêt : LOCK_INVALID_RECURSION_COUNT
• Arrêter le code : 0x207
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Suppression d’une section critique avec un nombre de verrous non valide.

Cet arrêt est généré si une section critique appartient à un thread s’il est supprimé ou si la section critique n’est pas initialisée. Pour déboguer cet arrêt :

• !cs -s <parameter1> : informations de vidage sur cette section critique. Si le thread propriétaire est 0, la section critique n’a pas été initialisée.
• ln <parameter1> : pour afficher les symboles près de l’adresse de la section critique. Cela doit vous aider à identifier la section critique.

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 - Nombre de verrous.
• Paramètre 3 - Nombre de verrous attendus.
• Paramètre 4 - Propriétaire du thread.

• Couche de test : Serrures
• ID d’arrêt : LOCK_INVALID_LOCK_COUNT
• Arrêter le code : 0x208
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Section critique sur-libérée ou endommagée.

Cet arrêt est généré si une section critique est libérée plus de fois que le thread actuel l’a acquis. Pour déboguer cet arrêt :

• !cs -s <parameter1> : informations de vidage sur cette section critique.
• !cs -s -d <paramètre4> : informations de vidage sur cette section critique.
• ln <parameter1> : pour afficher les symboles près de l’adresse de la section critique. Cela doit vous aider à identifier la section critique.

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 - Nombre de verrous.
• Paramètre 3 - Nombre de verrous attendus.
• Paramètre 4 - Adresse d’informations de débogage de section critique.

• Couche de test : Serrures
• ID d’arrêt : LOCK_OVER_RELEASED
• Arrêter le code : 0x209
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Section critique non initialisée.

Cet arrêt est généré si une section critique est utilisée sans être initialisée ou après sa suppression. Pour déboguer cet arrêt :

• ln <parameter1> : pour afficher les symboles près de l’adresse de la section critique. Cela doit vous aider à identifier la section critique.

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 - Adresse d’informations de débogage de section critique.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Serrures
• ID d’arrêt : LOCK_NOT_INITIALIZED
• Arrêter le code : 0x210
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

La section critique est déjà initialisée.

Cet arrêt est généré si une section critique est réinitialisée par le thread actuel. Pour déboguer cet arrêt :

• !cs -s <parameter1> ou !cs -s -d <parameter2> - informations de vidage sur cette section critique.
• ln <parameter1> : pour afficher les symboles près de l’adresse de la section critique. Cela peut aider à identifier la section critique s’il s’agit d’une variable globale.
• paramètre dps3 <> : pour identifier le chemin du code pour la première initialisation de cette section critique.
• kb : pour afficher la trace de pile actuelle, qui réinitialise cette section critique.

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 - Adresse d’informations de débogage de section critique.
• Paramètre 3 -Première  trace de pile d’initialisation. Utiliser dps pour la vider si la valeur n’est pas NULL
• Paramètre 4 - Non utilisé.

• Couche de test : Serrures
• ID d’arrêt : LOCK_ALREADY_INITIALIZED
• Arrêter le code : 0x211
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Libération de la mémoire virtuelle contenant une section critique active.

Cet arrêt est généré si le thread actuel appelle VirtualFree sur un bloc de mémoire qui contient une section critique active. L’application doit appeler DeleteCriticalSection sur cette section critique avant de libérer cette mémoire.

• kb : pour afficher la trace de pile actuelle, qui appelle VirtualFree. Le coupable probable est la DLL qui appelle VirtualFree.
• !cs -s <parameter1> : informations de vidage sur cette section critique.
• paramètre dps2>< : pour identifier le chemin du code pour l’initialisation de cette section critique.

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 -Suivi de la pile d’initialisation  de section critique.
• Paramètre 3 - Adresse de bloc de mémoire.
• Paramètre 4 -Taille  du bloc de mémoire.

• Couche de test : Serrures
• ID d’arrêt : LOCK_IN_FREED_VMEM
• Arrêter le code : 0x212
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Annuler le mappage de la région de mémoire contenant une section critique active.

Cet arrêt est généré si le thread actuel appelle UnmapViewOfFile sur un bloc de mémoire qui contient une section critique active. L’application doit appeler DeleteCriticalSection sur cette section critique avant d’annuler le mappage de cette mémoire.

• kb : pour afficher la trace de pile actuelle, qui appelle UnmapViewOfFile . Le coupable probable est la DLL qui appelle UnmapViewOfFile.
• !cs -s <parameter1> : informations de vidage sur cette section critique.
• paramètre dps2>< : pour identifier le chemin du code pour l’initialisation de cette section critique.

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 -Suivi de la pile d’initialisation  de section critique.
• Paramètre 3 - Adresse de bloc de mémoire.
• Paramètre 4 -Taille  du bloc de mémoire.

• Couche de test : Serrures
• ID d’arrêt : LOCK_IN_UNMAPPED_MEM
• Arrêter le code : 0x213
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Le thread actuel ne possède aucune section critique.

Cet arrêt est généré si le thread actuel appelle LeaveCriticalSection, mais, selon la comptabilité du vérificateur interne, il ne possède aucune section critique. Si \<parameter2\> est égal à zéro, il s’agit probablement d’un bogue dans le thread actuel. Il tente de laisser une section critique qu’elle n’a pas entrée, ou peut-être qu’elle appelle LeaveCriticalSection plus de fois qu’elle a appelé EnterCriticalSection pour la même section critique. Si \<parameter2\> n’est pas zéro (il s’agit d’un nombre entier négatif), les structures de données du vérificateur interne sont probablement endommagées.

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 - Nombre de sections critiques détenues par le thread actuel.
• Paramètre 3 - Non utilisé
• Paramètre 4 - Non utilisé

• Couche de test : Serrures
• ID d’arrêt : THREAD_NOT_LOCK_OWNER
• Arrêter le code : 0x214
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Utilisation d’une section critique privée vers une autre DLL.

Cet arrêt est généré si le thread actuel tente d’utiliser un verrou privé qui se trouve à l’intérieur d’une autre DLL. Par exemple, a.dll tente d’entrer une section critique définie dans ntdll.dll. Les verrous privés ne peuvent pas être utilisés dans les DLL.

• Paramètre 1 - Adresse de section critique.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé
• Paramètre 4 - Non utilisé

• Couche de test : Serrures
• ID d’arrêt : LOCK_PRIVATE
• Arrêter le code : 0x215
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Détails de l’arrêt SRWLock

Le verrou SRW n’est pas initialisé.

Cet arrêt est généré si un thread tente d’utiliser le verrou SRW (Param1) qui n’est pas initialisé. Pour déboguer cet arrêt, utilisez « kb » pour obtenir la trace de la pile actuelle. C’est là que le verrou SRW est utilisé. Le verrou SRW doit être initialisé à l’aide de « InitializeSRWLock » avant de pouvoir être utilisé.

• Paramètre 1 - SRW Lock
• Paramètre 2 - Non utilisé
• Paramètre 3 - Non utilisé
• Paramètre 4 - Non utilisé

• Couche de test : SRWLock
• ID d’arrêt : NOT_INITIALIZED
• Arrêter le code : 0x250
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Le verrou SRW est déjà initialisé.

Cet arrêt est généré si le verrou SRW (Param1) est réin initialisé. Si le verrou SRW est utilisé activement par d’autres threads, le re-initialisation du verrou entraîne un comportement imprévisible par l’application, y compris les blocages et les blocages. La trace de la pile d’initialisation peut afficher une acquisition si le verrou SRW a été initialisé statiquement. Pour déboguer cet arrêt :

• kb : pour obtenir la trace de la pile actuelle. C’est là que le verrou SRW est redé initialisé.
• paramètre dps3>< : pour obtenir la trace de la pile d’initialisation de verrou SRW. Cette trace de pile peut afficher une acquisition si le verrou a été initialisé statiquement.

• Paramètre 1 - SRW Lock
• Paramètre 2 - ThreadId du thread qui a initialisé le verrou SRW.
• Paramètre 3 - Adresse de la trace de la pile d’initialisation. Utilisez l’adresse< dps >pour voir où le verrou SRW a été initialisé.
• Paramètre 4 - Non utilisé

• Couche de test : SRWLock
• ID d’arrêt : ALREADY_INITIALIZED
• Arrêter le code : 0x251
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Incompatibilité Acquire-Release sur le verrou SRW.

Cet arrêt est généré si le verrou SRW (Param1) est libéré avec une API de mise en production incorrecte. Si le verrou SRW a été acquis pour l’accès partagé et est publié à l’aide de l’API de mise en production exclusive ou si le verrou SRW a été acquis pour l’accès exclusif et est mis en production à l’aide de l’API de mise en production partagée. Cela peut entraîner un comportement imprévisible par l’application, y compris les blocages et les blocages. Pour déboguer cet arrêt :

• kb : pour obtenir la trace de la pile actuelle. C’est là que le verrou SRW est libéré à l’aide de l’API incorrecte.
• paramètre dps3 <> : pour obtenir la trace de pile d’acquisition du verrou SRW.

• Paramètre 1 - SRW Lock
• Paramètre 2 - ThreadId du thread qui a acquis le verrou SRW.
• Paramètre 3 - Adresse de la trace de la pile d’acquisition. Utilisez l’adresse< dps >pour voir où le verrou SRW a été acquis.
• Paramètre 4 - Non utilisé

• Couche de test : SRWLock
• ID d’arrêt : MISMATCHED_ACQUIRE_RELEASE
• Arrêter le code : 0x252
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Le verrou SRW est acquis de manière récursive par le même thread.

Cet arrêt est généré si le verrou SRW (Param1) est acquis de manière récursive par le même thread. Cela entraîne un blocage et le thread bloque indéfiniment. L’acquisition récursive d’un verrou SRW en mode exclusif entraîne un blocage. L’acquisition récursive d’un verrou SRW en mode partagé entraîne un blocage lorsqu’un thread attend un accès exclusif. Prenons l’exemple ci-dessous : - Le thread A acquiert le verrou SRW en mode partagé - Le thread B tente d’acquérir le verrou SRW en mode exclusif et attend - Thread A tente d’acquérir le verrou SRW en mode partagé de manière récursive. Cela sera réussi tant qu’il n’y a pas d’serveur exclusif (dans ce cas B). Étant donné que les verrous SRW n’ont pas de faim d’enregistreur, le thread A attend derrière le thread B. À présent, thread B attend le thread A, qui attend à son tour le thread B à l’origine d’une attente circulaire et donc d’un blocage. Pour déboguer cet arrêt :

• kb : pour obtenir la trace de la pile actuelle. C’est là que le verrou SRW est acquis de manière récursive.
• paramètre dps2>< : pour obtenir la trace de pile pour la première acquisition.

• Paramètre 1 - SRW Lock
• Paramètre 2 - Adresse du premier suivi d’acquisition de la pile. Utilisez l’adresse< dps >pour voir où le verrou SRW a été acquis.
• Paramètre 3 - Non utilisé
• Paramètre 4 - Non utilisé

• Couche de test : SRWLock
• ID d’arrêt : RECURSIVE_ACQUIRE
• Arrêter le code : 0x253
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Le thread qui quitte ou se termine possède un verrou SRW.

Cet arrêt est généré si le thread (Param2) propriétaire du verrou SRW (Param1) quitte ou se termine. Cela entraîne un verrou SRW orphelin et les threads qui tentent d’acquérir ce verrou bloquent indéfiniment. Pour déboguer son arrêt :

• kb : pour obtenir la trace de la pile actuelle. C’est là que le thread quitte ou est arrêté.
• paramètre dps3<> : pour obtenir la trace de pile d’acquisition du verrou SRW.

• Paramètre 1 - SRW Lock
• Paramètre 2 - ThreadId du thread qui quitte ou se termine.
• Paramètre 3 - Adresse de la trace de la pile d’acquisition. Utilisez l’adresse< dps >pour voir où le verrou SRW a été acquis.
• Paramètre 4 - Non utilisé

• Couche de test : SRWLock
• ID d’arrêt : EXIT_THREAD_OWNS_LOCK
• Arrêter le code : 0x254
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Le verrou SRW libéré n’a pas été acquis par ce thread.

Cet arrêt est généré si le verrou SRW (Param1) est libéré par le thread (Param2) qui n’a pas acquis le verrou. Cela représente une mauvaise pratique de programmation difficile à obtenir et peut entraîner un comportement imprévisible par l’application. Pour déboguer cet arrêt :

• kb : pour obtenir la trace de la pile actuelle. C’est là que le thread libère le verrou SRW qu’il n’a pas acquis.
• paramètre dps4>< : pour obtenir la trace de pile d’acquisition du verrou SRW.

• Paramètre 1 - SRW Lock
• Paramètre 2 - ThreadId actuel.
• Paramètre 3 - ThreadId du thread qui a acquis le verrou SRW.
• Paramètre 4 - Adresse de la trace de la pile d’acquisition. Utilisez l’adresse< dps >pour voir où le verrou SRW a été acquis.

• Couche de test : SRWLock
• ID d’arrêt : INVALID_OWNER
• Arrêter le code : 0x255
• gravité : avertissement 
• erreur unique : 
• rapport d’erreurs : None
• Fichier journal : oui
• Créer un backtrace : oui

La mémoire libérée contient un verrou SRW actif.

Cet arrêt est généré si l’adresse mémoire (Param1) libérée contient un verrou SRW actif qui est toujours en cours d’utilisation. Cela peut entraîner un comportement imprévisible par l’application, y compris les blocages et les blocages. Pour déboguer cet arrêt :

• kb : pour obtenir la trace de la pile actuelle. C’est là que la mémoire est libérée qui contient un verrou SRW actif.
• paramètre dps4>< : pour obtenir la trace de pile d’acquisition du verrou SRW.

• Paramètre 1 - SRW Lock
• Paramètre 2 - Adresse de la mémoire libérée.
• Paramètre 3 - ThreadId du thread qui a acquis le verrou SRW.
• Paramètre 4 - Adresse de la trace de la pile d’acquisition. Utilisez l’adresse< dps >pour voir où le verrou SRW a été acquis.

• Couche de test : SRWLock
• ID d’arrêt : IN_FREED_MEMORY
• Arrêter le code : 0x256
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

La DLL déchargée contient un verrou SRW actif.

Cet arrêt est généré si la DLL déchargée (Param2) contient un verrou SRW actif (Param1) qui est toujours utilisé. Cela peut entraîner un comportement imprévisible par l’application, y compris les blocages et les blocages. Pour déboguer cet arrêt :

• kb : pour obtenir la trace de la pile actuelle. C’est là que la DLL est déchargée qui contient un verrou SRW actif.
• du <parameter2> : pour trouver le nom de la DLL qui est déchargée.
• paramètre dps4>< : pour obtenir la trace de pile d’acquisition du verrou SRW.

• Paramètre 1 - SRW Lock
• Paramètre 2 - Adresse du nom de la DLL déchargée. Utilisez l’adresse< du >pour afficher le nom.
• Paramètre 3 - ThreadId du thread qui a acquis le verrou SRW.
• Paramètre 4 - Adresse de la trace de la pile d’acquisition. Utilisez l’adresse< dps >pour voir où le verrou SRW a été acquis.

• Couche de test : SRWLock
• ID d’arrêt : IN_UNLOADED_DLL
• Arrêter le code : 0x257
• gravité : avertissement 
• erreur unique : 
• rapport d’erreurs : None
• Fichier journal : oui
• Créer un backtrace : oui

Détails de l’arrêt de la mémoire

Libérer un bloc de mémoire virtuelle avec une taille ou une adresse de début non valides.

Cet arrêt est généré si le vérificateur d’application détecte un virtualfree ou une DLL déchargé avec une adresse de démarrage ou une taille de démarrage non valide de l’allocation de mémoire. Dans le cas d’un déchargement DLL, cela signifie probablement une altération de la mémoire à l’intérieur de la liste DLL chargée. Pour déboguer cet arrêt, examinez la trace de la pile actuelle et l’adresse de mémoire et la taille sur le point d’être libérées et essayez de déterminer pourquoi elles ne sont pas valides.

• Paramètre 1 - Adresse de base d’allocation.
• Paramètre 2 -Taille  de la région de mémoire.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : INVALID_FREEMEM
• Arrêter le code : 0x600
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Appel d’alloc virtuel incorrect.

Cet arrêt est généré si le vérificateur d’application détecte un appel VirtualAlloc avec une adresse de début ou une taille de l’allocation de mémoire non valide. Pour déboguer cet arrêt, examinez la trace de pile actuelle (ko) et l’adresse de mémoire et la taille qui sont sur le point d’être allouées et essayez de déterminer pourquoi elles ne sont pas valides.

• Paramètre 1 - Pointeur vers l’adresse de base d’allocation.
• Paramètre 2 - Pointeur vers la taille de la région de mémoire.
• Paramètre 3 - Non utilisé
• Paramètre 4 - Non utilisé

• Couche de test : Mémoire
• ID d’arrêt : INVALID_ALLOCMEM
• Arrêter le code : 0x601
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Appel d’affichage de carte incorrect.

Cet arrêt est généré si le vérificateur d’application détecte un appel MapViewOfFile avec une adresse de base ou une taille de base non valide du mappage. Pour déboguer cet arrêt, examinez la trace de pile actuelle (ko) et l’adresse de mémoire et la taille sur le point d’être mappées et essayez de déterminer pourquoi elles ne sont pas valides.

• Paramètre 1 - Pointeur vers l’adresse de base de mappage.
• Paramètre 2 - Pointeur vers la taille de l’affichage.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : INVALID_MAPVIEW
• Arrêter le code : 0x602
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Détection d’une adresse non valide.

Cet arrêt est généré si le vérificateur d’application détecte un appel IsBadXXXPtr avec une adresse non valide (par exemple, une adresse en mode noyau, au lieu d’une adresse en mode utilisateur normal) pour la mémoire tampon à sonder. Pour déboguer cet arrêt, examinez la trace de pile actuelle (kb) et essayez de déterminer pourquoi l’appelant de la fonction IsBadXXXPtr a fini par une adresse non valide. Plusieurs fois, l’adresse est un bogus simple, par exemple un pointeur non initialisé. MSDN Library répertorie quelques raisons pour lesquelles les applications ne doivent pas utiliser les API IsBadXXXPtr : dans un environnement multitâche préemptif, il est possible que d’autres threads modifient l’accès du processus à la mémoire testée. La désactivation des pointeurs potentiellement non valides peut désactiver l’extension de pile dans d’autres threads. Un thread qui épuise sa pile, lorsque l’extension de pile a été désactivée, entraîne l’arrêt immédiat du processus parent, sans fenêtre d’erreur contextuelle ni informations de diagnostic. Les threads d’un processus sont censés coopérer de telle sorte que l’un ne libère pas la mémoire dont l’autre a besoin. L’utilisation de cette fonction n’annule pas la nécessité d’effectuer cette opération. Si ce n’est pas le cas, l’application peut échouer de manière imprévisible. Pour toutes ces raisons, nous vous recommandons de ne jamais utiliser ces API.

• Paramètre 1 - Adresse de début.
• Paramètre 2 -Taille  du bloc de mémoire.
• Paramètre 3 - Adresse non valide.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : PROBE_INVALID_ADDRESS
• Arrêter le code : 0x603
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Détection de la mémoire libre.

Cet arrêt est généré si le vérificateur d’application détecte un appel IsBadXXXPtr pour une allocation de mémoire gratuite. C’est très mauvais, car il est possible que, dans certains autres cas, cette mémoire ait déjà été réutilisée pour une autre allocation. Étant donné que le chemin de code actuel (kb) ne possède pas cette mémoire, il peut finir par endommager la mémoire d’une autre personne, avec des effets désastreux. Pour déboguer cet arrêt, examinez la trace de pile actuelle (ko) et essayez de déterminer pourquoi l’appelant de la fonction IsBadXXXPtr a fini par tester la mémoire libre. L’adresse peut être un bogus simple (par exemple, un pointeur non initialisé) ou peut-être déjà libéré de la mémoire. Si la mémoire a déjà été libérée par l’une des API VirtualFree ou UnmapViewOfFile, ' !avrf -vs -a parameter3' recherche un journal des traces de pile des chemins de code qui ont alloué/libéré cette adresse et affichent ces traces de pile s’ils sont disponibles. Cela peut afficher la trace de pile qui a libéré cette mémoire. Plus souvent, la mémoire est une allocation de tas déjà libérée. Pour vérifier cette possibilité, ' !avrf -hp -a paramètre3' recherche un journal des traces de pile des chemins de code alloués/libérés de cette adresse depuis/vers le tas et affichent ces traces de pile si elles sont disponibles. MSDN Library répertorie quelques raisons pour lesquelles les applications ne doivent pas utiliser les API IsBadXXXPtr : dans un environnement multitâche préemptif, il est possible que d’autres threads modifient l’accès du processus à la mémoire testée. La désactivation des pointeurs potentiellement non valides peut désactiver l’extension de pile dans d’autres threads. Un thread qui épuise sa pile, lorsque l’extension de pile a été désactivée, entraîne l’arrêt immédiat du processus parent, sans fenêtre d’erreur contextuelle ni informations de diagnostic. Les threads d’un processus sont censés coopérer de telle sorte que l’un ne libère pas la mémoire dont l’autre a besoin. L’utilisation de cette fonction n’annule pas la nécessité d’effectuer cette opération. Si ce n’est pas le cas, l’application peut échouer de manière imprévisible. Pour toutes ces raisons, nous vous recommandons de ne jamais utiliser ces API.

• Paramètre 1 - Adresse de début.
• Paramètre 2 -Taille  du bloc de mémoire.
• Paramètre 3 - Adresse de la page mémoire libre.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : PROBE_FREE_MEM
• Arrêter le code : 0x604
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Détection d’une page de garde.

Cet arrêt est généré si le vérificateur d’application détecte un appel IsBadXXXPtr pour une allocation de mémoire contenant au moins une GUARD_PAGE. C’est très mauvais, car il est très possible que cette GUARD_PAGE soit la fin de la pile actuelle d’un thread. Comme décrit dans la bibliothèque MSDN : La déréférencement des pointeurs potentiellement non valides peut désactiver l’extension de pile dans d’autres threads. Un thread qui épuise sa pile, lorsque l’extension de pile a été désactivée, entraîne l’arrêt immédiat du processus parent, sans fenêtre d’erreur contextuelle ni informations de diagnostic. Pour déboguer cet arrêt, examinez la trace de pile actuelle (kb) et essayez de déterminer pourquoi l’appelant de la fonction IsBadXXXPtr a fini par rechercher une GUARD_PAGE. MSDN Library répertorie quelques raisons pour lesquelles les applications ne doivent pas utiliser les API IsBadXXXPtr : dans un environnement multitâche préemptif, il est possible que d’autres threads modifient l’accès du processus à la mémoire testée. La désactivation des pointeurs potentiellement non valides peut désactiver l’extension de pile dans d’autres threads. Un thread qui épuise sa pile, lorsque l’extension de pile a été désactivée, entraîne l’arrêt immédiat du processus parent, sans fenêtre d’erreur contextuelle ni informations de diagnostic. Les threads d’un processus sont censés coopérer de telle sorte que l’un ne libère pas la mémoire dont l’autre a besoin. L’utilisation de cette fonction n’annule pas la nécessité d’effectuer cette opération. Si ce n’est pas le cas, l’application peut échouer de manière imprévisible. Pour toutes ces raisons, nous vous recommandons de ne jamais utiliser ces API.

• Paramètre 1 - Adresse de début.
• Paramètre 2 -Taille  du bloc de mémoire.
• Paramètre 3 - Adresse de la page de garde.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : PROBE_GUARD_PAGE
• Arrêter le code : 0x605
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Détection de l’adresse NULL.

Cet arrêt est généré si le vérificateur d’application détecte un appel IsBadXXXPtr avec une adresse NULL. Pour déboguer cet arrêt, examinez la trace de pile actuelle (kb) et essayez de déterminer pourquoi l’appelant de la fonction IsBadXXXPtr a fini par l’adresse NULL. Il s’agit généralement du signe d’une personne qui ne vérifie pas la valeur de retour de l’une des fonctions d’allocation de mémoire. Par exemple, le code ci-dessous est incorrect :

void Use(PVOID p);

int main(void) {
    PVOID p;
    p = malloc(1024);
    Use(p);
    return 0;
}

void Use(PVOID p) {
    if (IsBadReadPtr(p)) {
        return;
    }
    // p is safe to be used here.
}

Ce code doit être réécrit comme suit :

int main (void) 
{ 
    PVOID p; 
    
    p = malloc (1024); 
    if (NULL == p)) { 
        return -1;
     } 

    Use (p); 

    return 0; 
} 

void Use (PVOID p) 
{
    // 
    // p is safe to be used here. 
    // 
} 

MSDN Library répertorie quelques raisons pour lesquelles les applications ne doivent pas utiliser les API IsBadXXXPtr : dans un environnement multitâche préemptif, il est possible que d’autres threads modifient l’accès du processus à la mémoire testée. La désactivation des pointeurs potentiellement non valides peut désactiver l’extension de pile dans d’autres threads. Un thread qui épuise sa pile, lorsque l’extension de pile a été désactivée, entraîne l’arrêt immédiat du processus parent, sans fenêtre d’erreur contextuelle ni informations de diagnostic. Les threads d’un processus sont censés coopérer de telle sorte que l’un ne libère pas la mémoire dont l’autre a besoin. L’utilisation de cette fonction n’annule pas la nécessité d’effectuer cette opération. Si ce n’est pas le cas, l’application peut échouer de manière imprévisible. Pour toutes ces raisons, nous vous recommandons de ne jamais utiliser ces API.

• paramètre 1 - Non utilisé.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : PROBE_NULL
• Arrêter le code : 0x606
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Détection d’un bloc de mémoire avec une adresse ou une taille de début non valide.

Cet arrêt est généré si le vérificateur d’application détecte un appel IsBadXXXPtr avec une adresse de démarrage non valide (par exemple, une adresse en mode noyau, au lieu d’une adresse en mode utilisateur normal) ou une taille non valide pour la mémoire tampon à sonder. Pour déboguer cet arrêt, examinez la trace de pile actuelle (kb) et essayez de déterminer pourquoi l’appelant de la fonction IsBadXXXPtr a fini par une adresse ou une taille non valide. Plusieurs fois, l’adresse ou la taille sont des bogus simples, par exemple une variable non initialisée. MSDN Library répertorie quelques raisons pour lesquelles les applications ne doivent pas utiliser les API IsBadXXXPtr : dans un environnement multitâche préemptif, il est possible que d’autres threads modifient l’accès du processus à la mémoire testée. La désactivation des pointeurs potentiellement non valides peut désactiver l’extension de pile dans d’autres threads. Un thread qui épuise sa pile, lorsque l’extension de pile a été désactivée, entraîne l’arrêt immédiat du processus parent, sans fenêtre d’erreur contextuelle ni informations de diagnostic. Les threads d’un processus sont censés coopérer de telle sorte que l’un ne libère pas la mémoire dont l’autre a besoin. L’utilisation de cette fonction n’annule pas la nécessité d’effectuer cette opération. Si ce n’est pas le cas, l’application peut échouer de manière imprévisible. Pour toutes ces raisons, nous vous recommandons de ne jamais utiliser ces API.

• Paramètre 1 - Adresse de début.
• Paramètre 2 -Taille  du bloc de mémoire.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : PROBE_INVALID_START_OR_SIZE
• Arrêter le code : 0x607
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Déchargement de DLL avec une taille ou une adresse de début non valides.

Cet arrêt est généré si le vérificateur d’application détecte un déchargement DLL avec une adresse de démarrage ou une taille de la plage de mémoire DLL non valide. Cela signifie probablement une altération de la mémoire à l’intérieur de la liste DE DLL chargée ntdll.dll interne.

• Paramètre 1 - Adresse de base de mémoire DLL.
• Paramètre 2 -Taille  de la plage de mémoire DLL.
• Paramètre 3 - Adresse du nom de la DLL. Utilisez du pour la vider.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : INVALID_DLL_RANGE
• Arrêter le code : 0x608
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Libérer le bloc de mémoire à l’intérieur de la plage d’adresses de la pile du thread actuel.

Cet arrêt est généré si le vérificateur d’application détecte un VirtualFree pour un bloc de mémoire qui fait réellement partie de la pile du thread actuel ( !). Pour déboguer cet arrêt, examinez la trace de pile actuelle (ko) et essayez de comprendre pourquoi la fonction appelée VirtualFree pensait que le bloc de mémoire a été alloué dynamiquement ou mappé, mais qu’il s’agissait réellement de la mémoire allouée à partir de la pile.

• Paramètre 1 - Adresse de base d’allocation.
• Paramètre 2 -Taille  de la région de mémoire.
• Paramètre 3 - Stack low limit address.
• Paramètre 4 - Stack high limit address.

• Couche de test : Mémoire
• ID d’arrêt : FREE_THREAD_STACK_MEMORY
• Arrêter le code : 0x609
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Paramètre FreeType incorrect pour l’opération VirtualFree.

Cet arrêt est généré si le vérificateur d’application détecte un VirtualFree avec une valeur incorrecte pour le paramètre FreeType. Les deux seules valeurs acceptables pour ce paramètre sont MEM_DECOMMIT et MEM_RELEASE. Si VirtualFree est appelé avec une autre valeur, à l’exception de ces deux, VirtualFree ne libère pas la mémoire. Pour déboguer cet arrêt, examinez la trace de pile actuelle (kb) : l’appelant de VirtualFree est probablement le coupable.

• Paramètre 1 -Valeur  incorrecte utilisée par l’application.
• Paramètre 2 -Valeur  correcte attendue 1.
• Paramètre 3 -Valeur  correcte attendue 2.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : INVALID_FREE_TYPE
• Arrêter le code : 0x60A
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Essayez de libérer un bloc de mémoire virtuelle déjà gratuit.

Cet arrêt est généré si le vérificateur d’application détecte un VirtualFree pour une adresse déjà gratuite. Pour déboguer ce point d’arrêt, examinez la trace de pile actuelle (ko) et essayez de déterminer pourquoi la mémoire est déjà gratuite, mais l’application tente de la libérer à nouveau. ' !avrf -vs -a parameter1' recherche un journal des traces de pile des chemins de code qui ont alloué/libéré cette adresse et affichent ces traces de pile s’ils sont disponibles. Cela peut afficher la trace de pile qui a libéré cette mémoire.

• Paramètre 1 - Adresse de bloc de mémoire.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : MEM_ALREADY_FREE
• Arrêter le code : 0x60B
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Paramètre Size incorrect pour l’opération VirtualFree (MEM_RELEASE).

Cet arrêt est généré si le vérificateur d’application détecte un VirtualFree (MEM_RELEASE) avec une valeur non nulle pour le paramètre dwSize. Lorsque vous utilisez MEM_RELEASE, la seule valeur acceptable pour ce paramètre est 0. Si VirtualFree est appelé avec n’importe quelle autre valeur, à l’exception de 0, VirtualFree ne libère pas la mémoire. Pour déboguer cet arrêt, examinez la trace de pile actuelle (kb) : l’appelant de VirtualFree est probablement le coupable.

• Paramètre 1 -Taille  incorrecte utilisée par l’application.
• Paramètre 2 -Taille  correcte attendue (0).
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : INVALID_FREE_SIZE
• Arrêter le code : 0x60C
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Exception inattendue levée dans la routine de point d’entrée DLL.

Cet arrêt est généré si la fonction de point d’entrée (DllMain) d’une DLL déclenche une exception. Voici un exemple de problème : si DllMain(DLL_PROCESS_ATTACH) déclenche une exception, le chargeur de DLL Windows va : - Intercepter et masquer l’exception ; - Déchargez la DLL sans appeler son DllMain(DLL_PROCESS_DETACH). Ainsi, dans de nombreux cas, la DLL a déjà alloué certaines ressources, puis elle a déclenché l’exception, et elle n’aura pas la possibilité de libérer ces ressources sur DllMain (DLL_PROCESS_DETACH). Pour déboguer cet arrêt :

• Paramètre 1 - Nom de la DLL (utilisez du pour le vider).
• Paramètre 2 -Enregistrement d’exception . Utilisez .exr pour l’afficher.
• Paramètre 3 - Enregistrement de contexte. Utilisez .cxr pour l’afficher.
• Paramètre 4 - Vérificateur de descripteur dll

• Couche de test : Mémoire
• ID d’arrêt : DLL_UNEXPECTED_EXCEPTION
• Arrêter le code : 0x60D
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Exception inattendue déclenchée dans la fonction thread.

Cet arrêt est généré si une fonction de thread déclenche une exception. C’est mauvais parce que tout le processus sera tué. Pour déboguer cet arrêt :

• < parameter1> peut être significatif pour le type d’exception. Par exemple, un code d’exception C0000005 signifie violation d’accès.
• .exr <parameter2> : pour afficher les informations d’exception.
• .cxr <parameter3> suivi de kb - pour afficher les informations de contexte d’exception

• Paramètre 1 -Code d’exception .
• Paramètre 2 -Enregistrement d’exception . Utilisez .exr pour l’afficher.
• Paramètre 3 - Enregistrement de contexte. Utilisez .cxr pour l’afficher.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : THREAD_UNEXPECTED_EXCEPTION
• Arrêter le code : 0x60E
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Exception inattendue levée lors de la détection de la mémoire.

Cet arrêt est généré si nous obtenons une exception pendant un appel IsBadXXXPtr. Cela signifie que la mémoire tampon que nous examinons n’a pas réellement la protection supposée par l’appelant, ou que la mémoire a déjà été libérée, etc. Consultez la discussion ci-dessus sur d’autres codes d’arrêt (PROBE_INVALID_ADDRESS, PROBE_FREE_MEM, PROBE_GUARD_PAGE, PROBE_NULL, PROBE_INVALID_START_OR_SIZE) pour obtenir d’autres exemples de pourquoi l’utilisation des API IsBadXXXPtr n’est pas recommandée. Pour déboguer cet arrêt :

• < parameter1> est généralement C0000005, une violation d’accès
• .exr <parameter2> : pour afficher les informations d’exception
• .cxr <parameter3> suivi de kb - pour afficher les informations de contexte d’exception et la trace de pile au moment où l’exception a été levée

• Paramètre 1 -Code d’exception .
• Paramètre 2 -Enregistrement d’exception . Utilisez .exr pour l’afficher.
• Paramètre 3 - Enregistrement de contexte. Utilisez .cxr pour l’afficher.
• Paramètre 4 - Non utilisé

• Couche de test : Mémoire
• ID d’arrêt : PROBE_UNEXPECTED_EXCEPTION
• Arrêter le code : 0x60F
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Essayez de réinitialiser l’adresse NULL.

Cet arrêt est généré si le vérificateur d’application détecte un appel VirtualFree (MEM_RESET) avec un premier paramètre NULL. MEM_RESET ne doit être utilisé que pour la mémoire déjà allouée. La valeur NULL n’est donc pas un premier paramètre valide dans ce cas.

• paramètre 1 - Non utilisé.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : INVALID_MEM_RESET
• Arrêter le code : 0x610
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Libérer le bloc de mémoire du tas à l’intérieur de la plage d’adresses de la pile du thread actuel.

Cet arrêt est généré si le vérificateur d’application détecte un heapFree, pour un bloc de mémoire qui fait réellement partie de la pile du thread actuel ( !). Pour déboguer cet arrêt, examinez la trace de pile actuelle (ko) et essayez de comprendre pourquoi la fonction appelée HeapFree pensait que le bloc de mémoire a été alloué dynamiquement ou mappé, mais qu’il s’agissait réellement de la mémoire allouée à partir de la pile.

• Paramètre 1 - Adresse de base d’allocation.
• Paramètre 2 -Taille  de la région de mémoire.
• Paramètre 3 - Stack low limit address.
• Paramètre 4 - Stack high limit address.

• Couche de test : Mémoire
• ID d’arrêt : FREE_THREAD_STACK_MEMORY_AS_HEAP
• Arrêter le code : 0x612
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Annuler le mappage de la région de mémoire à l’intérieur de la plage d’adresses de la pile du thread actuel.

Cet arrêt est généré si le vérificateur d’application détecte un UnmapViewOfFile, pour un bloc de mémoire qui fait réellement partie de la pile du thread actuel ( !). Pour déboguer cet arrêt, examinez la trace de pile actuelle (kb) et essayez de comprendre pourquoi la fonction appelée UnmapViewOfFile pensait que le bloc de mémoire a été alloué dynamiquement ou mappé, mais qu’il s’agissait réellement de la mémoire allouée à partir de la pile.

• Paramètre 1 - Adresse de base d’allocation.
• Paramètre 2 -Taille  de la région de mémoire.
• Paramètre 3 - Stack low limit address.
• Paramètre 4 - Stack high limit address.

• Couche de test : Mémoire
• ID d’arrêt : FREE_THREAD_STACK_MEMORY_AS_MAP
• Arrêter le code : 0x613
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Adresse RTL_RESOURCE incorrecte.

Cet arrêt est généré si l’application tente d’utiliser NULL ou une autre adresse incorrecte (par exemple, une adresse en mode noyau) comme adresse d’un objet valide. RtlInitializeResource (NULL) est un appel d’API incorrect qui déclenchera ce type d’arrêt du vérificateur. *Parameter1* est l’adresse incorrecte utilisée et le coupable se trouve sur la trace de la pile (affichez-la avec kb).

• Paramètre 1 - Adresse.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : INVALID_RESOURCE_ADDRESS
• Arrêter le code : 0x614
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Adresse de section critique non valide.

Cet arrêt est généré si l’application tente d’utiliser NULL ou une autre adresse incorrecte (par exemple, une adresse en mode noyau) comme adresse d’un objet valide. EnterCriticalSection(NULL) est un appel d’API incorrect qui déclenchera ce type d’arrêt du vérificateur. *Parameter1* est l’adresse incorrecte utilisée et le coupable se trouve sur la trace de la pile (affichez-la avec kb).

• Paramètre 1 - Adresse.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : INVALID_CRITSECT_ADDRESS
• Arrêter le code : 0x615
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Essayez d’exécuter du code en mémoire non exécutable.

Cet arrêt est généré si l’application tente d’exécuter du code à partir d’une adresse qui n’est pas exécutable ou gratuite. Pour déboguer cet arrêt :

• u <parameter2> - pour désassembler le code coupable
• .exr <parameter3> : pour afficher les informations d’exception
• Paramètre .cxr4>< suivi de kb pour afficher les informations de contexte d’exception et la trace de pile pour l’heure à laquelle l’exception a été levée.

• Paramètre 1 - Adresse accessible.
• Paramètre 2 - Code effectuant un accès non valide.
• Paramètre 3 -Enregistrement d’exception . Utilisez .exr pour l’afficher.
• Paramètre 4 - Enregistrement de contexte. Utilisez .cxr pour l’afficher.

• Couche de test : Mémoire
• ID d’arrêt : THREAD_UNEXPECTED_EXCEPTION_CODE
• Arrêter le code : 0x616
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Exception inattendue levée lors de l’initialisation de la mémoire tampon de sortie.

Cet arrêt est généré si nous obtenons une exception lors de l’initialisation d’une mémoire tampon spécifiée comme paramètre de sortie pour une API Win32 ou CRT. Cela signifie généralement que la taille de mémoire tampon de sortie spécifiée est incorrecte. Pour déboguer cet arrêt :

• .exr <parameter3> : pour afficher les informations d’exception.
• Paramètre .cxr4>< suivi de kb pour afficher les informations de contexte d’exception et la trace de pile au moment où l’exception a été levée.

• Paramètre 1 - Adresse de début de la mémoire tampon.
• Paramètre 2 -Taille  de la mémoire tampon.
• Paramètre 3 -Enregistrement d’exception . Utilisez .exr pour l’afficher.
• Paramètre 4 - Enregistrement de contexte. Utilisez .cxr pour l’afficher.

• Couche de test : Mémoire
• ID d’arrêt : OUTBUFF_UNEXPECTED_EXCEPTION
• Arrêter le code : 0x617
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Exception inattendue lors de la tentative de recherche de la taille du bloc de tas.

Cet arrêt est généré si nous obtenons une exception lors de l’appel de tasSize pour un bloc de tas libéré. Cela signifie généralement que l’adresse de bloc de tas spécifiée est incorrecte ou que le tas est endommagé. Pour déboguer cet arrêt :

• .exr <parameter3> : pour afficher l’enregistrement d’exception.
• Paramètre .cxr4>< suivi de kb pour afficher les informations de contexte d’exception et la trace de pile au moment où l’exception a été levée.

• Paramètre 1 - Adresse du bloc de tas libéré.
• Paramètre 2 - Handle de tas.
• Paramètre 3 -Enregistrement d’exception . Utilisez .exr pour l’afficher.
• Paramètre 4 - Enregistrement de contexte. Utilisez .cxr pour l’afficher.

• Couche de test : Mémoire
• ID d’arrêt : SIZE_HEAP_UNEXPECTED_EXCEPTION
• Arrêter le code : 0x618
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Libérer un bloc de mémoire avec une adresse de début non valide.

Cet arrêt est généré si le programme appelle VirtualFree (MEM_RELEASE) avec un paramètre lpAddress qui n’est pas l’adresse de base retournée par la fonction VirtualAlloc ou VirtualAllocEx lorsque la région des pages a été réservée ; Pour déboguer cet arrêt :

• kb : pour afficher la trace de pile actuelle, qui appelle VirtualFree. Le coupable probable est la DLL qui appelle VirtualFree.

• Paramètre 1 - Adresse du bloc de mémoire libéré.
• Paramètre 2 - Adresse de bloc de mémoire correcte attendue.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : INVALID_FREEMEM_START_ADDRESS
• Arrêter le code : 0x619
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Annuler le mappage du bloc de mémoire avec une adresse de début non valide.

Cet arrêt est généré si le programme appelle UnmapViewOfFile avec un paramètre lpBaseAddress qui n’est pas identique à la valeur retournée par un appel précédent à la fonction MapViewOfFile ou MapViewOfFileEx. Pour déboguer cet arrêt :

• kb : pour afficher la trace de pile actuelle, qui appelle UnmapViewOfFile. Le coupable probable est la DLL qui appelle UnmapViewOfFile.

• Paramètre 1 - Adresse du bloc de mémoire non mappé.
• Paramètre 2 - Adresse de bloc de mémoire correcte attendue.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : INVALID_UNMAPVIEW_START_ADDRESS
• Arrêter le code : 0x619
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

exception inattendue déclenchée dans la fonction de rappel de threadpool.

Cet arrêt est généré si une fonction de rappel dans le thread de thread déclenche une exception. Pour déboguer cet arrêt :

• < parameter1> peut être significatif pour le type d’exception. Par exemple, un code d’exception C0000005 signifie violation d’accès.
• .exr <parameter2> : pour afficher les informations d’exception.
• Paramètre .cxr3>< suivi de kb pour afficher les informations de contexte d’exception.

• Paramètre 1 -Code d’exception 
• Paramètre 2 -Enregistrement d’exception . Utiliser .exr pour l’afficher
• Paramètre 3 - Enregistrement de contexte. Utiliser .cxr pour l’afficher
• Paramètre 4 - Non utilisé

• Couche de test : Mémoire
• ID d’arrêt : THREADPOOL_UNEXPECTED_EXCEPTION
• Arrêter le code : 0x61B
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

code dans la mémoire non exécutable

Cet arrêt est généré si l’application tente d’exécuter du code à partir d’une adresse qui n’est pas exécutable ou gratuite. Pour déboguer cet arrêt :

• u <parameter2> - pour désassembler le code coupable
• .exr <parameter3> : pour afficher les informations d’exception
• Paramètre .cxr4>< suivi de kb pour afficher les informations de contexte d’exception et la trace de pile pour l’heure à laquelle l’exception a été levée.

• Paramètre 1 - Adresse accessible
• Paramètre 2 - Code effectuant un accès non valide
• Paramètre 3 -Enregistrement d’exception . Utilisez .exr pour l’afficher.
• Paramètre 4 - Enregistrement de contexte. Utilisez .cxr pour l’afficher.

• Couche de test : Mémoire
• ID d’arrêt : THREADPOOL_UNEXPECTED_EXCEPTION_CODE
• Arrêter le code : 0x61C
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Création d’un tas exécutable.

Cet arrêt est généré si l’application crée un tas exécutable. Il peut s’agir d’un risque de sécurité.

• paramètre 1 - Non utilisé.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : EXECUTABLE_HEAP
• Arrêter le code : 0x1D
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Allocation de mémoire exécutable.

Cet arrêt est généré si l’application alloue de la mémoire exécutable. Il peut s’agir d’un risque de sécurité.

• Paramètre 1 - Protection de page spécifiée par l’appelant.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Mémoire
• ID d’arrêt : EXECUTABLE_MEMORY
• Arrêter le code : 0x1E
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Détails de l’arrêt TLS

Déchargement de DLL qui a alloué l’index TLS qui n’a pas été libéré.

Cet arrêt est généré si une DLL qui a alloué un index TLS est déchargée avant de libérer cet index TLS. Pour déboguer cet arrêt :

• du <parameter3> - afficher le nom de la DLL coupable
• .reload xxx.dll=<parameter4> : rechargez les symboles de la DLL coupable (si nécessaire). xxx.dll est le nom de la DLL affichée à l’étape ci-dessus.
• u <parameter2> : désassemblez le code qui a alloué le protocole TLS. Cela doit pointer vers la fonction qui a alloué le protocole TLS, mais elle a oublié de le libérer avant que la DLL ne soit déchargée.

• Paramètre 1 -Index  TLS
• Paramètre 2 - Adresse du code qui a alloué cet index TLS.
• Paramètre 3 - Adresse du nom de la DLL. Utilisez du pour la vider.
• Paramètre 4 - Adresse de base DLL.

• Couche de test : TLS
• ID d’arrêt : TLS_LEAK
• Arrêter le code : 0x350
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Structure TLS du vérificateur endommagé.

Cet arrêt est généré si les structures de vérificateur interne utilisées pour stocker l’état des emplacements TLS pour le thread sont endommagées. Il est très probable qu’il s’agit d’une corruption aléatoire dans le processus.

• Paramètre 1 - ADRESSE TEB.
• Paramètre 2 - Adresse TEB attendue.
• Paramètre 3 - ID de thread.
• Paramètre 4 - ID de thread attendu.

• Couche de test : TLS
• ID d’arrêt : CORRUPTED_TLS
• Arrêter le code : 0x351
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Utilisation d’un index TLS non valide.

Cet arrêt est généré si un index TLS non valide est utilisé. Dans la plupart des cas, c’est parce que le code utilise toujours cet index lorsque TlsFree est appelé. Voici un exemple pour le thread de thread de thread.

• T1 : Chargements de dll et TlsAlloc
• T1 : Rappel de file d’attente
• T1 : Rappel attendu/annulé ignoré
• T1 : TlsFree
• T2 : Callback s’exécute et appelle TlsSetValue
• T1 : Déchargements de dll

• Paramètre 1 -Index  TLS
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : TLS
• ID d’arrêt : INVALID_TLS_INDEX
• Arrêter le code : 0x352
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Détails de l’arrêt du threadpool

La priorité de ce thread de thread a été modifiée.

Cet arrêt est généré si la priorité du thread est modifiée lorsqu’elle est retournée au threadpool.

• Format: -  Threadpool thread (%x) ayant exécuté le rappel (%p) a une priorité de thread modifiée (%i -> %i)
• Paramètre 1 - Callback, fonction.
• Paramètre 2 - Context.
• Paramètre 3 - Trace de pile d’allocation d’objets Threadpool, utilisez dps pour la vider.
• Paramètre 4 - Priorité actuelle.

• Couche de test : Threadpool
• ID d’arrêt : INCONSISTENT_PRIORITY
• Arrêter le code : 0x700
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

L’affinité de ce thread de thread a été modifiée.

Cet arrêt est généré si l’affinité de thread est modifiée lorsqu’elle est retournée au threadpool.

• Format: - threadpool thread (%x) ayant exécuté le rappel (%p) a un masque d’affinité de thread modifié (%p -> %p)
• Paramètre 1 - Callback, fonction.
• Paramètre 2 - Context.
• Paramètre 3 - Trace de pile d’allocation d’objets Threadpool, utilisez dps pour la vider.
• Paramètre 4 - Affinité actuelle.

• Couche de test : Threadpool
• ID d’arrêt : INCONSISTENT_AFFINITY_MASK
• Arrêter le code : 0x701
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Msg non traité dans le pool msg du thread actuel.

Cet arrêt est généré si un message n’est pas traité lorsque ce thread de thread est retourné au pool. C’est dangereux, car il sera traité dans un contexte totalement différent. Utilisez !avrf -tp <Param4> pour afficher les messages publiés sur ce thread.

• Format: - threadpool thread (%x) ayant exécuté le rappel (%p) a un message de fenêtre en attente (%x: %x)
• Paramètre 1 - Callback, fonction.
• Paramètre 2 - Context.
• Paramètre 3 - Trace de pile d’allocation d’objets Threadpool, utilisez dps pour la vider.
• Paramètre 4 - Threadpool thread ID. Utilisez !avrf -tp <threadid> pour voir les messages publiés sur ce thread.

• Couche de test : Threadpool
• ID d’arrêt : ORPHANED_THREAD_MESSAGE
• Arrêter le code : 0x702
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

La fenêtre non fermée appartient au thread actuel.

Cet arrêt est généré si une fenêtre est conservée en vie lorsque ce thread de thread est retourné au pool.

• Format: -  threadpool thread (%x) ayant exécuté le rappel (%p) a un hwnd valide (%x: %s) qui peut recevoir des messages
• Paramètre 1 - Callback, fonction.
• Paramètre 2 - Context.
• Paramètre 3 - Trace de pile d’allocation d’objets Threadpool, utilisez dps pour la vider.
• Paramètre 4 - Threadpool thread ID.

• Couche de test : Threadpool
• ID d’arrêt : ORPHANED_THREAD_WINDOW
• Arrêter le code : 0x703
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

ExitThread() ou TerminateThread() sur un thread de thread.

Cet arrêt est généré si ExitThread est appelé sur un thread threadpool. Il est interdit, car il rend le système instable. Cela entraîne une fuite de ressources, un gel ou une av.

• Paramètre 1 - Callback, fonction.
• Paramètre 2 - Context.
• Paramètre 3 - Trace de pile d’allocation d’objets Threadpool, utilisez dps pour la vider.
• Paramètre 4 - Non utilisé.

• Couche de test : Threadpool
• ID d’arrêt : ILLEGAL_THREAD_TERMINATION
• Arrêter le code : 0x704
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Le thread est dans un état d’emprunt d’identité lorsqu’il est retourné à un thread de threadpool.

Cet arrêt est généré si la fonction de rappel modifie le jeton de thread pour emprunter l’identité d’un autre utilisateur et a oublié de le réinitialiser avant de le renvoyer au threadpool.

• Paramètre 1 - Callback, fonction.
• Paramètre 2 - Context.
• Paramètre 3 - Trace de pile d’allocation d’objets Threadpool, utilisez dps pour la vider.
• Paramètre 4 - Non utilisé.

• Couche de test : Threadpool
• ID d’arrêt : THREAD_IN_IMPERSONATION
• Arrêter le code : 0x705
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Une fonction qui nécessite un thread persistant est appelée.

Certaines API Microsoft Windows doivent être appelées à l’intérieur d’un thread dédié ou persistant. Dans le threadpool, vous devez généralement éviter d’utiliser le stockage local de threads et la mise en file d’attente des appels asynchrones qui nécessitent un thread persistant, tel que la fonction RegNotifyChangeKeyValue. Toutefois, ces fonctions peuvent être mises en file d’attente vers un thread de travail persistant à l’aide de QueueUserWorkItem avec l’option WT_EXECUTEINPERSISTENTTHREAD. Une base de connaissances dans le débogueur révélera l’appelant.

• Paramètre 1 - Callback, fonction.
• Paramètre 2 - Context.
• Paramètre 3 - Trace de pile d’allocation d’objets Threadpool, utilisez dps pour la vider.
• Paramètre 4 - Non utilisé.

• Couche de test : Threadpool
• ID d’arrêt : PERSISTED_THREAD_NEEDED
• Arrêter le code : 0x706
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Le thread est dans un état de transaction incorrect.

Cet arrêt est généré si la fonction de rappel a oublié de fermer ou de réinitialiser le handle de transaction actuel.

• Paramètre 1 - Callback, fonction.
• Paramètre 2 - Context.
• Paramètre 3 - Trace de pile d’allocation d’objets Threadpool, utilisez dps pour la vider.
• Paramètre 4 - Handle de transaction.

• Couche de test : Threadpool
• ID d’arrêt : DIRTY_TRANSACTION_CONTEXT
• Arrêter le code : 0x707
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Cet état de threadpool a des appels CoInit et CoUnInit déséquilibrés.

Cet arrêt est généré si la fonction de rappel appelle CoInit et CoUnInit non déséquilibré.

• Paramètre 1 - Callback, fonction.
• Paramètre 2 - Context.
• Paramètre 3 - Trace de pile d’allocation d’objets Threadpool, utilisez dps pour la vider.
• Paramètre 4 -Nombre  d’appels équilibrés.

• Couche de test : Threadpool
• ID d’arrêt : DIRTY_COM_STATE
• Arrêter le code : 0x708
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Les paramètres de l’objet minuteur sont incohérents. La période doit être 0 lorsque WT_EXECUTEONLYONCE est spécifiée lors de la création du minuteur

Cet arrêt est généré si la période pour signaler que le minuteur n’est pas égal à zéro lorsque le minuteur n’est défini qu’une seule fois avec l’indicateur de WT_EXECUTEONLYONCE

• Paramètre 1 - Période spécifiée.
• Paramètre 2 - Indicateurs spécifiés.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Threadpool
• ID d’arrêt : INCONSISTENT_TIMER_PARAMS
• Arrêter le code : 0x709
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Le verrou du chargeur a été conservé par le thread de threadpool dans le rappel.

Cet arrêt est généré si le verrou du chargeur est conservé dans le rappel et n’est pas libéré lorsque le thread est retourné au threadpool.

• Paramètre 1 - Callback, fonction.
• Paramètre 2 - Context.
• Paramètre 3 - Trace de pile d’allocation d’objets Threadpool, utilisez dps pour la vider.
• Paramètre 4 - Non utilisé.

• Couche de test : Threadpool
• ID d’arrêt : LOADER_LOCK_HELD
• Arrêter le code : 0x7A
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Le langage préféré est défini par le thread de thread de thread dans le rappel.

Cet arrêt est généré si la langue préférée est définie dans le rappel et n’est pas effacée lorsque le thread est retourné au threadpool.

• Paramètre 1 - Callback, fonction.
• Paramètre 2 - Context.
• Paramètre 3 - Trace de pile d’allocation d’objets Threadpool, utilisez dps pour la vider.
• Paramètre 4 - Non utilisé.

• Couche de test : Threadpool
• ID d’arrêt : PREFERRED_LANGUAGES_SET
• Arrêter le code : 0x7B
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

La priorité d’arrière-plan est définie par le thread de thread de thread dans le rappel.

Cet arrêt est généré si la priorité en arrière-plan est définie dans le rappel et n’est pas désactivée lorsque le thread est retourné au threadpool.

• Paramètre 1 - Callback, fonction.
• Paramètre 2 - Context.
• Paramètre 3 - Trace de pile d’allocation d’objets Threadpool, utilisez dps pour la vider.
• Paramètre 4 - Non utilisé.

• Couche de test : Threadpool
• ID d’arrêt : BACKGROUND_PRIORITY_SET
• Arrêter le code : 0x7C
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

TerminateThread() sur un thread de thread.

Cet arrêt est généré si TerminateThread est appelé sur un thread de threadpool. Il est interdit, car il rend le système instable. Cela entraîne une fuite de ressources, un gel ou une av.

• Paramètre 1 - Non utilisé.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Threadpool
• ID d’arrêt : ILLEGAL_THREAD_TERMINATION
• Arrêter le code : 0x7D
• gravité : erreur 
• erreur unique : 
• rapport d’erreurs : arrêt de 
• Fichier journal : oui
• Créer un backtrace : oui

Voir aussi

Vérificateur d’application - Codes d’arrêt et définitions

Application Verifier - Vue d’ensemble

vérificateur d’applications - Fonctionnalités

vérificateur d’applications - Test des applications

Application Verifier - Tests au sein du vérificateur d’application

Vérificateur d’applications - Débogage de l’vérificateur d’application s’arrête

Application Verifier - Forum aux questions