Vérificateur d’application - Questions fréquentes (FAQ)

Article
10/23/2024

Questions générales

Voici une liste de questions reçues concernant l’utilisation générale du vérificateur d’application.

Qu’est-ce que le vérificateur d’application ?

Application Verificationr est un outil de vérification d’exécution utilisé pour rechercher des bogues dans Microsoft Windows-applications. Étant donné qu’il s’agit d’un outil d’exécution, le code de l’application doit être exercé pour être vérifié. Une bonne couverture de test est donc essentielle.

Le scénario d’utilisation classique du vérificateur d’application consiste à l’activer pour les applications intéressantes (consultez les questions ci-dessous pour savoir comment procéder), puis exécuter tous les tests que vous avez écrits pour votre application. Vous recevrez une notification pour tout bogue trouvé sous la forme d’un saut de débogueur ou d’une entrée de journal de vérificateur.

Comment faire désinstaller Application Verifier ?

Pour désinstaller le vérificateur d’application, accédez au panneau de configuration en cliquant sur Démarrer, sélectionnez Ajouter ou supprimer des programmes, puis Supprimez un programme, cliquez sur Vérificateur d’application, puis cliquez sur Supprimer.

Comment faire démarrer le vérificateur d’application ?

Après avoir installé Application Verifier, vous pouvez le démarrer en l’accédant à votre liste de programmes OU en tapant Appverif.exe sur une ligne de commande. Pour ce faire, accédez à une invite de commandes ou à la zone Exécuter du menu Démarrage. Tapez appverif.exe, puis appuyez sur Entrée. Le vérificateur d’application démarre.

Le fichier binaire Appverifer.exe est installé dans le répertoire système et sert à définir les paramètres de l’outil.

Où sont stockés les journaux ?

Les journaux sont stockés dans %USERPROFILE%\AppVerifierLogs

Que dois-je faire si j’ai des problèmes lors de l’utilisation du vérificateur d’application ?

Vérifiez que vous exécutez la dernière version. Envisagez d’essayer la même application sur un autre PC ou même une version de Windows.

Application Verifyr vérifie-t-il le code managé ?

AppVerifier s’intéresse aux interfaces entre le système d’exploitation et l’application. Par conséquent, sauf si votre code managé effectue une interopérabilité sur des API natives qui doivent être associées aux segments de mémoire, aux handles, à la section critique, etc. vos cas de test ne vous donnent aucune interaction avec les interfaces vérifiées.

Nous vous recommandons d’utiliser les Assistants de débogage managé pour vérifier votre code managé. Pour plus d’informations, consultez débogage de code managé à l’aide du débogueur Windows.

ARM64EC est-il pris en charge ?

Application Verifier ne prend pas en charge ARM64EC.

Questions sur le débogueur

Voici la liste des questions reçues concernant le débogueur.

Pourquoi ai-je reçu une erreur me disant que j’ai besoin d’un débogueur ?

La couche de vérification de base dans Application Verificationr nécessite que vous exécutiez votre application sous un débogueur. Si vous n’avez pas de débogueur associé à l’application avant de sélectionner le test, vous recevrez une boîte de dialogue vous rappelant que vous devrez exécuter votre application sous un débogueur pour obtenir les informations journalisées.

Comment faire exécuter mon application sous un débogueur ?

Consultez les rubriques d’installation et d’installation du débogueur - Prise en main du débogage Windows

Comment faire’extension de pile de test sans aucune autre instrumentation ?

En règle générale, l’expansion de la pile doit être vraiment testée en isolation à partir d’autres couches de vérification, y compris le tas. La raison est la suivante : chaque couche de vérification « thunks » une API ou un point exporté avec une routine.

Par exemple, un appel à CreateFileA sera un appel à appvocre ! NS_SecurityChecks ::CreateFileA, qui peut appeler appvcore ! NS_FillePaths ::CreateFileA qui peut appeler kernel32 ! CreateFileA, qui peut appeler le vérificateur ! AVrfpNtCreateFile, qui appellera ntdll ! NtCreateFile. Vous pouvez voir que l’instrumentation a ajouté 3 appels de fonction « empilés », chacun d’entre eux peut consommer plus de pile.

