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

Les codes d’arrêt suivants sont inclus dans l’ensemble de tests de base.

Détails des arrêts d’exception

Tentative d’exécution de code dans une mémoire non exécutable (première chance).

Cause probable

Cet arrêt est généré si l’application tente d’exécuter du code à partir d’une adresse non exécutable ou libre. Pour déboguer cet arrêt : $ u parameter2 - pour désassembler le code incriminé $ .exr parameter3 - pour afficher les informations d’exception ; $ .cxr parameter4 suivi de kb - pour afficher les informations de contexte de l’exception et la trace de la pile au moment où l’exception a été levée.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Exceptions
• ID d’arrêt : FIRST_CHANCE_ACCESS_VIOLATION_CODE
• Code d’arrêt : 650NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Détails des arrêts de handles

Exception de handle invalide pour la trace d’appels actuelle.

Cause probable

Cet arrêt est généré si la fonction en haut de la pile a passé un handle invalide aux routines système. Habituellement, une simple commande kb révélera la valeur du handle passé (doit être l’un des paramètres - généralement le premier). Si la valeur est nulle, c’est clairement incorrect. Si la valeur semble correcte, vous devez utiliser l’extension du débogueur !htrace pour obtenir un historique des opérations relatives à cette valeur de handle. Dans la plupart des cas, il doit s’agir d’une valeur de handle utilisée après sa fermeture.

Informations affichées par Application Verifier

• 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é.

Informations supplémentaires

• Couche de test : Handles
• ID d’arrêt : INVALID_HANDLE
• Code d’arrêt : 300NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Indice TLS invalide utilisé pour la trace de pile actuelle.

Cause probable

Cet arrêt est généré si la fonction en haut de la pile a passé un indice TLS invalide aux routines système TLS. Habituellement, une simple commande kb révélera ce qui ne va pas. Le bug typique ici est de supposer une certaine valeur pour un indice TLS au lieu d’appeler TlsAlloc. Paramètres invalides pour l’appel de WaitForMultipleObjects.

Informations affichées par Application Verifier

• 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é.

Informations supplémentaires

• Couche de test : Handles
• ID d’arrêt : INVALID_TLS_VALUE
• Code d’arrêt : 300NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Paramètres invalides pour l’appel de WaitForMultipleObjects.

Cause probable

Cet arrêt est généré si la fonction en haut de la pile a appelé WaitForMultipleObjects avec NULL comme adresse du tableau de handles à attendre ou avec zéro comme nombre de handles. Une simple commande kb révélera la fonction appelant cette API incorrectement.

Informations affichées par Application Verifier

• Paramètre 1 - Adresse du vecteur des handles d’objet.
• Paramètre 2 - Nombre de handles.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

Informations supplémentaires

• Couche de test : Handles
• ID d’arrêt : INCORRECT_WAIT_CALL
• Code d’arrêt : 300NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

Cet arrêt est généré si la fonction en haut de la pile a passé un handle NULL aux routines système.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Handles
• ID d’arrêt : NULL_HANDLE
• Code d’arrêt : 300NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Attente sur un handle de thread dans DllMain.

Cause probable

Cet arrêt est généré si le thread actuel exécute du code dans la fonction DllMain de l’une des DLLs chargées dans le processus actuel et appelle WaitForSingleObject ou WaitForMultipleObjects pour attendre sur un handle de thread dans le même processus. Cela conduirait probablement à un blocage car le handle du thread ne sera pas signalé à moins que ce deuxième thread ne se termine. Lorsque le deuxième thread appelle ExitThread, il essaiera d’acquérir le verrou de chargement de la DLL, puis d’appeler DllMain (DLL_THREAD_DETACH) pour toutes les DLLs dans le processus actuel. Mais le verrou de chargement est détenu par le premier thread (celui qui attend sur le handle du thread) donc les deux threads seront bloqués.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Handles
• ID d’arrêt : WAIT_IN_DLLMAIN
• Code d’arrêt : 300NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Type d’objet incorrect pour le handle.

Cause probable

Cet arrêt est généré si le thread actuel appelle une API avec un handle vers un objet de type incorrect. Par exemple, appeler SetEvent avec un handle de sémaphore en paramètre générera cet arrêt. Pour déboguer cet arrêt : $ kb - pour afficher la trace de la 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 du handle est parameter1. Dans l’exemple ci-dessus, cela affichera : Semaphore. $ du parameter3 - pour afficher le type d’objet attendu par l’API. Dans l’exemple ci-dessus, ce nom sera : Event. $ !htrace parameter1 peut être utile car il affichera la trace de la pile pour les opérations récentes d’ouverture/fermeture sur ce handle.

Informations affichées par Application Verifier

• Paramètre 1 - Valeur du handle.
• Paramètre 2 - Nom du type d’objet. Utilisez du pour l’afficher.
• Paramètre 3 - Nom du type d’objet attendu. Utilisez du pour l’afficher.
• Paramètre 4 - Non utilisé.

Informations supplémentaires

• Couche de test : Handles
• ID d’arrêt : INCORRECT_OBJECT_TYPE
• Code d’arrêt : 300NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Détails des arrêts des tas

Erreur inconnue.

Cause probable

Ce message peut apparaître si l’erreur rencontrée ne peut être classée d’aucune autre manière. Non utilisé pour l’instant.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : UNKNOWN_ERROR
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Exception de violation d’accès.

Cause probable

C’est l’arrêt le plus courant d’application verifier. Il est généralement causé par une erreur de dépassement de tampon. Le vérificateur de tas place une page non accessible à la fin d’une allocation de tas et un dépassement de tampon causera une exception en touchant cette page. Pour déboguer cet arrêt, identifiez l’adresse d’accès qui a causé l’exception, puis utilisez la commande de débogueur suivante : !heap -p -a ACCESS_ADDRESS Cette commande donnera des détails sur la nature de l’erreur et sur quel bloc de tas est dépassé. Elle donnera également la trace de la pile pour l’allocation du bloc. Il y a plusieurs autres causes pour cet arrêt. Par exemple, accéder à un bloc de tas après l’avoir libéré. La même commande de débogueur sera utile pour ce cas aussi.

Informations affichées par Application Verifier

• Paramètre 1 - Adresse invalide causant l’exception.
• Paramètre 2 - Adresse du code exécutant l’accès invalide.
• Paramètre 3 - Enregistrement d’exception
• Paramètre 4 - Enregistrement de contexte

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : ACCESS_VIOLATION
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

Un tas créé avec le flag HEAP_NO_SERIALIZE n’est pas censé être accédé simultanément à partir de deux threads. Si une telle situation est détectée, vous recevrez ce message. La manière typique dont cette situation se glisse dans un programme est de se lier à une version single-threaded de la bibliothèque C-runtime. Visual C++ peut par exemple lier statiquement une telle bibliothèque lorsque des flags appropriés sont utilisés. Ensuite, les gens oublient ce détail et utilisent plusieurs threads. Le bug est très difficile à déboguer en réalité car il se manifestera sous forme de corruptions de données mystérieuses.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : UNSYNCHRONIZED_ACCESS
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Demande de taille extrême.

Cause probable

Ce message sera généré si dans une opération HeapAlloc() ou HeapReAlloc() la taille du bloc est au-dessus de toute valeur raisonnable. En règle générale, cette valeur est 0x80000000 sur les plateformes 32 bits et significativement plus grande sur les plateformes 64 bits.

Informations affichées par Application Verifier

• 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é

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : EXTREME_SIZE_REQUEST
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Handle de tas avec une signature incorrecte.

Cause probable

Les structures de tas sont marquées avec une valeur magique. Si le handle de tas utilisé dans l’appel à une interface de tas n’a pas ce motif, alors cet arrêt sera généré. Ce bug peut se produire si la structure interne du tas est corrompue (corruption aléatoire) ou simplement si une valeur fausse est utilisée comme handle de tas. Pour obtenir une liste des valeurs de handle de tas valides, utilisez les commandes de débogueur suivantes : !heap -p Notez que si vous changez simplement un handle de tas valide par un autre valide dans une opération de tas, vous n’obtiendrez pas cet arrêt (le handle semble valide après tout). Cependant, le vérificateur de tas détecte cette situation et la signale avec l’arrêt SWITCHED_HEAP_HANDLE.

