Vérificateur d’application - Codes d’arrêt - Divers

Les codes d’arrêt suivants sont contenus dans cet ensemble de tests.

Appel dangereux à TerminateThread.

Cet arrêt est généré si un thread (l’ID de thread est paramètre1) est arrêté explicitement à l’aide de TerminateThread.Cette fonction est très dangereuse car elle introduit une altération des données et des blocages (comme par MSDN).

• Paramètre 1 - ID de thread pour l’appelant de Terminatethread.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Dangereux
• ID d’arrêt : TERMINATE_THREAD_CALL
• Arrêter le code : 0x100
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Dépassement de capacité de pile potentiel dans des conditions de mémoire insuffisantes.

Cet arrêt est généré si la taille initiale de validation de pile d’un thread est telle qu’un dépassement de capacité de pile peut être déclenché dans des conditions de mémoire faible si la pile ne peut pas être étendue.

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

• Couche de test : Dangereux
• ID d’arrêt : STACK_OVERFLOW
• Arrêter le code : 0x101
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

ExitProcess appelé pendant l’exécution de plusieurs threads.

Cet arrêt est généré si un thread appelle ExitProcess pendant qu’il existe plusieurs threads en cours d’exécution. Dans ce cas, TerminateThread est appelé en interne pour chaque thread, ce qui peut créer des interblocages ou des altérations de données.

• Paramètre 1 - Nombre de threads en cours d’exécution.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Dangereux
• ID d’arrêt : INVALID_EXIT_PROCESS_CALL
• Arrêter le code : 0x102
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

LoadLibrary est appelé pendant DllMain.

Cet arrêt est généré si le code à l’intérieur de DllMain appelle LoadLibrary ou FreeLibary. Il s’agit du comportement interdit par MSDN.

• Paramètre 1 - Nom de dll (utilisez du pour vider).
• Paramètre 2 - Adresse de base dll.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Dangereux
• ID d’arrêt : INVALID_LOAD_LIBRARY_CALL
• Arrêter le code : 0x103
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

FreeLibrary est appelé pendant DllMain.

Cet arrêt est généré si le code à l’intérieur de DllMain appelle LoadLibrary ou FreeLibary. Il s’agit du comportement interdit par MSDN.

• Paramètre 1 - Nom de dll (utilisez du pour vider).
• Paramètre 2 - Adresse de base dll.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : Dangereux
• ID d’arrêt : INVALID_FREE_LIBRARY_CALL
• Arrêter le code : 0x104
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

SetProcessWorkingSetSize est appelé avec MinimumWorkingSetSize = 0xFFFFFFFF.

Utilisez MinimumWorkingSetSize = (SIZE_T) -1.

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

• Couche de test : Dangereux
• ID d’arrêt : INVALID_MINIMUM_PROCESS_WORKING_SIZE
• Arrêter le code : 0x105
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

SetProcessWorkingSetSize est appelé avec MaximumWorkingSetSize = 0xFFFFFFFF.

Utilisez MaximumWorkingSetSize = (SIZE_T) -1.

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

• Couche de test : Dangereux
• ID d’arrêt : INVALID_MAXIMUM_PROCESS_WORKING_SIZE
• Arrêter le code : 0x106
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

SetProcessWorkingSetSizeEx est appelé avec MinimumWorkingSetSize = 0xFFFFFFFF.

Utilisez MinimumWorkingSetSize = (SIZE_T) -1.

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

• Couche de test : Dangereux
• ID d’arrêt : INVALID_MINIMUM_PROCESS_WORKING_SIZE_EX
• Arrêter le code : 0x107
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

SetProcessWorkingSetSizeEx est appelé avec MaximumWorkingSetSize = 0xFFFFFFFF.

Utilisez MaximumWorkingSetSize = (SIZE_T) -1.

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