Dans le cas ci-dessous, la LH-verifier.dll est « thunking » chaque DllMain, et le chemin de code du tas « instrumenté » ajoute davantage d’utilisation de la pile. Étant donné que le thread injecté à partir du débogueur n’utilise pas les valeurs par défaut IMAGE_NT_HEADERS, la pile initialement validée n’est pas suffisante pour terminer l’état APC d’un thread (un thread dans l’état APC a exécuté le code d’initialisation).

Si vous souhaitez utiliser Stack-Ckecs, probablement la seule autre couche de vérification que vous devez utiliser si FirstChanceAccessViolation.

Lorsque vous utilisez l’extension !avrf, j’obtiens « Le vérificateur d’application n’est pas activé pour ce processus... »

Erreur complète reçue : Application verifier is not enabled for this process. Use appverif.exe tool to enable it.

Vous avez probablement uniquement les couches de vérification shim activées et/ou le tas en mode « pur » activé. Voici quelques-unes des causes possibles.

Questions sur les scénarios de test

Voici une liste de questions reçues autour de différents scénarios de test.

Comment puis-je activer le vérificateur d’application sur mon service, mais pas d’autres ?

Effectuez une copie de svchost.exe dans le répertoire System32 et appelez la copie « Mysvchost.exe ».

À l’aide de regedit, ouvrez HKLM\System\CurrentControlSet\Services\MyService.

Modifiez la valeur « ImagePath », qui sera semblable à « %SystemRoot%\system32\svchost.exe -k myservice » et remplacez svchost.exe par « Mysvchost.exe ».

Ajoutez « Mysvchost.exe » à la liste AppVerifier et vérifiez les tests souhaités.

Redémarrage.

Comment faire exécuter Application Verifier sur une application 64 bits lancée à partir d’une application 32 bits s’exécutant sous WOW64 ?

Version simple : la règle d’or pour activer les paramètres du vérificateur sur une application donnée est de faire correspondre le niveau de bits de l’outil et du processus cible. Autrement dit, utilisez la appverif.exe 32 bits pour une application 32 bits (exécutée sous WoW64) et utilisez la AppVerif.exe 64 bits pour la cible native 64 bits.

Version longue : les paramètres du vérificateur d’application sont l’union appropriée des paramètres « core » et des paramètres « shim ».

Paramètres principaux : les paramètres principaux sont stockés sous options d’exécution de fichier d’image.

La valeur « Débogueur » est lue à partir de l’application de lancement. Par conséquent, si vous souhaitez avoir des devenv.exe 32 bits qui lancent des my.exe 64 bits et qu’elles s’exécutent sous le débogueur, vous devez utiliser la clé de Registre 32 bits sous WoW6432Node. Les autres valeurs, pour un processus 32 bits, sont lues à partir des deux emplacements, à la fois l’IFEO natif et le WoW6432Node.

Le raisonnement est le suivant : un processus 32 bits exécuté sous WoW est un processus 64 bits exécutant la boucle d’émulation Wow64. Ainsi, chaque processus 32 bits est d’abord un processus 64 bits, puis un processus 32 bits. L’IFEO 64 bits active le vérificateur sur le code Wow64cpu.dll, tandis que l’IFEO 32 bits active le vérificateur sur le code 32 bits.

Du point de vue de l’utilisateur final, verifier.dll est chargé deux fois (une fois dans le monde 64 bits, une fois dans le monde 32 bits). Étant donné que la plupart des gens ne s’intéressent pas à la vérification de wow64cpu.dll, le comportement le plus accepté pour les processus 32 bits consiste à vérifier uniquement la partie 32 bits. C’est pourquoi la règle d’or de « toujours correspondre au bit-ness » s’applique.

Comment faire déboguer mon service qui s’exécute dans une station de fenêtre non interactive

Pour déboguer un service qui s’exécute dans une station de fenêtre non interactive, procédez comme suit (s’applique uniquement si vous utilisez ntsd/windbg) :

Ajoutez une clé au Registre sous HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options. Le nom de cette clé doit être le nom du processus (service.exe).