Informations affichées par Application Verifier

• 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é

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : BAD_HEAP_HANDLE
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Pointeur de tas corrompu ou utilisation du mauvais tas.

Cause probable

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

Informations affichées par Application Verifier

• 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é.

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : SWITCHED_HEAP_HANDLE
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

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 de libération différée. Si un programme bogué tente de libérer le bloc à nouveau, cela sera détecté à condition que le bloc n’ait pas été retiré de la file d’attente de libération différée et que sa mémoire n’ait pas été réutilisée pour d’autres allocations. La profondeur de la file d’attente de libération différée est de l’ordre de milliers de blocs, il y a donc de bonnes chances que la plupart des doubles libérations soient détectées.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : DOUBLE_FREE
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Bloc de tas corrompu.

Cause probable

Ceci est une erreur générique émise si la corruption dans le bloc de tas ne peut être placée dans une catégorie plus spécifique.

Informations affichées par Application Verifier

• 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é

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : CORRUPTED_HEAP_BLOCK
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Tentative de destruction du tas de processus.

Cause probable

C’est une erreur de tenter de détruire le tas de processus par défaut (celui retourné par l’interface GetProcessHeap()).

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : DESTROY_PROCESS_HEAP
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Exception inattendue levée lors de l’exécution du code de gestion de tas.

Cause probable

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 levée dans des situations illégitimes. Il y a très peu de 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 trouver le contexte exact de l’exception. Utilisez les commandes de débogueur suivantes pour cela : $ .exr STOP-PARAMETER-2 $ .cxr STOP-PARAMETER-3 Habituellement, cet arrêt peut se produire s’il y a une corruption aléatoire dans les structures internes du tas.

Informations affichées par Application Verifier

• 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)

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : UNEXPECTED_EXCEPTION
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

Cette situation se produit si nous ne pouvons vraiment déterminer aucun type particulier de corruption pour le bloc. Très probablement, cet arrêt se produira lorsque l’adresse de bloc de tas passée à une libération de tas pointe vers une zone mémoire non accessible (pointeur corrompu, pointeur non initialisé, etc.).

Informations affichées par Application Verifier

• Paramètre 1 - Handle de tas pour le tas possédant le bloc.
• Paramètre 2 - Bloc de tas qui est corrompu.
• Paramètre 3 - Taille du bloc ou zéro si la taille ne peut être déterminée.
• Paramètre 4 - Non utilisé.

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_EXCEPTION_RAISED_FOR_HEADER
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

Cette situation se produit si nous ne pouvons vraiment déterminer aucun type particulier de corruption pour le bloc. Par exemple, vous obtiendrez cela si, lors d’une opération de libération de tas, vous passez une adresse qui pointe vers une zone mémoire non accessible. Cela peut également se produire pour des situations de double libération si nous ne trouvons pas le bloc parmi les blocs de tas de page complète et nous le sondons comme un bloc de tas de page légère.

Informations affichées par Application Verifier

• 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é.

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_EXCEPTION_RAISED_FOR_PROBING
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

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

Informations affichées par Application Verifier

• Paramètre 1 - Handle de tas pour le tas possédant le bloc.
• Paramètre 2 - Bloc de tas qui est corrompu.
• Paramètre 3 - Taille du bloc ou zéro si la taille ne peut être déterminée.
• Paramètre 4 - Non utilisé.

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_HEADER
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Motif d’infixe corrompu pour bloc de tas libéré.

Cause probable

Les blocs libérés sont parfois marqués non accessibles et un programme les touchant violera l’accès (différent arrêt du vérificateur). Dans d’autres cas (tas de page légère), le bloc est marqué avec un motif magique et sera conservé pendant un certain temps. Finalement, de manière FIFO, les blocs sont vraiment libérés. À ce moment, le motif d’infixe est vérifié et s’il a été modifié, vous recevrez cette interruption. La pile au moment de l’interruption n’est pas pertinente. Vous devez déterminer la nature du bloc et revoir le code qui pourrait être incorrect.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : CORRUPTED_FREED_HEAP_BLOCK
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Motif de suffixe corrompu pour bloc de tas.

Cause probable

Cela se produit le plus souvent pour des erreurs de dépassement de tampon. Parfois, le vérificateur d’application place des pages non accessibles à la fin de l’allocation et les dépassements de tampon provoqueront une violation d’accès et parfois le bloc de tas est suivi par un motif magique. Si ce motif est modifié lorsque le bloc est libéré, vous recevrez cette interruption. Ces interruptions peuvent être assez difficiles à déboguer car vous n’avez pas le moment réel où la corruption s’est produite. Vous avez juste accès au moment de la libération (l’arrêt s’est produit ici) et à la trace de la pile d’allocation (!heap -p -a HEAP_ADDRESS)

Informations affichées par Application Verifier

• 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é.

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_SUFFIX
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Motif de début corrompu pour bloc de tas.

Cause probable

Cela se produit pour des erreurs de dépassement de tampon inverse.

Informations affichées par Application Verifier

• 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 de timbre corrompue.

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_START_STAMP
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Timbre de fin corrompu pour le bloc de tas.

Cause probable

Cela se produit pour des erreurs de dépassement de tampon inverse.

Informations affichées par Application Verifier

• 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 de timbre corrompue.

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_END_STAMP
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Motif de préfixe corrompu pour le bloc de tas.

Cause probable

Cela se produit pour des erreurs de dépassement de tampon inverse.

Informations affichées par Application Verifier

• 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é.

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : CORRUPTED_HEAP_BLOCK_PREFIX
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Violation d’accès au premier essai pour la trace d’appels actuelle.

Cause probable

C’est l’arrêt le plus courant d’application verifier. Il est généralement causé par une erreur de dépassement de tampon. Le vérificateur de tas place une page non accessible à la fin d’une allocation de tas et un dépassement de tampon causera une exception en touchant cette page. Pour déboguer cet arrêt, identifiez l’adresse d’accès qui a causé l’exception, puis utilisez la commande de débogueur suivante : !heap -p -a ACCESS_ADDRESS Cette commande donnera des détails sur la nature de l’erreur et sur quel bloc de tas est dépassé. Elle donnera également la trace de la pile pour l’allocation du bloc. Il y a plusieurs autres causes pour cet arrêt. Par exemple, accéder à un bloc de tas après l’avoir libéré. La même commande de débogueur sera utile pour ce cas aussi.

Informations affichées par Application Verifier

• Paramètre 1 - Adresse invalide causant l’exception.
• Paramètre 2 - Adresse du code exécutant l’accès invalide.
• Paramètre 3 - Enregistrement d’exception.
• Paramètre 4 - Enregistrement de contexte.

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : FIRST_CHANCE_ACCESS_VIOLATION
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Nombre invalide de listes de tas de processus.

Cause probable

Ce message peut apparaître si, lors de l’appel de GetProcessHeaps, le gestionnaire de tas de pages détecte des incohérences internes. Cela peut être causé par une corruption aléatoire dans l’espace du processus.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Heaps
• ID d’arrêt : CORRUPTED_HEAP_LIST
• Code d’arrêt : 0NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Détails des arrêts de fuite

Une allocation de tas a fui.

Cause probable

Cet arrêt est généré si la DLL propriétaire de l’allocation a été déchargée dynamiquement tout en possédant des ressources.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Leak
• ID d’arrêt : ALLOCATION
• Code d’arrêt : 900NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Un HANDLE a fui.

Cause probable

Cet arrêt est généré si la DLL propriétaire du handle a été déchargée dynamiquement tout en possédant des ressources. Pour déboguer cet arrêt : Exécutez !htrace parameter1 pour obtenir des informations supplémentaires sur le handle.

Informations affichées par Application Verifier

• Paramètre 1 - Valeur du handle fuité. Exécutez !htrace <handle> pour obtenir des informations supplémentaires sur le handle si le traçage du handle est activé.
• Paramètre 2 - Adresse de la trace d’allocation. Exécutez dps <address> pour voir la trace d’allocation.
• Paramètre 3 - Adresse du nom de la DLL propriétaire. Exécutez du <address> pour lire le nom de la DLL.
• Paramètre 4 - Base de la DLL propriétaire. Exécutez .reload <dll_name> = <address> pour recharger la DLL propriétaire. Utilisez « lm » pour obtenir plus d’informations sur les modules chargés et déchargés.