• Couche de test : Dangereux
• ID d’arrêt : INVALID_MAXIMUM_PROCESS_WORKING_SIZE_EX
• Arrêter le code : 0x108
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Serrures
• ID d’arrêt : EXIT_THREAD_OWNS_LOCK
• Arrêter le code : 0x200
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Déchargement de DLL contenant une section critique active.

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

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

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_IN_UNLOADED_DLL
• Arrêter le code : 0x201
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_IN_FREED_HEAP
• Arrêter le code : 0x202
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Section critique double initialisée ou endommagée.

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

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

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_DOUBLE_INITIALIZE
• Arrêter le code : 0x203
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Mémoire libre contenant une section critique active.

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

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

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

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_IN_FREED_MEMORY
• Arrêter le code : 0x204
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Section critique endommagée.

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

• !cs -s -d <paramètre3> - informations de vidage sur cette section critique basées sur le contenu actuel de la structure d’informations de débogage trouvée dans la liste active (cette structure est rarement endommagée, donc généralement ces informations sont fiables).
• !cs -s <paramètre1> : informations de vidage sur cette section critique basées sur le contenu actuel de la structure de section critique (la structure est déjà endommagée si parfois ces informations ne sont pas fiables).
• paramètre dps4>< : pour identifier le chemin d’accès du code pour l’initialisation de cette section critique. Videz la section critique au paramètre1 de l’adresse et recherchez le modèle d’altération. Avec de bons symboles pour ntdll.dl, vous pouvez utiliser les commandes suivantes :
• dt ntdll !_RTL_CRITICAL_SECTION LOCK_ADDRESS
• dt ntdll !_RTL_CRITICAL_SECTION_DEBUG DEBUG_ADDRESS

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_CORRUPTED
• Arrêter le code : 0x205
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Thread de propriétaire de section critique non valide.

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

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

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_INVALID_OWNER
• Arrêter le code : 0x206
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_INVALID_RECURSION_COUNT
• Arrêter le code : 0x207
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_INVALID_LOCK_COUNT
• Arrêter le code : 0x208
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_OVER_RELEASED
• Arrêter le code : 0x209
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Section critique non initialisée.

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

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

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_NOT_INITIALIZED
• Arrêter le code : 0x210
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_ALREADY_INITIALIZED
• Arrêter le code : 0x211
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_IN_FREED_VMEM
• Arrêter le code : 0x212
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_IN_UNMAPPED_MEM
• Arrêter le code : 0x213
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Le thread actuel ne possède aucune section critique.

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

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

• Couche de test : Serrures
• ID d’arrêt : THREAD_NOT_LOCK_OWNER
• Arrêter le code : 0x214
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Serrures
• ID d’arrêt : LOCK_PRIVATE
• Arrêter le code : 0x215
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Le verrou SRW n’est pas initialisé.

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

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

• Couche de test : SRWLock
• ID d’arrêt : NOT_INITIALIZED
• Arrêter le code : 0x250
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Le verrou SRW est déjà initialisé.

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

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

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

• Couche de test : SRWLock
• ID d’arrêt : ALREADY_INITIALIZED
• Arrêter le code : 0x251
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Incompatibilité Acquire-Release sur le verrou SRW.

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

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

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

• Couche de test : SRWLock
• ID d’arrêt : MISMATCHED_ACQUIRE_RELEASE
• Arrêter le code : 0x252
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : SRWLock
• ID d’arrêt : RECURSIVE_ACQUIRE
• Arrêter le code : 0x253
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : SRWLock
• ID d’arrêt : EXIT_THREAD_OWNS_LOCK
• Arrêter le code : 0x254
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : SRWLock
• ID d’arrêt : INVALID_OWNER
• Arrêter le code : 0x255
• Sévérité: Avertissement
• Erreur ponctuelle : 
• Rapport d’erreurs : Aucun
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : SRWLock
• ID d’arrêt : IN_FREED_MEMORY
• Arrêter le code : 0x256
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : SRWLock
• ID d’arrêt : IN_UNLOADED_DLL
• Arrêter le code : 0x257
• Sévérité: Avertissement
• Erreur ponctuelle : 
• Rapport d’erreurs : Aucun
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Le verrou SRW est acquis sur le chemin d’arrêt qui peut entraîner un blocage.

Cet arrêt est généré si un verrou SRW (Param1) est acquis sur un chemin d’arrêt. Les verrous SRW ne sont pas conscients de l’arrêt. La tentative d’acquisition d’un verrou SRW orphelin (en raison de l’arrêt du processus ou d’une autre raison) entraîne un blocage. L’appel de ConditionVariableSRW sur un chemin d’arrêt peut également entraîner l’arrêt de ce vérificateur lorsque le verrou est libéré et acquis pendant cet appel. Pour déboguer cet arrêt :