Créez une valeur REG_SZ appelée Débogueur et définissez cette valeur sur le chemin d’accès où réside votre débogueur. Il doit contenir le chemin d’accès complet, pas seulement le nom du débogueur. La commande doit inclure l’option –server et une plage de ports spécifique sur laquelle le débogueur doit écouter. Par exemple, c :\debuggers\ntsd.exe –server tcp :port=5500:5600 –g –G.

Connectez-vous au serveur du débogueur en exécutant le débogueur avec une option –remote. Par exemple, windbg.exe –remote tcp :=localhost,port=55xx où 'xx' est un nombre compris entre 00 et 99 si vous avez utilisé une plage sur le serveur.

AppVerifier effectue-t-il la détection des fuites ? Sous Windows 7 et versions ultérieures, il existe une option de vérification des fuites qui détecte lorsqu’un processus fuit la mémoire. Sous les systèmes d’exploitation précédents, AppVerifier ne teste pas l’application pour détecter les fuites, mais recherche d’autres problèmes de mémoire.

Quels tests sont recommandés pour les problèmes de sécurité ?

Heaps
Descripteurs
Verrous
Piles (uniquement pour les services et les processus importants qui peuvent descendre la machine)

N’oubliez pas que ObsoleteAPICalls génère simplement un avertissement pour chaque appel qu’il voit à une API répertoriée comme obsolète ou déconseillée dans MSDN. Vous devez décider d’un cas par cas s’il est important que votre application bascule vers les nouvelles API. Certaines API sont dangereuses, et certaines ont simplement été remplacées par une API plus récente avec plus d’options. Consultez la section « API dangereuses » de l’écriture de code sécurisé, 2e ajout pour plus d’informations.

Pour les applications qui doivent être hautement fiables, comme les services et les programmes serveur, vous devez également activer la vérification des piles. Cette vérification vérifie si la taille de validation de la pile est adéquate, en désactivant la croissance de la pile. Si l’application quitte immédiatement avec un dépassement de capacité de pile, cela signifie que l’application doit être recompilée avec une plus grande taille de validation de pile. Si vous êtes testeur et que vous rencontrez un problème avec une application lors de l’utilisation de la vérification Stacks, déposez un bogue, affectez-le à votre développeur et continuez à tester.

Questions spécifiques sur les tests

Voici une liste de questions sur les tests. Cliquez sur la question pour voir la réponse :

Les fuites de section critiques sont-elles importantes ?

Chaque fois que vous fuitez une section critique, vous fuitez les éléments suivants : un handle d’événement, une petite quantité de pool de noyau et une petite allocation de tas. Celles-ci seront nettoyées si le processus s’arrête.

Si votre processus est censé rester vivant longtemps, ces fuites peuvent vous mordre. Étant donné que les correctifs sont très faciles dans 99 % des cas (le développeur vient d’oublier d’appeler RtlDeleteCriticalSection) vous devez les traiter.

Pouvons-nous traiter par programmation des dépassements de capacité de pile ?

L’établissement d’un gestionnaire d’exceptions dans la fonction de thread initiale n’est pas garanti pour intercepter les dépassements de capacité de pile potentiels susceptibles d’être déclenchés. Cela est dû au fait que le code qui répartit les exceptions a également besoin d’un peu de pile pour s’exécuter au-dessus de l’enregistrement d’activation actuel. Étant donné que nous venons d’échouer l’extension de pile, il est très probable que nous allons passer à la fin de la pile validée et déclencher une deuxième exception lors de la tentative de distribution du premier. Une exception de double erreur met fin au processus de manière inconditionnelle.

Le test LoaderLock donne une erreur sur l’appel de DestroyWindow. Pourquoi ne puis-je pas appeler DestroyWindow dans DllMain ? Vous ne contrôlez pas le thread qui va se détacher. Si ce n’est pas le même thread que celui qui a créé la fenêtre, vous ne pouvez pas détruire la fenêtre. Ainsi, vous fuitez la fenêtre et la prochaine fois que la fenêtre reçoit un message, vous plantez parce que le Wndproc a été déchargé.