Informations supplémentaires

• Couche de test : Leak
• ID d’arrêt : HANDLE
• Code d’arrêt : 900NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Un HKEY a fui.

Cause probable

Cet arrêt est généré si la DLL propriétaire de la clé de registre a été déchargée dynamiquement tout en possédant des ressources.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Leak
• ID d’arrêt : REGISTRY
• Code d’arrêt : 900NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Une réservation virtuelle a fui.

Cause probable

Cet arrêt est généré si la DLL propriétaire de la réservation virtuelle a été déchargée dynamiquement tout en possédant des ressources.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Leak
• ID d’arrêt : VIRTUAL_RESERVATION
• Code d’arrêt : 900NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Un BSTR a fui.

Cause probable

Cet arrêt est généré si la DLL propriétaire du SysString a été déchargée dynamiquement tout en possédant des ressources.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Leak
• ID d’arrêt : SYSSTRING
• Code d’arrêt : 900NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Une notification de puissance n’a pas été annulée.

Cause probable

Cet arrêt est généré si la DLL s’est inscrite pour une notification de puissance et a été déchargée dynamiquement sans se désinscrire.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Leak
• ID d’arrêt : POWER_NOTIFICATION
• Code d’arrêt : 900NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Détails des arrêts de verrouillage

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

Cause probable

Cet arrêt est généré si un thread (l’ID du thread est parameter1) est terminé, suspendu ou est dans un état (le thread de travail a terminé un élément de travail) dans lequel il ne peut pas détenir de section critique. Le thread actuel est le coupable. Pour déboguer cet arrêt, utilisez les commandes de débogage suivantes : $ kb - pour obtenir la trace d’appels actuelle. Si le thread actuel est le propriétaire de la section critique, il appelle probablement ExitThread. Le thread actuel aurait dû libérer la section critique avant de sortir. Si le thread actuel appelle TerminateThread ou SuspendThread, il ne devrait pas le faire pour un thread détenant une section critique. $ !cs -s parameter2 - vider les informations sur cette section critique. $ ln parameter2 - pour afficher les symboles près de l’adresse de la section critique. Cela devrait aider à identifier la section critique fuitée. $ dps parameter4 - pour vider la trace d’appels pour l’initialisation de cette section critique.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : EXIT_THREAD_OWNS_LOCK
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Déchargement de la DLL contenant une section critique active.

Cause probable

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 la section critique n’a pas été supprimée. Pour déboguer cet arrêt, utilisez les commandes de débogage suivantes : $ du parameter3 - pour vider le nom de la DLL coupable. $ .reload dllname ou .reload dllname = parameter4 - pour recharger les symboles pour cette DLL. $ !cs -s parameter1 - vider les informations sur cette section critique. $ ln parameter1 - pour afficher les symboles près de l’adresse de la section critique. Cela devrait aider à identifier la section critique fuitée. $ dps parameter2 - pour vider la trace d’appels pour l’initialisation de cette section critique.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_IN_UNLOADED_DLL
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Libération d’un bloc de tas contenant une section critique active.

Cause probable

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ébogage suivantes : $ !cs -s parameter1 - vider les informations sur cette section critique. $ ln parameter1 - pour afficher les symboles près de l’adresse de la section critique. Cela devrait aider à identifier la section critique fuitée. $ dps parameter2 - pour vider la trace d’appels pour l’initialisation de cette section critique. $ parameter3 et parameter4 pourraient aider à comprendre où ce bloc de tas a été alloué (la taille de l’allocation est probablement significative).

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_IN_FREED_HEAP
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Double initialisation ou section critique corrompue.

Cause probable

Habituellement, cet arrêt est généré si une section critique a été initialisée plus d’une fois. Dans ce cas, parameter3 et parameter4 sont les adresses de trace d’appels pour deux de ces initialisations. Parfois, il est possible d’obtenir cet arrêt si la section critique ou sa structure d’informations de débogage a été corrompue. Dans ce deuxième cas, il est possible que parameter3 et parameter4 soient invalides et inutiles. Pour déboguer cet arrêt : $ !cs -s -d parameter2 - vider les informations sur cette section critique. $ ln parameter1 - pour afficher les symboles près de l’adresse de la section critique. Cela pourrait aider à identifier la section critique si c’est une variable globale. $ dps parameter3 et dps parameter4 - pour identifier les deux chemins de code pour l’initialisation de cette section critique.

Informations affichées par Application Verifier

• Paramètre 1 - Adresse de la 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 d’initialisation.
• Paramètre 4 - Deuxième trace d’initialisation.

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_DOUBLE_INITIALIZE
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Mémoire libre contenant une section critique active.