• kb : pour obtenir la trace de la pile actuelle. C’est là que le verrou SRW est acquis sur un chemin d’arrêt.

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

• Couche de test : SRWLock
• ID d’arrêt : ACQUIRE_ON_SHUTDOWN_PATH
• Arrêter le code : 0x258
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

Cet arrêt est généré si la fonction située en haut de la pile a passé un handle non valide aux routines système. En règle générale, une commande kb simple révèle la valeur du handle passé (doit être l’un des paramètres , généralement le premier). Si la valeur est null, cela est clairement incorrect. Si la valeur semble ok, 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 du fait que la valeur de handle est utilisée après avoir été fermée.

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

• Couche de test : Poignées
• ID d’arrêt : INVALID_HANDLE
• Arrêter le code : 0x300
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

Cet arrêt est généré si la fonction située en haut de la pile a passé un index TLS non valide aux routines système TLS. En règle générale, une simple commande kb révélera ce qui est incorrect. Le bogue classique ici consiste à supposer une certaine valeur pour un index TLS au lieu d’appeler TlsAlloc. Cela peut se produire soit en pensant que vous obtenez toujours la valeur N, il n’est donc pas nécessaire d’appeler TlsAlloc ou plus fréquemment en raison d’une variable non initialisée.

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

• Couche de test : Poignées
• ID d’arrêt : INVALID_TLS_VALUE
• Arrêter le code : 0x301
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Paramètres non valides pour l’appel WaitForMultipleObjects.

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

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

• Couche de test : Poignées
• ID d’arrêt : INCORRECT_WAIT_CALL
• Arrêter le code : 0x302
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Poignées
• ID d’arrêt : NULL_HANDLE
• Arrêter le code : 0x303
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Attente d’un handle de thread dans DllMain.

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

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

• Couche de test : Poignées
• ID d’arrêt : WAIT_IN_DLLMAIN
• Arrêter le code : 0x304
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Type d’objet incorrect pour handle.

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

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

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

• Couche de test : Poignées
• ID d’arrêt : INCORRECT_OBJECT_TYPE
• Arrêter le code : 0x305
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : TLS
• ID d’arrêt : TLS_LEAK
• Arrêter le code : 0x350
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Structure TLS du vérificateur endommagé.

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

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

• Couche de test : TLS
• ID d’arrêt : CORRUPTED_TLS
• Arrêter le code : 0x351
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Utilisation d’un index TLS non valide.

Cet arrêt est généré si un index TLS non valide est utilisé. Dans la plupart des cas, c’est parce que le code utilise toujours cet index lorsque TlsFree est appelé. Voici un exemple pour le thread de thread de thread. T1 : Chargements de dll et TlsAlloc T1 : Rappel de file d’attente T1 : Rappel attendu/annulé T1 : TlsFree T2 : Exécutions de rappel et appels TlsSetValue T1 : Dll déchargées

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

• Couche de test : TLS
• ID d’arrêt : INVALID_TLS_INDEX
• Arrêter le code : 0x352
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : INVALID_FREEMEM
• Arrêter le code : 0x600
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Appel d’alloc virtuel incorrect.

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

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

• Couche de test : Mémoire
• ID d’arrêt : INVALID_ALLOCMEM
• Arrêter le code : 0x601
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Appel d’affichage de carte incorrect.

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

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

• Couche de test : Mémoire
• ID d’arrêt : INVALID_MAPVIEW
• Arrêter le code : 0x602
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Détection d’une adresse non valide.

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

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

• Couche de test : Mémoire
• ID d’arrêt : PROBE_INVALID_ADDRESS
• Arrêter le code : 0x603
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Détection de la mémoire libre.

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

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

• Couche de test : Mémoire
• ID d’arrêt : PROBE_FREE_MEM
• Arrêter le code : 0x604
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Détection d’une page de garde.

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

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

• Couche de test : Mémoire
• ID d’arrêt : PROBE_GUARD_PAGE
• Arrêter le code : 0x605
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Détection de l’adresse NULL.

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