Vous devez détruire la fenêtre avant d’obtenir le processus de détachement. Le danger n’est pas que l’utilisateur32 sera déchargé. Le danger est que vous êtes déchargé. Par conséquent, le message suivant que la fenêtre reçoit bloque le processus, car l’utilisateur32 remet le message à votre Wndproc qui n’existe plus.

Le système d’exploitation Microsoft Windows a une affinité de thread. Le détachement du processus n’est pas le cas. Le verrou du chargeur n’est pas vraiment le gros problème ; le problème est Dllmain. Le détachement de processus est la dernière fois que votre DLL est en train d’exécuter du code. Vous devez vous débarrasser de tout avant de retourner. Toutefois, étant donné que Windows a une affinité de thread, vous ne pouvez pas nettoyer la fenêtre si vous êtes sur le mauvais thread.

Le verrou du chargeur entre dans l’image si quelqu’un a un crochet global installé (par exemple, spy++ est en cours d’exécution). Dans ce cas, vous entrez un scénario d’interblocage potentiel. Là encore, la solution consiste à détruire la fenêtre avant d’obtenir le détachement du processus.

Est-il coûteux d’augmenter les validations de pile initiales pour éviter les dépassements de capacité ?

Lorsque vous validez la pile, vous réservez simplement de l’espace de fichier de page. Il n’y a aucun impact sur les performances. Aucune mémoire physique n’est réellement utilisée. Le seul coût supplémentaire se produit si vous touchez réellement l’espace de pile que vous avez validé. Mais cela se produit de toute façon même si vous ne validez pas la pile avant.

Voyons ce qui serait le coût pour que tous les services s’exécutent dans svchost.exe à puces. Sur une machine de test, j’obtiens 9 processus svchost.exe ayant un total de 139 threads. Si nous définissons la pile par défaut pour chaque thread à 32 Ko, nous aurons besoin d’environ 32 00 x 200 ~ 6,4 Mo d’espace de fichier de page pour valider toutes les piles avant.

C’est un très petit prix à payer pour la fiabilité.

Qu’en est-il de la taille de la pile réservée ?

Il existe des éléments intéressants, tels que la répartition des exceptions sur IA64/AMD64, qui nécessitent une pile supplémentaire « inattendue ». Il peut y avoir un certain traitement sur des threads de travail RPC dont les exigences de pile sont passées à des tentatives raisonnables de les mesurer.

Tout d’abord, vous devez avoir une idée de tous les pools de threads vivant dans le processus. Le pool de threads NT, avec les threads alertable-wait-threads est parfois spécial, car, par exemple, si vous utilisez un composant de base de données à partir de SQL, il utilise des veilles alertables sur un thread qui est une cible de user-APC. Cela peut entraîner des problèmes liés aux appels imbriqués.

Une fois que vous connaissez tous les pools de threads, découvrez comment contrôler leurs exigences de pile. Par exemple, RPC lit une clé de Registre pour la validation de la pile. Les threads de pompe WDM obtiennent cela à partir de l’image. Pour les autres pools de threads, le kilométrage peut varier.

Lorsque tous les threads sont clairs, vous pouvez effectuer une action. Le fait de ne pas avoir d’espace réservé énorme aide à résoudre la fragmentation de l’espace uniquement si les threads viennent et vont très souvent. Si vous disposez d’un pool de threads stable qui se trouve dans votre contrôle, vous pouvez également avoir un avantage pour réduire l’espace réservé. Il aidera vraiment à économiser de l’espace d’adressage pour les tas et l’espace d’adressage pour les utilisateurs.

Existe-t-il des recommandations sur la façon de choisir la taille appropriée pour LINKER_STACKCOMMITSIZE= ?

La valeur doit être divisible par la taille de la page (4k/8k en fonction du processeur). Voici quelques instructions pour déterminer la taille dont vous avez besoin :