Cause probable

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 en utilisant DeleteCriticalSection. Pour déboguer cet arrêt, utilisez les commandes de débogage suivantes : $ !cs -s -d parameter2 - vider les informations sur cette section critique. $ dps parameter3 - pour identifier le chemin de code pour l’initialisation de cette section critique. Dans la plupart des cas, le vérificateur de verrou détecte immédiatement les sections critiques fuitées contenues dans une allocation de tas, une plage de DLL, une allocation de mémoire virtuelle ou une plage de mémoire mappée par MapViewOfFile et émet différents arrêts dans ces cas. Il reste donc très peu de cas 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 de manière inter-processus par des API comme VirtualFreeEx. La plupart du temps, cet arrêt sera rencontré si un arrêt précédent (par exemple, LOCK_IN_FREED_HEAP ou LOCK_IN_UNLOADED_DLL) a été continué en appuyant sur `g’ dans la console de débogage.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_IN_FREED_MEMORY
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Section critique corrompue.

Cause probable

Cet arrêt est généré si le champ DebugInfo de la section critique pointe vers une mémoire libérée. Habituellement, une autre structure DebugInfo valide est trouvée dans la liste des sections critiques actives. Sans corruption, les deux pointeurs devraient être identiques. Pour déboguer cet arrêt, utilisez les commandes de débogueur suivantes : $ !cs -s -d parameter3 - 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 parameter1 - vider les informations sur cette section critique en fonction du contenu actuel de la structure de la section critique (la structure est déjà corrompue donc parfois ces informations ne sont PAS fiables). $ dps parameter4 - pour identifier le chemin de code pour l’initialisation de cette section critique. Videz la section critique à l’adresse parameter1 et cherchez le motif de corruption. 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

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_CORRUPTED
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Propriétaire de section critique invalide.

Cause probable

Cet arrêt est généré si l’ID du thread propriétaire est invalide dans le contexte actuel. Pour déboguer cet arrêt : $ !cs -s parameter1 - vider les informations sur cette section critique. $ ln parameter1 - pour afficher les symboles près de l’adresse de la section critique. Cela devrait aider à identifier la section critique.

Informations affichées par Application Verifier

• Paramètre 1 - Adresse de la section critique.
• Paramètre 2 - Thread propriétaire.
• Paramètre 3 - Thread propriétaire attendu.
• Paramètre 4 - Adresse des informations de débogage de la section critique.

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_INVALID_OWNER
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Nombre de récursions de section critique invalide.

Cause probable

Cet arrêt est généré si le champ de nombre de récursions de la structure de section critique est invalide dans le contexte actuel. Pour déboguer cet arrêt : $ !cs -s parameter1 - vider les informations sur cette section critique. $ ln parameter1 - pour afficher les symboles près de l’adresse de la section critique. Cela devrait aider à identifier la section critique.

Informations affichées par Application Verifier

• Paramètre 1 - Adresse de la section critique.
• Paramètre 2 - Nombre de récursions.
• Paramètre 3 - Nombre de récursions attendu.
• Paramètre 4 - Adresse des informations de débogage de la section critique.

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_INVALID_RECURSION_COUNT
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Suppression de section critique avec un nombre de verrous invalide.

Cause probable

Cet arrêt est généré si une section critique est possédée par un thread lorsqu’elle est supprimée ou si la section critique n’est pas initialisée. Pour déboguer cet arrêt : $ !cs -s parameter1 - vider les informations 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 devrait aider à identifier la section critique.

Informations affichées par Application Verifier

• Paramètre 1 - Adresse de la section critique.
• Paramètre 2 - Nombre de verrous.
• Paramètre 3 - Nombre de verrous attendu.
• Paramètre 4 - Thread propriétaire.

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_INVALID_LOCK_COUNT
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

Cet arrêt est généré si une section critique est libérée plus de fois que le thread actuel ne l’a acquise. Pour déboguer cet arrêt : $ !cs -s parameter1 - vider les informations sur cette section critique. $ !cs -s -d parameter4 - vider les informations sur cette section critique. $ ln parameter1 - pour afficher les symboles près de l’adresse de la section critique. Cela devrait aider à identifier la section critique.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_OVER_RELEASED
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Section critique non initialisée.

Cause probable

Cet arrêt est généré si une section critique est utilisée sans être initialisée ou après avoir été supprimée. Pour déboguer cet arrêt : $ ln parameter1 - pour afficher les symboles près de l’adresse de la section critique. Cela devrait aider à identifier la section critique.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_NOT_INITIALIZED
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

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 - vider les informations sur cette section critique. $ ln parameter1 - pour afficher les symboles près de l’adresse de la section critique. Cela pourrait aider à identifier la section critique si c’est une variable globale. $ dps parameter3 - pour identifier le chemin de code pour la première initialisation de cette section critique. $ kb - pour afficher la trace d’appels actuelle, qui réinitialise cette section critique.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_ALREADY_INITIALIZED
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

Cet arrêt est généré si le thread actuel appelle VirtualFree sur un bloc de mémoire contenant 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 d’appels actuelle, qui appelle VirtualFree. Le coupable probable est la DLL qui appelle VirtualFree. $ !cs -s parameter1 - vider les informations sur cette section critique. $ dps parameter2 - pour identifier le chemin de code pour l’initialisation de cette section critique.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_IN_FREED_VMEM
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

Cet arrêt est généré si le thread actuel appelle UnmapViewOfFile sur un bloc de mémoire contenant une section critique active. L’application doit appeler DeleteCriticalSection sur cette section critique avant de démapper cette mémoire. $ kb - pour afficher la trace d’appels actuelle, qui appelle UnmapViewOfFile. Le coupable probable est la DLL qui appelle UnmapViewOfFile. $ !cs -s parameter1 - vider les informations sur cette section critique. $ dps parameter2 - pour identifier le chemin de code pour l’initialisation de cette section critique.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_IN_UNMAPPED_MEM
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Le thread actuel ne possède aucune section critique.

Cause probable

Cet arrêt est généré si le thread actuel appelle LeaveCriticalSection mais, selon la comptabilité interne du vérificateur, il ne possède aucune section critique. Si parameter2 est zéro, c’est probablement un bug dans le thread actuel. Il essaie soit de quitter une section critique qu’il n’a pas entrée, soit peut-être appelle-t-il LeaveCriticalSection plus de fois qu’il n’a appelé EnterCriticalSection pour la même section critique. Si parameter2 n’est pas zéro (c’est un nombre entier négatif), les structures de données internes du vérificateur sont probablement corrompues.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : THREAD_NOT_LOCK_OWNER
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

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

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Locks
• ID d’arrêt : LOCK_PRIVATE
• Code d’arrêt : 200NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Détails des arrêts SRWLock

Le verrou SRW n’est pas initialisé.

Cause probable

Cet arrêt est généré si un thread essaie d’utiliser le verrou SRW (Param1) qui n’est pas initialisé. $ kb - pour obtenir la trace d’appels actuelle. C’est ici que le verrou SRW est utilisé. Le verrou SRW doit être initialisé en utilisant InitializeSRWLock avant de pouvoir être utilisé.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : SRWLock
• ID d’arrêt : NOT_INITIALIZED
• Code d’arrêt : 250NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Le verrou SRW est déjà initialisé.

Cause probable

Cet arrêt est généré si le verrou SRW (Param1) est réinitialisé. Si le verrou SRW est activement utilisé par d’autres threads, la réinitialisation du verrou entraînera un comportement imprévisible de l’application, y compris des blocages et des plantages. La trace d’appels d’initialisation peut montrer une acquisition si le verrou SRW a été initialisé statiquement. $ kb - pour obtenir la trace d’appels actuelle. C’est ici que le verrou SRW est réinitialisé. $ dps Param3 - pour obtenir la trace d’appels d’initialisation du verrou SRW. Cette trace d’appels peut montrer une acquisition si le verrou a été initialisé statiquement.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : SRWLock
• ID d’arrêt : ALREADY_INITIALIZED
• Code d’arrêt : 250NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Acquisition-libération non correspondante sur le verrou SRW.

Cause probable

Cet arrêt est généré si le verrou SRW (Param1) est libéré avec une mauvaise API de libération. Si le verrou SRW a été acquis pour un accès partagé et est libéré en utilisant l’API de libération exclusive ou si le verrou SRW a été acquis pour un accès exclusif et est libéré en utilisant l’API de libération partagée. Cela peut entraîner un comportement imprévisible de l’application, y compris des blocages et des plantages. $ kb - pour obtenir la trace d’appels actuelle. C’est ici que le verrou SRW est libéré en utilisant la mauvaise API. $ dps Param3 - pour obtenir la trace d’appels d’acquisition du verrou SRW.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : SRWLock
• ID d’arrêt : MISMATCHED_ACQUIRE_RELEASE
• Code d’arrêt : 250NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

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înera un blocage et le thread sera bloqué indéfiniment. L’acquisition récursive d’un verrou SRW en mode exclusif entraînera un blocage. L’acquisition récursive d’un verrou SRW en mode partagé entraînera un blocage lorsqu’un thread attend un accès exclusif. Considérez l’exemple ci-dessous : - Le thread A acquiert le verrou SRW en mode partagé - Le thread B essaie d’acquérir le verrou SRW en mode exclusif et attend - Le thread A essaie d’acquérir le verrou SRW en mode partagé de manière récursive. Cela réussira tant qu’il n’y aura pas d’attente exclusive (dans ce cas B). Étant donné que les verrous SRW n’ont pas de famine d’écrivain, le thread A attend derrière le thread B. Maintenant, le thread B attend le thread A qui à son tour attend le thread B, provoquant une attente circulaire et donc un blocage. $ kb - pour obtenir la trace d’appels actuelle. C’est ici que le verrou SRW est acquis de manière récursive. $ dps Param2 - pour obtenir la trace d’appels pour la première acquisition.

Informations affichées par Application Verifier

• Paramètre 1 - Verrou SRW
• Paramètre 2 - Adresse de la trace d’appels de la première acquisition. Utilisez dps <address> pour voir où le verrou SRW a été acquis.
• Paramètre 3 - Non utilisé
• Paramètre 4 - Non utilisé

Informations supplémentaires

• Couche de test : SRWLock
• ID d’arrêt : RECURSIVE_ACQUIRE
• Code d’arrêt : 250NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Le thread qui sort ou qui est terminé possède un verrou SRW.

Cause probable

Cet arrêt est généré si le thread (Param2) qui possède le verrou SRW (Param1) est en train de sortir ou d’être terminé. Cela entraînera un verrou SRW orphelin et les threads essayant d’acquérir ce verrou seront bloqués indéfiniment. $ kb - pour obtenir la trace d’appels actuelle. C’est ici que le thread est en train de sortir ou d’être terminé. $ dps Param3 - pour obtenir la trace d’appels d’acquisition du verrou SRW.

Informations affichées par Application Verifier

• Paramètre 1 - Verrou SRW
• Paramètre 2 - ID du thread qui sort ou est terminé.
• Paramètre 3 - Adresse de la trace d’appels d’acquisition. Utilisez dps <address> pour voir où le verrou SRW a été acquis.
• Paramètre 4 - Non utilisé

Informations supplémentaires

• Couche de test : SRWLock
• ID d’arrêt : EXIT_THREAD_OWNS_LOCK
• Code d’arrêt : 250NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

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 à corriger et peut entraîner un comportement imprévisible de l’application. $ kb - pour obtenir la trace d’appels actuelle. C’est ici que le thread libère le verrou SRW qu’il n’a pas acquis. $ dps Param4 - pour obtenir la trace d’appels d’acquisition du verrou SRW.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : SRWLock
• ID d’arrêt : INVALID_OWNER
• Code d’arrêt : 250NAN
• Gravité : Avertissement
• Erreur unique : 
• Rapport d’erreur : Aucun
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

Cet arrêt est généré si l’adresse mémoire (Param1) libérée contient un verrou SRW actif qui est encore en cours d’utilisation. Cela peut entraîner un comportement imprévisible de l’application, y compris des plantages et des blocages. $ kb - pour obtenir la trace d’appels actuelle. C’est ici que la mémoire est libérée et qu’elle contient un verrou SRW actif. $ dps Param4 - pour obtenir la trace d’appels d’acquisition du verrou SRW.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : SRWLock
• ID d’arrêt : IN_FREED_MEMORY
• Code d’arrêt : 250NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

Cet arrêt est généré si la DLL déchargée (Param2) contient un verrou SRW actif (Param1) qui est encore en cours d’utilisation. Cela peut entraîner un comportement imprévisible de l’application, y compris des plantages et des blocages. $ kb - pour obtenir la trace d’appels actuelle. C’est ici que la DLL est déchargée et qu’elle contient un verrou SRW actif. $ du Param2 - pour trouver le nom de la DLL qui est déchargée. $ dps Param4 - pour obtenir la trace d’appels d’acquisition du verrou SRW.

Informations affichées par Application Verifier

• Paramètre 1 - Verrou SRW
• Paramètre 2 - Adresse du nom de la DLL déchargée. Utilisez du <address> pour voir le nom.
• Paramètre 3 - ID du thread qui a acquis le verrou SRW.
• Paramètre 4 - Adresse de la trace d’appels d’acquisition. Utilisez dps <address> pour voir où le verrou SRW a été acquis.

Informations supplémentaires

• Couche de test : SRWLock
• ID d’arrêt : IN_UNLOADED_DLL
• Code d’arrêt : 250NAN
• Gravité : Avertissement
• Erreur unique : 
• Rapport d’erreur : Aucun
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Détails des arrêts de mémoire

Libération d’un bloc de mémoire virtuelle avec une taille ou une adresse de début invalide.

Cause probable

Cet arrêt est généré si le vérificateur d’application détecte un VirtualFree ou un déchargement de DLL avec une adresse de début ou une taille d’allocation de mémoire invalide. Dans le cas du déchargement de DLL, cela signifie probablement une corruption de mémoire à l’intérieur de la liste des DLL chargées. Pour déboguer cet arrêt, regardez la trace d’appels actuelle et l’adresse mémoire et la taille qui sont sur le point d’être libérées et essayez de déterminer pourquoi elles sont invalides.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : INVALID_FREEMEM
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Appel VirtualAlloc incorrect.

Cause probable

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 d’allocation de mémoire invalide. Pour déboguer cet arrêt, regardez la trace d’appels actuelle (kb) et l’adresse mémoire et la taille qui sont sur le point d’être allouées et essayez de déterminer pourquoi elles sont invalides.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : INVALID_ALLOCMEM
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Appel de vue de carte incorrect.

Cause probable

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 mappage invalide. Pour déboguer cet arrêt, regardez la trace d’appels actuelle (kb) et l’adresse mémoire et la taille qui sont sur le point d’être mappées et essayez de déterminer pourquoi elles sont invalides.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : INVALID_MAPVIEW
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Sondage d’une adresse invalide.

Cause probable

Cet arrêt est généré si le vérificateur d’application détecte un appel IsBadXXXPtr avec une adresse invalide (par exemple, une adresse en mode noyau, au lieu d’une adresse normale en mode utilisateur) pour le tampon de mémoire à sonder. Pour déboguer cet arrêt, regardez la trace d’appels actuelle (kb) et essayez de déterminer pourquoi l’appelant de la fonction IsBadXXXPtr a fini avec une adresse invalide. Souvent, l’adresse est tout simplement fausse, par exemple un pointeur non initialisé. La bibliothèque MSDN liste quelques raisons pour lesquelles les applications ne devraient pas utiliser les API IsBadXXXPtr : Dans un environnement de multitâche préemptif, il est possible pour un autre thread de changer l’accès du processus à la mémoire testée. La déréférenciation de pointeurs potentiellement invalides peut désactiver l’expansion de la pile dans d’autres threads. Un thread épuisant sa pile, lorsque l’expansion de la pile a été désactivée, entraîne la terminaison immédiate du processus parent, sans fenêtre d’erreur contextuelle ou informations de diagnostic. Les threads d’un processus sont censés coopérer de manière à ce qu’un thread ne libère pas la mémoire dont un autre a besoin. L’utilisation de cette fonction ne dispense pas de cette nécessité. Si cela n’est pas fait, l’application peut échouer de manière imprévisible. Pour toutes ces raisons, nous recommandons de ne jamais utiliser ces API.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : PROBE_INVALID_ADDRESS
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Sondage de la mémoire libre.

Cause probable

Cet arrêt est généré si le vérificateur d’application détecte un appel IsBadXXXPtr pour une allocation de mémoire qui est libre. Cela est très mauvais car il est possible que, dans d’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 pourrait finir par corrompre la mémoire de quelqu’un d’autre, avec des effets désastreux. Pour déboguer cet arrêt, regardez la trace d’appels actuelle (kb) et essayez de déterminer pourquoi l’appelant de la fonction IsBadXXXPtr a fini par sonder la mémoire libre. L’adresse pourrait être tout simplement fausse (par exemple, un pointeur non initialisé) ou peut-être une mémoire déjà libérée. Si la mémoire a déjà été libérée par l’une des API VirtualFree ou UnmapViewOfFile, `!avrf -vs -a parameter3’ recherchera un journal des traces de pile des chemins de code qui ont alloué/libéré cette adresse et affichera ces traces de pile si elles sont disponibles. Cela pourrait montrer la trace d’appels 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 parameter3’ recherchera un journal des traces de pile des chemins de code qui ont alloué/libéré cette adresse du/vers le tas et affichera ces traces de pile si elles sont disponibles. La bibliothèque MSDN liste quelques raisons pour lesquelles les applications ne devraient pas utiliser les API IsBadXXXPtr : Dans un environnement de multitâche préemptif, il est possible pour un autre thread de changer l’accès du processus à la mémoire testée. La déréférenciation de pointeurs potentiellement invalides peut désactiver l’expansion de la pile dans d’autres threads. Un thread épuisant sa pile, lorsque l’expansion de la pile a été désactivée, entraîne la terminaison immédiate du processus parent, sans fenêtre d’erreur contextuelle ou informations de diagnostic. Les threads d’un processus sont censés coopérer de manière à ce qu’un thread ne libère pas la mémoire dont un autre a besoin. L’utilisation de cette fonction ne dispense pas de cette nécessité. Si cela n’est pas fait, l’application peut échouer de manière imprévisible. Pour toutes ces raisons, nous recommandons de ne jamais utiliser ces API.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : PROBE_FREE_MEM
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Sondage d’une page de garde.