int main (void)
{
PVOID p;

p = malloc (1024);
Use (p);

return 0;
}

void Use (PVOID p)
{
if (IsBadReadPtr (p)) {
return;
}

//
// p is safe to be used here.
//
}

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

int main (void)
{
PVOID p;

p = malloc (1024);
if (NULL == p)) {
return -1;
}

Use (p);

return 0;
}

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : PROBE_NULL
• Arrêter le code : 0x606
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : PROBE_INVALID_START_OR_SIZE
• Arrêter le code : 0x607
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : INVALID_DLL_RANGE
• Arrêter le code : 0x608
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : FREE_THREAD_STACK_MEMORY
• Arrêter le code : 0x609
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : INVALID_FREE_TYPE
• Arrêter le code : 0x60A
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : MEM_ALREADY_FREE
• Arrêter le code : 0x60B
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : INVALID_FREE_SIZE
• Arrêter le code : 0x60C
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

• du <parameter1> : pour afficher le nom de la DLL ;
• .exr <parameter2> : pour afficher les informations d’exception ;
• Paramètre .cxr3>< suivi de kb - pour afficher les informations de contexte d’exception et la trace de pile pour l’heure à laquelle l’exception a été levée ;
• < parameter4> est l’adresse d’une structure de vérificateur interne et n’a aucune importance pour la plupart des utilisateurs du vérificateur.

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

• Couche de test : Mémoire
• ID d’arrêt : DLL_UNEXPECTED_EXCEPTION
• Arrêter le code : 0x60D
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : THREAD_UNEXPECTED_EXCEPTION
• Arrêter le code : 0x60E
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

• < paramètre1> sera généralement C0000005 et cela signifie que violation d’accès ;
• .exr <parameter2> : pour afficher les informations d’exception ;
• Paramètre .cxr3>< suivi de kb pour afficher les informations de contexte d’exception et la trace de pile au moment où l’exception a été levée.

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

• Couche de test : Mémoire
• ID d’arrêt : PROBE_UNEXPECTED_EXCEPTION
• Arrêter le code : 0x60F
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Essayez de réinitialiser l’adresse NULL.

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

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

• Couche de test : Mémoire
• ID d’arrêt : INVALID_MEM_RESET
• Arrêter le code : 0x610
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : FREE_THREAD_STACK_MEMORY_AS_HEAP
• Arrêter le code : 0x612
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : FREE_THREAD_STACK_MEMORY_AS_MAP
• Arrêter le code : 0x613
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Adresse RTL_RESOURCE incorrecte.

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

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

• Couche de test : Mémoire
• ID d’arrêt : INVALID_RESOURCE_ADDRESS
• Arrêter le code : 0x614
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Adresse de section critique non valide.

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

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

• Couche de test : Mémoire
• ID d’arrêt : INVALID_CRITSECT_ADDRESS
• Arrêter le code : 0x615
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : THREAD_UNEXPECTED_EXCEPTION_CODE
• Arrêter le code : 0x616
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : OUTBUFF_UNEXPECTED_EXCEPTION
• Arrêter le code : 0x617
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : SIZE_HEAP_UNEXPECTED_EXCEPTION
• Arrêter le code : 0x618
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : INVALID_FREEMEM_START_ADDRESS
• Arrêter le code : 0x619
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : INVALID_UNMAPVIEW_START_ADDRESS
• Arrêter le code : 0x61A
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : THREADPOOL_UNEXPECTED_EXCEPTION
• Arrêter le code : 0x61B
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

code dans la mémoire non exécutable

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

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

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

• Couche de test : Mémoire
• ID d’arrêt : THREADPOOL_UNEXPECTED_EXCEPTION_CODE
• Arrêter le code : 0x61C
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Création d’un tas exécutable.

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

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

• Couche de test : Mémoire
• ID d’arrêt : EXECUTABLE_HEAP
• Arrêter le code : 0x61D
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Allocation de mémoire exécutable.

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

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

• Couche de test : Mémoire
• ID d’arrêt : EXECUTABLE_MEMORY
• Arrêter le code : 0x61E
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

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