Convertissez toutes les fonctions récursives avec une profondeur potentielle non liée (ou au moins une profondeur élevée inductible par l’utilisateur) en itérative.
Réduisez l’utilisation d’alloca. Utilisez le tas ou safealloca.
Exécutez Prefast avec une vérification de taille de pile réduite (par exemple, 8 ko). Corrigez ces fonctions marquées comme utilisant trop de pile.
Définissez la validation de la pile sur 16 000.
Exécutez un groupe de tests sous un débogueur avec la vérification « Stacks » de Application Verifier.
Lorsque vous voyez un dépassement de capacité de pile, déterminez les pires délinquants et corrigez-les. (Voir l’étape 5.)
Lorsque vous ne pouvez pas réduire l’utilisation de la pile plus de 8 ko. Si vous êtes > 64k il ya quelque chose de mal, diminuez à 64k et voyez l’étape 6. Sinon, passez à l’étape 5.

Quelles sont les exigences en mémoire pour le test de tas ?

Pour les tests de tas complets, vous aurez besoin de 256 Mo de RAM et au moins d’un fichier de page de 1 Go. Pour les tests de tas normaux, vous aurez besoin d’au moins 128 Mo de RAM. Il n’existe aucune configuration requise spécifique pour le processeur ou le disque.

Pourquoi est-ce que je reçois un arrêt ALL_ACCESS ?

Toute application qui utilise _ALL_ACCESS restitue l’objet auquel il accède, car le journal d’audit ne reflète pas ce que vous avez réellement fait avec l’objet, uniquement ce que vous avez demandé à faire avec l’objet.

Cette condition crée un camouflage pour une attaque plus deveuse. L’analyse par l’administrateur d’une activité d’attaque en cours ne voit rien de mal avec la personne demandant ALL_ACCESS sur la clé X, car une application particulière le fait toujours. L’administrateur pense que « la personne est probablement juste en cours d’exécution de Word ». L’administrateur ne peut pas dire qu’un pirate a pénétré mon compte et est maintenant à l’étude du système pour déterminer quel accès j’ai, qu’il peut exploiter pour ses fins malveillantes. Les possibilités sont infinies.

Le problème de liste de contrôle d’accès avec ALL_ACCESS est que vous devez toujours l’accorder. Si nous voulions refuser un jour l’accès DELETE à une certaine clé, nous ne pouvons pas le faire. Même si vous n’avez pas réellement supprimé la clé, nous cassons votre application, car vous demanderiez l’accès à la suppression.

Pourquoi ne reçois-je pas de journaux d’activité à partir du tas et des tests de verrouillage ?

Ces tests sont des couches de vérification intégrées au système opérationnel (et non dans le package) et signalent des erreurs dans un débogueur. Si vous exécutez une application avec ces tests activés et n’avez aucun plantage, ils ne signalent aucun problème.

Si vous rencontrez des incidents, il sera nécessaire de s’exécuter sous un débogueur ou de passer l’application à un développeur pour tester plus étroitement.

Pourquoi l’injection d’erreurs ne fonctionne-t-elle pas ?

La probabilité d’injection d’erreur a été modifiée en parties par million dans les builds AppVerifier publiées après février 2007 en fonction des commentaires des clients. Ainsi, une probabilité de 0n20000 est de 2 %, 0n500000 est de 50 % et ainsi de suite.

!avrf –flt extension de débogueur peut être utilisée pour modifier la probabilité à la volée dans le débogueur. Toutefois, la vérification de la simulation de faible ressource pour le processus doit être activée pour que cela fonctionne.

!avrf extension de débogueur fait partie exts.dll fournie avec le package de débogueur. Les modifications apportées à !avrf qui prennent en charge le changement de probabilité se trouvent dans le dernier package de débogueur. Si vous rencontrez des problèmes liés à l’injection d’erreurs, mettez à jour vos débogueurs et le package AppVerifier.

Pourquoi le vérificateur de fuites ne signale-t-il pas certaines fuites de ressources ?

Le vérificateur de fuite ne signale aucune fuite de ressource pendant le chargement d’une DLL ou d’un module EXE. Lorsqu’un module est déchargé, le vérificateur de fuite émet un arrêt si l’une des ressources allouées par le module n’a pas été publiée.

Pour inspecter les ressources allouées par une DLL ou EXE chargée, utilisez l’extension de débogueur !avrf -leak.