Cause probable

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 documenté dans la bibliothèque MSDN : La déréférenciation de pointeurs potentiellement invalides peut désactiver l’expansion de la pile dans d’autres threads. Un thread épuisant sa pile, lorsque l’expansion de la pile a été désactivée, entraîne la terminaison immédiate du processus parent, sans fenêtre d’erreur contextuelle ou informations de diagnostic. Pour déboguer cet arrêt, regardez la trace d’appels actuelle (kb) et essayez de déterminer pourquoi l’appelant de la fonction IsBadXXXPtr a fini par sonder une GUARD_PAGE. La bibliothèque MSDN liste quelques raisons pour lesquelles les applications ne devraient pas utiliser les API IsBadXXXPtr : Dans un environnement de multitâche préemptif, il est possible pour un autre thread de changer l’accès du processus à la mémoire testée. La déréférenciation de pointeurs potentiellement invalides peut désactiver l’expansion de la pile dans d’autres threads. Un thread épuisant sa pile, lorsque l’expansion de la pile a été désactivée, entraîne la terminaison immédiate du processus parent, sans fenêtre d’erreur contextuelle ou informations de diagnostic. Les threads d’un processus sont censés coopérer de manière à ce qu’un thread ne libère pas la mémoire dont un autre a besoin. L’utilisation de cette fonction ne dispense pas de cette nécessité. Si cela n’est pas fait, l’application peut échouer de manière imprévisible. Pour toutes ces raisons, nous recommandons de ne jamais utiliser ces API.