• Couche de test : Exceptions
• ID d’arrêt : FIRST_CHANCE_ACCESS_VIOLATION_CODE
• Arrêter le code : 0x650
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Threadpool
• ID d’arrêt : INCONSISTENT_PRIORITY
• Arrêter le code : 0x700
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Threadpool
• ID d’arrêt : INCONSISTENT_AFFINITY_MASK
• Arrêter le code : 0x701
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Threadpool
• ID d’arrêt : ORPHANED_THREAD_MESSAGE
• Arrêter le code : 0x702
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Threadpool
• ID d’arrêt : ORPHANED_THREAD_WINDOW
• Arrêter le code : 0x703
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

ExitThread() sur un thread de thread.

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

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

• Couche de test : Threadpool
• ID d’arrêt : ILLEGAL_THREAD_EXIT
• Arrêter le code : 0x704
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Threadpool
• ID d’arrêt : THREAD_IN_IMPERSONATION
• Arrêter le code : 0x705
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Threadpool
• ID d’arrêt : PERSISTED_THREAD_NEEDED
• Arrêter le code : 0x706
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Le thread est dans un état de transaction incorrect.

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

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

• Couche de test : Threadpool
• ID d’arrêt : DIRTY_TRANSACTION_CONTEXT
• Arrêter le code : 0x707
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Threadpool
• ID d’arrêt : DIRTY_COM_STATE
• Arrêter le code : 0x708
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Threadpool
• ID d’arrêt : INCONSISTENT_TIMER_PARAMS
• Arrêter le code : 0x709
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Threadpool
• ID d’arrêt : LOADER_LOCK_HELD
• Arrêter le code : 0x70A
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Threadpool
• ID d’arrêt : PREFERRED_LANGUAGES_SET
• Arrêter le code : 0x70B
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Threadpool
• ID d’arrêt : BACKGROUND_PRIORITY_SET
• Arrêter le code : 0x70C
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

TerminateThread() sur un thread de thread.

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

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

• Couche de test : Threadpool
• ID d’arrêt : ILLEGAL_THREAD_TERMINATION
• Arrêter le code : 0x70D
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

La pile a été dérouillée lorsque l’opération d’E/S asynchrone est en attente.

Cet arrêt est généré si l’application a émis une opération d’E/S qui utilise une variable de pile et n’a pas attendu la fin de l’E/S, ce qui entraîne une altération de la pile. Pour déboguer cet arrêt :

• paramètre dps4>< pour afficher la trace de pile lorsque l’E/S a été émise. Le paramètre1 indique l’adresse basée sur la pile et le paramètre3 du thread qui a émis les E/S.

• Paramètre 1 - Adresse de la variable de pile utilisée dans l’E/S.
• Paramètre 2 - Pointeur de pile actuel.
• Paramètre 3 -Thread  d’origine qui a émis les E/S.
• Paramètre 4 - Stack Trace lorsque l’E/S a été émise.

• Couche de test : IO
• ID d’arrêt : ASYNCIO_STACK_UNWIND
• Arrêter le code : 0x800
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

La pile a été endommagée lorsque l’opération d’E/S asynchrone est en attente.

Cet arrêt est généré si l’application a émis une opération d’E/S qui utilise une variable de pile et n’a pas attendu la fin de l’E/S, ce qui entraîne une altération de la pile. Pour déboguer cet arrêt :

• paramètre dps4>< pour afficher la trace de pile lorsque l’E/S a été émise. Le paramètre1 indique l’adresse basée sur la pile et le paramètre3 du thread qui a émis les E/S.

• Paramètre 1 - Adresse de la variable de pile utilisée dans l’E/S.
• Paramètre 2 - Pointeur de pile actuel.
• Paramètre 3 -Thread  d’origine qui a émis les E/S.
• Paramètre 4 - Stack Trace lorsque l’E/S a été émise.

• Couche de test : IO
• ID d’arrêt : ASYNCIO_CORRUPTED_STACK
• Arrêter le code : 0x801
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Utilisation d’une adresse libérée dans une opération d’E/S en attente.

Cet arrêt est généré si l’application a émis une opération d’E/S et libéré la mémoire utilisée dans l’E/S avant que l’E/S soit terminée, ce qui entraîne une altération de la mémoire, etc. Pour déboguer cet arrêt :