Informations affichées par Application Verifier

• 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é.

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : PROBE_GUARD_PAGE
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Sondage de l’adresse NULL.

Cause probable

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, regardez la trace d’appels actuelle (kb) et essayez de déterminer pourquoi l’appelant de la fonction IsBadXXXPtr a fini avec l’adresse NULL. C’est typiquement le signe que quelqu’un 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 : int main (void) { PVOID p; p = malloc (1024); Use (p); return 0; } void Use (PVOID p) { if (IsBadReadPtr (p)) { return; } // // p est sûr à utiliser ici. // } Ce code devrait être réécrit ainsi : int main (void) { PVOID p; p = malloc (1024); if (NULL == p)) { return -1; } Use (p); return 0; } void Use (PVOID p) { // // p est sûr à utiliser ici. // } La bibliothèque MSDN liste quelques raisons pour lesquelles les applications ne devraient pas utiliser les API IsBadXXXPtr : Dans un environnement de multitâche préemptif, il est possible pour un autre thread de changer l’accès du processus à la mémoire testée. La déréférenciation de pointeurs potentiellement invalides peut désactiver l’expansion de la pile dans d’autres threads. Un thread épuisant sa pile, lorsque l’expansion de la pile a été désactivée, entraîne la terminaison immédiate du processus parent, sans fenêtre d’erreur contextuelle ou informations de diagnostic. Les threads d’un processus sont censés coopérer de manière à ce qu’un thread ne libère pas la mémoire dont un autre a besoin. L’utilisation de cette fonction ne dispense pas de cette nécessité. Si cela n’est pas fait, l’application peut échouer de manière imprévisible. Pour toutes ces raisons, nous recommandons de ne jamais utiliser ces API.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : PROBE_NULL
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Sondage d’un bloc de mémoire avec une adresse de début ou une taille invalide.

Cause probable

Cet arrêt est généré si le vérificateur d’application détecte un appel IsBadXXXPtr avec une adresse de début invalide (par exemple, une adresse en mode noyau, au lieu d’une adresse normale en mode utilisateur) ou une taille invalide pour le tampon de mémoire à sonder. Pour déboguer cet arrêt, regardez la trace d’appels actuelle (kb) et essayez de déterminer pourquoi l’appelant de la fonction IsBadXXXPtr a fini avec une adresse ou une taille invalide. Souvent, l’adresse ou la taille sont tout simplement fausses, par exemple des variables non initialisées. La bibliothèque MSDN liste quelques raisons pour lesquelles les applications ne devraient pas utiliser les API IsBadXXXPtr : Dans un environnement de multitâche préemptif, il est possible pour un autre thread de changer l’accès du processus à la mémoire testée. La déréférenciation de pointeurs potentiellement invalides peut désactiver l’expansion de la pile dans d’autres threads. Un thread épuisant sa pile, lorsque l’expansion de la pile a été désactivée, entraîne la terminaison immédiate du processus parent, sans fenêtre d’erreur contextuelle ou informations de diagnostic. Les threads d’un processus sont censés coopérer de manière à ce qu’un thread ne libère pas la mémoire dont un autre a besoin. L’utilisation de cette fonction ne dispense pas de cette nécessité. Si cela n’est pas fait, l’application peut échouer de manière imprévisible. Pour toutes ces raisons, nous recommandons de ne jamais utiliser ces API.

Informations affichées par Application Verifier

• 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é.

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : PROBE_INVALID_START_OR_SIZE
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

Cet arrêt est généré si le vérificateur d’application détecte un déchargement de DLL avec une adresse de début invalide ou une taille de la plage de mémoire de la DLL. Cela signifie probablement une corruption de mémoire à l’intérieur de la liste des DLL chargées par ntdll.dll.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : INVALID_DLL_RANGE
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

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 en fait partie de la pile du thread actuel (!). Pour déboguer cet arrêt, regardez la trace d’appels actuelle (kb) et essayez de comprendre pourquoi la fonction qui a appelé VirtualFree pensait que le bloc de mémoire était alloué ou mappé dynamiquement alors qu’il s’agissait en fait de mémoire allouée à partir de la pile.

Informations affichées par Application Verifier

• Paramètre 1 - Adresse de base de l’allocation.
• Paramètre 2 - Taille de la région mémoire.
• Paramètre 3 - Adresse de la limite basse de la pile.
• Paramètre 4 - Adresse de la limite haute de la pile.

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : FREE_THREAD_STACK_MEMORY
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

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 seules deux valeurs acceptables pour ce paramètre sont MEM_DECOMMIT et MEM_RELEASE. Si VirtualFree est appelé avec une autre valeur que ces deux-là, VirtualFree échouera à libérer la mémoire. Pour déboguer cet arrêt, regardez la trace d’appels actuelle (kb) : l’appelant de VirtualFree est probablement le coupable.

Informations affichées par Application Verifier

• 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é.

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : INVALID_FREE_TYPE
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Tentative de libération d’un bloc de mémoire virtuelle déjà libéré.

Cause probable

Cet arrêt est généré si le vérificateur d’application détecte un VirtualFree pour une adresse déjà libérée. Pour déboguer cet arrêt, regardez la trace d’appels actuelle (kb) et essayez de déterminer pourquoi la mémoire est déjà libérée mais l’application essaie de la libérer à nouveau. `!avrf -vs -a parameter1’ recherchera un journal des traces de pile des chemins de code qui ont alloué/libéré cette adresse et affichera ces traces de pile si elles sont disponibles. Cela pourrait montrer la trace d’appels qui a libéré cette mémoire.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : MEM_ALREADY_FREE
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

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. Lors de l’utilisation de MEM_RELEASE, la seule valeur acceptable pour ce paramètre est 0. Si VirtualFree est appelé avec une autre valeur que 0, VirtualFree échouera à libérer la mémoire. Pour déboguer cet arrêt, regardez la trace d’appels actuelle (kb) : l’appelant de VirtualFree est probablement le coupable.

Informations affichées par Application Verifier

• 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é.

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : INVALID_FREE_SIZE
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

Cet arrêt est généré si la fonction du point d’entrée (DllMain) d’une DLL lève une exception. Un exemple de raison pour laquelle cela est mauvais est : si DllMain(DLL_PROCESS_ATTACH) lève une exception, le chargeur de DLL de Windows fera : - Capturer et masquer l’exception ; - Décharger 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 levé l’exception, et elle n’aura pas la chance de libérer ces ressources sur DllMain (DLL_PROCESS_DETACH). Pour déboguer cet arrêt : $ du parameter1 - pour afficher le nom de la DLL ; $ .exr parameter2 - pour afficher les informations d’exception ; $ .cxr parameter3 suivi de kb - pour afficher les informations de contexte de l’exception et la trace d’appels au moment où l’exception a été levée ; $ parameter4 est l’adresse d’une structure de vérification interne et n’a pas de signification pour la plupart des utilisateurs du vérificateur.

Informations affichées par Application Verifier

• Paramètre 1 - Nom de la DLL (utilisez du pour la 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 - Descripteur de la dll de vérification

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : DLL_UNEXPECTED_EXCEPTION
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Exception inattendue levée dans la fonction du thread.

Cause probable

Cet arrêt est généré si une fonction de thread lève une exception. Cela est mauvais car tout le processus sera tué. Pour déboguer cet arrêt : $ parameter1 pourrait ê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 de l’exception ;

Informations affichées par Application Verifier

• 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é.

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : THREAD_UNEXPECTED_EXCEPTION
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Exception inattendue levée lors du sondage de la mémoire.

Cause probable

Cet arrêt est généré si nous obtenons une exception pendant un appel IsBadXXXPtr. Cela signifie que le tampon de mémoire que nous sondons 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. Voir la discussion ci-dessus sur les autres codes d’arrêt (PROBE_INVALID_ADDRESS, PROBE_FREE_MEM, PROBE_GUARD_PAGE, PROBE_NULL, PROBE_INVALID_START_OR_SIZE) pour plus d’exemples de raisons pour lesquelles l’utilisation des API IsBadXXXPtr n’est pas recommandée. Pour déboguer cet arrêt : $ parameter1 sera généralement C0000005 et cela signifie Violation d’accès ; $ .exr parameter2 - pour afficher les informations d’exception ; $ .cxr parameter3 suivi de kb - pour afficher les informations de contexte de l’exception et la trace d’appels au moment où l’exception a été levée ;

Informations affichées par Application Verifier

• 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é

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : PROBE_UNEXPECTED_EXCEPTION
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Tentative de réinitialisation d’une adresse NULL.

Cause probable

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 doit être utilisé uniquement pour la mémoire déjà allouée, donc NULL n’est pas un premier paramètre valide dans ce cas.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : INVALID_MEM_RESET
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

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 en fait partie de la pile du thread actuel (!). Pour déboguer cet arrêt, regardez la trace d’appels actuelle (kb) et essayez de comprendre pourquoi la fonction qui a appelé HeapFree pensait que le bloc de mémoire était alloué ou mappé dynamiquement alors qu’il s’agissait en fait de mémoire allouée à partir de la pile.

Informations affichées par Application Verifier

• Paramètre 1 - Adresse de base de l’allocation.
• Paramètre 2 - Taille de la région mémoire.
• Paramètre 3 - Adresse de la limite basse de la pile.
• Paramètre 4 - Adresse de la limite haute de la pile.

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : FREE_THREAD_STACK_MEMORY_AS_HEAP
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

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 en fait partie de la pile du thread actuel (!). Pour déboguer cet arrêt, regardez la trace d’appels actuelle (kb) et essayez de comprendre pourquoi la fonction qui a appelé UnmapViewOfFile pensait que le bloc de mémoire était alloué ou mappé dynamiquement alors qu’il s’agissait en fait de mémoire allouée à partir de la pile.

Informations affichées par Application Verifier

• Paramètre 1 - Adresse de base de l’allocation.
• Paramètre 2 - Taille de la région mémoire.
• Paramètre 3 - Adresse de la limite basse de la pile.
• Paramètre 4 - Adresse de la limite haute de la pile.

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : FREE_THREAD_STACK_MEMORY_AS_MAP
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Adresse RTL_RESOURCE incorrecte.

Cause probable

Cet arrêt est généré si l’application essaie 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 de vérification. param1 est l’adresse incorrecte utilisée et le coupable est dans la trace d’appels (affichez-la avec kb).

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : INVALID_RESOURCE_ADDRESS
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Adresse de section critique invalide.

Cause probable

Cet arrêt est généré si l’application essaie 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 de vérification. param1 est l’adresse incorrecte utilisée et le coupable est dans la trace d’appels (affichez-la avec kb).

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : INVALID_CRITSECT_ADDRESS
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Tentative d’exécution de code dans une mémoire non exécutable.

Cause probable

Cet arrêt est généré si l’application tente d’exécuter du code à partir d’une adresse non exécutable ou libre. Pour déboguer cet arrêt : $ u parameter2 - pour désassembler le code incriminé $ .exr parameter3 - pour afficher les informations d’exception ; $ .cxr parameter4 suivi de kb - pour afficher les informations de contexte de l’exception et la trace de la pile au moment où l’exception a été levée.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : THREAD_UNEXPECTED_EXCEPTION_CODE
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Exception inattendue levée lors de l’initialisation du tampon de sortie.

Cause probable

Cet arrêt est généré si nous obtenons une exception lors de l’initialisation d’un tampon spécifié comme paramètre de sortie pour une API Win32 ou CRT. Cela signifie généralement que la taille du tampon de sortie spécifiée est incorrecte. Pour déboguer cet arrêt : $ .exr parameter3 - pour afficher les informations d’exception ; $ .cxr parameter4 suivi de kb - pour afficher les informations de contexte de l’exception et la trace d’appels au moment où l’exception a été levée.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : OUTBUFF_UNEXPECTED_EXCEPTION
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Exception inattendue lors de la tentative de détermination de la taille du bloc de tas.

Cause probable

Cet arrêt est généré si nous obtenons une exception lors de l’appel de HeapSize pour un bloc de tas qui est en cours de libération. Cela signifie généralement que l’adresse du bloc de tas spécifiée est incorrecte ou que le tas est corrompu. Pour déboguer cet arrêt : $ .exr parameter3 - pour afficher l’enregistrement d’exception ; $ .cxr parameter4 suivi de kb - pour afficher les informations de contexte de l’exception et la trace d’appels au moment où l’exception a été levée.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : SIZE_HEAP_UNEXPECTED_EXCEPTION
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Libération d’un bloc de mémoire avec une adresse de début invalide.

Cause probable

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 de 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.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : INVALID_FREEMEM_START_ADDRESS
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Démappage d’un bloc de mémoire avec une adresse de début invalide.

Cause probable

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.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : INVALID_UNMAPVIEW_START_ADDRESS
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Exception inattendue levée dans la fonction de rappel du threadpool.

Cause probable

Cet arrêt est généré si une fonction de rappel dans le thread du threadpool lève une exception. Pour déboguer cet arrêt : $ parameter1 pourrait ê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 de l’exception.

Informations affichées par Application Verifier

• 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é

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : THREADPOOL_UNEXPECTED_EXCEPTION
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Code dans la mémoire non exécutable

Cause probable

Cet arrêt est généré si l’application tente d’exécuter du code à partir d’une adresse non exécutable ou libre. Pour déboguer cet arrêt : $ u parameter2 - pour désassembler le code incriminé $ .exr parameter3 - pour afficher les informations d’exception $ .cxr parameter4 suivi de kb - pour afficher les informations de contexte de l’exception et la trace de la pile au moment où l’exception a été levée.

Informations affichées par Application Verifier

• Paramètre 1 - Adresse accédée
• Paramètre 2 - Code effectuant l’accès invalide
• Paramètre 3 - Enregistrement d’exception. Utilisez .exr pour l’afficher.
• Paramètre 4 - Enregistrement de contexte. Utilisez .cxr pour l’afficher.

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : THREADPOOL_UNEXPECTED_EXCEPTION_CODE
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Création d’un tas exécutable.

Cause probable

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

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : EXECUTABLE_HEAP
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Allocation de mémoire exécutable.

Cause probable

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

Informations affichées par Application Verifier

• 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é.

Informations supplémentaires

• Couche de test : Memory
• ID d’arrêt : EXECUTABLE_MEMORY
• Code d’arrêt : 600NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Détails des arrêts TLS

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

Cause probable

Cet arrêt est généré si une DLL ayant 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 incriminée ; $ .reload xxx.dll=parameter4 - recharger les symboles pour la DLL incriminée (si nécessaire). xxx.dll est le nom de la DLL affichée à l’étape ci-dessus ; $ u parameter2 - désassembler le code qui a alloué le TLS. Cela devrait pointer vers la fonction qui a alloué le TLS mais a oublié de le libérer avant que la DLL ne soit déchargée.

Informations affichées par Application Verifier

• 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 de la DLL.

Informations supplémentaires

• Couche de test : TLS
• ID d’arrêt : TLS_LEAK
• Code d’arrêt : 350NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Structure TLS du vérificateur corrompue.

Cause probable

Cet arrêt est généré si les structures internes du vérificateur utilisées pour stocker l’état des slots TLS pour le thread sont corrompues. Il est très probable que cela soit dû à une corruption aléatoire dans le processus.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : TLS
• ID d’arrêt : CORRUPTED_TLS
• Code d’arrêt : 350NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Utilisation d’un index TLS invalide.

Cause probable

Cet arrêt est généré si un index TLS invalide est utilisé. Dans la plupart des cas, c’est parce que le code utilise encore cet index lorsque TlsFree est appelé. Voici un exemple pour le thread du threadpool. T1 : La DLL se charge et TlsAlloc T1 : Callback de file d’attente T1 : Callback ignoré/annulé T1 : TlsFree T2 : Le callback s’exécute et appelle TlsSetValue T1 : La DLL se décharge

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : TLS
• ID d’arrêt : INVALID_TLS_INDEX
• Code d’arrêt : 350NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Détails des arrêts de threadpool

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

Cause probable

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

Informations affichées par Application Verifier

• Format : -  threadpool thread (%x) ayant exécuté Callback (%p) a une priorité de thread altérée (%i -> %i)
• Paramètre 1 - Fonction de callback.
• Paramètre 2 - Contexte.
• Paramètre 3 - Trace de pile d’allocation d’objet threadpool, utilisez dps pour la vider.
• Paramètre 4 - Priorité actuelle.

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : INCONSISTENT_PRIORITY
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

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

Informations affichées par Application Verifier

• Format : - threadpool thread (%x) ayant exécuté Callback (%p) a un masque d’affinité de thread altéré (%p -> %p)
• Paramètre 1 - Fonction de callback.
• Paramètre 2 - Contexte.
• Paramètre 3 - Trace de pile d’allocation d’objet threadpool, utilisez dps pour la vider.
• Paramètre 4 - Affinité actuelle.

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : INCONSISTENT_AFFINITY_MASK
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Message non traité dans le pool de messages du thread actuel.

Cause probable

Cet arrêt est généré si un message reste non traité lorsque ce thread de threadpool est retourné au pool. C’est dangereux car il sera traité dans un contexte totalement différent. Veuillez utiliser Veuillez utiliser !avrf -tp <Param4> pour voir les messages postés à ce thread.

Informations affichées par Application Verifier

• Format : - threadpool thread (%x) ayant exécuté Callback (%p) a un message de fenêtre en attente (%x: %x)
• Paramètre 1 - Fonction de callback.
• Paramètre 2 - Contexte.
• Paramètre 3 - Trace de pile d’allocation d’objet threadpool, utilisez dps pour la vider.
• Paramètre 4 - ID du thread de threadpool. Veuillez utiliser !avrf -tp <threadid> pour voir les messages postés à ce thread.

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : ORPHANED_THREAD_MESSAGE
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Fenêtre non fermée appartenant au thread actuel.

Cause probable

Cet arrêt est généré si une fenêtre est maintenue ouverte lorsque ce thread de threadpool est retourné au pool.

Informations affichées par Application Verifier

• Format : -  threadpool thread (%x) ayant exécuté Callback (%p) a un hwnd valide (%x: %s) qui pourrait recevoir des messages
• Paramètre 1 - Fonction de callback.
• Paramètre 2 - Contexte.
• Paramètre 3 - Trace de pile d’allocation d’objet threadpool, utilisez dps pour la vider.
• Paramètre 4 - ID du thread de threadpool.

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : ORPHANED_THREAD_WINDOW
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

ExitThread() sur un thread de threadpool.

Cause probable

Cet arrêt est généré si ExitThread est appelé sur un thread de threadpool. C’est interdit car cela rendra le système instable. Cela causera des fuites de ressources, des blocages ou des AV.

Informations affichées par Application Verifier

• Paramètre 1 - Fonction de callback.
• Paramètre 2 - Contexte.
• Paramètre 3 - Trace de pile d’allocation d’objet threadpool, utilisez dps pour la vider.
• Paramètre 4 - Non utilisé.

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : ILLEGAL_THREAD_EXIT
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Le thread est en état d’usurpation lorsqu’il est retourné à un thread de threadpool.

Cause probable

Cet arrêt est généré si la fonction de callback change le jeton de thread pour usurper un autre utilisateur et oublie de le réinitialiser avant de le retourner au threadpool.

Informations affichées par Application Verifier

• Paramètre 1 - Fonction de callback.
• Paramètre 2 - Contexte.
• Paramètre 3 - Trace de pile d’allocation d’objet threadpool, utilisez dps pour la vider.
• Paramètre 4 - Non utilisé.

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : THREAD_IN_IMPERSONATION
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Une fonction nécessitant un thread persistant est appelée.

Cause probable

Certaines API de Microsoft Windows doivent être appelées à l’intérieur d’un thread dédié ou persistant. Dans le threadpool, vous devriez généralement éviter d’utiliser le stockage local de thread et de mettre en file d’attente des appels asynchrones nécessitant un thread persistant, comme la fonction RegNotifyChangeKeyValue. Cependant, ces fonctions peuvent être mises en file d’attente pour un thread de travail persistant en utilisant QueueUserWorkItem avec l’option WT_EXECUTEINPERSISTENTTHREAD. Un kb dans le débogueur révélera l’appelant.

Informations affichées par Application Verifier

• Paramètre 1 - Fonction de callback.
• Paramètre 2 - Contexte.
• Paramètre 3 - Trace de pile d’allocation d’objet threadpool, utilisez dps pour la vider.
• Paramètre 4 - Non utilisé.

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : PERSISTED_THREAD_NEEDED
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Le thread est dans un état de transaction sale.

Cause probable

Cet arrêt est généré si la fonction de callback oublie de fermer ou de réinitialiser le handle de la transaction actuelle.

Informations affichées par Application Verifier

• Paramètre 1 - Fonction de callback.
• Paramètre 2 - Contexte.
• Paramètre 3 - Trace de pile d’allocation d’objet threadpool, utilisez dps pour la vider.
• Paramètre 4 - Handle de transaction.

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : DIRTY_TRANSACTION_CONTEXT
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

Cet arrêt est généré si la fonction de callback appelle CoInit et CoUnInit de manière déséquilibrée.

Informations affichées par Application Verifier

• Paramètre 1 - Fonction de callback.
• Paramètre 2 - Contexte.
• Paramètre 3 - Trace de pile d’allocation d’objet threadpool, utilisez dps pour la vider.
• Paramètre 4 - Compte d’appels équilibrés.

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : DIRTY_COM_STATE
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

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

Cause probable

Cet arrêt est généré si la période pour signaler le timer n’est pas zéro lorsque le timer est configuré pour signaler une seule fois avec le flag WT_EXECUTEONLYONCE

Informations affichées par Application Verifier

• 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é.

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : INCONSISTENT_TIMER_PARAMS
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Le verrou de chargement a été maintenu par le thread de threadpool pendant le callback.

Cause probable

Cet arrêt est généré si le verrou de chargement est maintenu pendant le callback et n’est pas libéré lorsque le thread est retourné au threadpool.

Informations affichées par Application Verifier

• Paramètre 1 - Fonction de callback.
• Paramètre 2 - Contexte.
• Paramètre 3 - Trace de pile d’allocation d’objet threadpool, utilisez dps pour la vider.
• Paramètre 4 - Non utilisé.

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : LOADER_LOCK_HELD
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

La langue préférée est définie par le thread de threadpool pendant le callback.

Cause probable

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

Informations affichées par Application Verifier

• Paramètre 1 - Fonction de callback.
• Paramètre 2 - Contexte.
• Paramètre 3 - Trace de pile d’allocation d’objet threadpool, utilisez dps pour la vider.
• Paramètre 4 - Non utilisé.

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : PREFERRED_LANGUAGES_SET
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

La priorité en arrière-plan est définie par le thread de threadpool pendant le callback.

Cause probable

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

Informations affichées par Application Verifier

• Paramètre 1 - Fonction de callback.
• Paramètre 2 - Contexte.
• Paramètre 3 - Trace de pile d’allocation d’objet threadpool, utilisez dps pour la vider.
• Paramètre 4 - Non utilisé.

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : BACKGROUND_PRIORITY_SET
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

TerminateThread() sur un thread de threadpool.

Cause probable

Cet arrêt est généré si TerminateThread est appelé sur un thread de threadpool. C’est interdit car cela rendra le système instable. Cela causera des fuites de ressources, des blocages ou des AV.

Informations affichées par Application Verifier

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

Informations supplémentaires

• Couche de test : Threadpool
• ID d’arrêt : ILLEGAL_THREAD_TERMINATION
• Code d’arrêt : 700NAN
• Gravité :  Erreur
• Erreur unique : 
• Rapport d’erreur : Interruption
• Journaliser dans un fichier : oui
• Créer une rétroaction : oui

Voir aussi

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

Application Verifier : Vue d’ensemble

Vérificateur d’application - Fonctionnalités

Vérificateur d’application - Test d’applications

Vérificateur d’application - Tests dans Application Verifier

Vérificateur d’application - Débogage des arrêts du vérificateur d’application

Vérificateur d’application - Forum aux questions