• paramètre dps4>< : pour afficher la trace de pile lorsque l’E/S a été émise. Le paramètre1 indique l’adresse utilisée dans l’E/S. Le paramètre2 indique la libération de l’adresse et le paramètre3 du thread qui a émis les E/S.

• Paramètre 1 - Adresse utilisée dans l’E/S.
• Paramètre 2 - Adresse libérée.
• Paramètre 3 -Thread  d’origine qui a émis les E/S.
• Paramètre 4 - Stack Trace lorsque l’E/S a été émise.

• Couche de test : IO
• ID d’arrêt : FREED_ADDRESS_IN_PENDINGIO
• Arrêter le code : 0x802
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Un bloc d’état d’E/S (CHEVAUCHEMENT) est réutilisé alors que la requête d’E/S associée est toujours en attente.

Cet arrêt est généré si l’application a réutilisé un bloc d’état d’E/S (CHEVAUCHEMENT) alors qu’une demande d’E/S utilisant ce bloc d’état d’E/S (CHEVAUCHEMENT) est toujours en attente. Pour déboguer cet arrêt :

• paramètre dps3>< pour afficher la trace de pile lorsque l’E/S d’origine a été émise. Le paramètre1 indique l’adresse utilisée dans l’E/S et le paramètre2 du thread qui a émis l’E/S.

• Paramètre 1 - Adresse du bloc d’état d’E/S (CHEVAUCHEMENT).
• Paramètre 2 -Thread  d’origine qui a émis les E/S.
• Paramètre 3 - Stack Trace lorsque l’E/S a été émise.
• Paramètre 4 - Non utilisé.

• Couche de test : IO
• ID d’arrêt : REUSED_IOSTATUS_BLOCK
• Arrêter le code : 0x803
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Utilisation d’un indicateur non pris en charge, FILE_ATTRIBUTE_NOT_CONTENT_INDEXED sur CreateFile

Ancienne version de MSDN documentée par erreur CreateFile comme prise en charge FILE_ATTRIBUTE_NOT_CONTENT_INDEXED. Si cet indicateur est prévu, il doit être défini à l’aide d’autres fonctions d’API telles que SetFileAttributes.

• ln <parameter1> : pour rechercher l’appelant de CreateFile.

• Format: -  CreateFile lors de l’écriture de %hs%ws avec des indicateurs %08x %08x %08x
• Paramètre 1 - Adresse de retour.
• Paramètre 2 - Non utilisé.
• Paramètre 3 - Non utilisé.
• Paramètre 4 - Non utilisé.

• Couche de test : IO
• ID d’arrêt : USING_BAD_CREATEFILE_FLAG
• Arrêter le code : 0x804
• Sévérité: Avertissement
• Erreur ponctuelle : 
• Rapport d’erreurs : Aucun
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Fuite
• ID d’arrêt : ALLOCATION
• Arrêter le code : 0x900
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Un HANDLE a été fui.

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

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

• Couche de test : Fuite
• ID d’arrêt : MANCHE
• Arrêter le code : 0x901
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Fuite
• ID d’arrêt : REGISTRE
• Arrêter le code : 0x902
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Fuite
• ID d’arrêt : VIRTUAL_RESERVATION
• Arrêter le code : 0x903
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Une BSTR a été divulguée.

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

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

• Couche de test : Fuite
• ID d’arrêt : SYSSTRING
• Arrêter le code : 0x904
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

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

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

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

• Couche de test : Fuite
• ID d’arrêt : POWER_NOTIFICATION
• Arrêter le code : 0x905
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Une allocation COM a été divulguée.

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

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

• Couche de test : Fuite
• ID d’arrêt : COM_ALLOCATION
• Arrêter le code : 0x906
• Sévérité: Erreur
• Erreur ponctuelle : 
• Rapport d’erreurs : Casser
• Connectez-vous au fichier : oui
• Créer un backtrace : oui

Voir aussi

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

Vérificateur d’application - Vue d’ensemble

Vérificateur d’application - Fonctionnalités

Vérificateur d’application - Test d’applications

Vérificateur d’application - Tests au sein du vérificateur d’application

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

Vérificateur d’application - Forum aux questions