Partager via

Application Verifier (Livre de recettes sur la qualité des applications Windows 7 et Windows Server 2008 R2)

  • Article

Plateformes affectées

Clients : Windows XP, Windows Vista, Windows 7
Serveurs : Windows Server 2003, Windows Server 2008, Windows Server 2008 R2

Description

Promouvez et appliquez Application Verifier comme porte de qualité pour tout le développement. Il comprend plusieurs améliorations :

  • Nous avons fourni des vérifications supplémentaires pour résoudre les problèmes détectés par l’équipe Rapport d’erreurs Windows lors de l’utilisation du pool de threads.
  • Nous avons combiné les versions 32 et 64 bits du package pour traiter les modifications apportées à Windows 7, notamment les besoins de test des composants 32 bits sous une version 64 bits de Windows, ainsi que pour la simplification générale.
  • Nous avons inclus des vérifications supplémentaires pour les applications multithreads, l’exécution d’applications 32 bits sur Windows 64 bits, ainsi que de nombreux correctifs de bogues.

Ces modifications ne doivent pas avoir d’impact négatif sur les utilisateurs qui n’activent pas les vérifications de threads. Ceux qui le font doivent recevoir une prise en charge supplémentaire dans la découverte et le diagnostic des problèmes d’utilisation de pool de threads existants. Que vous activiez ou non les vérifications de threads, vous bénéficiez des autres améliorations et correctifs de bogues dans ce service.

Même s’il existe une légère pénalité de performances lors de l’utilisation de ce service, les niveaux de performances doivent rester acceptables, car il ne s’exécute généralement pas dans des environnements de vente au détail.

Utilisation

Informations générales

Pour fournir des applications Windows fiables :

  1. Testez les applications écrites dans du code non managé (natif) avec Application Verifier sous le débogueur et avec un tas de page entier avant de le publier aux clients.
  2. Suivez les étapes fournies par Application Verifier pour résoudre les conditions errantes.
  3. Une fois votre application publiée, surveillez régulièrement les rapports d’échec de l’application collectés par le Rapport d’erreurs Windows.

Les vérifications de pool de threads sont activées par défaut sous l’en-tête de vérification « De base ». Comme cela est inclus dans le paramètre par défaut, les utilisateurs doivent uniquement exécuter Application Verifier sur leur code avec les paramètres par défaut pour tirer parti des nouvelles vérifications.

Détails

Au minimum, vous devez exécuter Application Verifier avec le paramètre De base sélectionné. Cela est requis pour WinLogo et WinQual. Le paramètre De base vérifie les éléments suivants :

  • Détails d’arrêt des exceptions : garantit que les applications ne masquent pas les violations d’accès à l’aide de la gestion structurée des exceptions
  • Détails d’arrêt des handles : effectue des tests pour vérifier que l’application ne tente pas d’utiliser des handles non valides
  • Détails d’arrêt du tas : vérifie des problèmes d’altération des données de la mémoire dans le tas
  • Détails d’arrêt d’entrée/sortie : surveille l’exécution d’E/S asynchrones et effectue différentes validations
  • Détails d’arrêt des fuites : détecte les fuites en suivant les ressources effectuées par une dll qui ne sont pas libérées au moment où la dll a été déchargée
  • Détails d’arrêt des verrous : vérifie l’utilisation correcte pour les sections critiques
  • Détails d’arrêt de la mémoire : garantit que les API pour les manipulations d’espace virtuel sont utilisées correctement (par exemple, VirtualAlloc, MapViewOfFile)
  • Détails d’arrêt du protocole TLS : garantit que les API de stockage local de threads sont utilisées correctement
  • Détails d’arrêt de pool de threads : garantit l’utilisation correcte des API de pool de threads et applique des vérifications de cohérence sur les états worker-thread après un rappel

Si votre application migre à partir d’une application « Pre-Vista », vous souhaiterez tirer parti de l’option « LuaPriv » (également appelée vérifications UAC). Le prédicteur de privilèges de compte d’utilisateur limité (LuaPriv) a deux objectifs principaux :

  • Prédictif : lors de l’exécution d’une application avec un privilège administratif, prédit si cette application fonctionnerait aussi bien si elle s’exécutait avec moins de privilège (généralement, en tant qu’utilisateur normal). Par exemple, si l’application écrit dans des fichiers qui autorisent uniquement l’accès Administrateurs, cette application ne pourra pas écrire dans le même fichier si elle est exécutée en tant qu’utilisateur non administrateur.
  • Diagnostic : lors de l’exécution avec un privilège non administrateur, identifie les problèmes potentiels qui peuvent déjà exister avec l’exécution actuelle. En continuant l’exemple précédent, si l’application tente d’écrire dans un fichier qui accorde uniquement l’accès aux membres du groupe Administrateur, l’application obtient une erreur ACCESS_DENIED. Si l’application ne fonctionne pas correctement, cette opération peut être la coupable.

LuaPriv identifie les types de problèmes suivants :

Problème potentiel Description
Espaces de noms restreints La création d’un objet de synchronisation nommé (Événement, Sémaphore, Mutex, etc.) sans espace de noms peut compliquer l’exécution sans privilège sur certains systèmes d’exploitation, car le système d’exploitation peut choisir de placer l’objet dans un espace de noms restreint. La création d’un tel objet dans un espace de noms restreint (tel que l’espace de noms global) nécessite SeCreateGlobalPrivilege, qui est accordé uniquement aux administrateurs.
LuaPriv signale ces deux problèmes s’il les détecte.
Vérifications administrateur en dur Certaines applications interrogent le jeton de sécurité des utilisateurs pour savoir combien de privilèges ils ont. Dans ces cas, l’application peut modifier son comportement en fonction de la puissance estimée de l’utilisateur.
LuaPriv signale les appels d’API qui retournent ces informations.
Demande de privilèges Une application peut tenter d’activer un privilège pertinent en matière de sécurité (par exemple, SeTcbPrivilege ou SeSecurityPrivilege) avant d’effectuer une opération qui l’exige.
LuaPriv signale les tentatives d’activation de privilèges pertinents pour la sécurité.
Privilèges manquants Si une application tente d’activer un privilège que l’utilisateur n’a pas, il signale probablement que l’application attend le privilège, ce qui peut entraîner des différences de comportement.
LuaPriv signale les échecs de demande de privilèges.
Opérations de fichier INI Les tentatives d’écriture dans des fichiers INI mappés (WritePrivateProfileSection et API similaires) peuvent échouer en tant qu’utilisateur non administrateur.
LuaPriv signale ces opérations.
accès refusé Si l’application tente d’accéder à un objet (fichier, clé de Registre, etc.), mais que la tentative échoue en raison d’un accès insuffisant, l’application s’attend probablement à s’exécuter avec plus de privilèges qu’elle ne dispose.
LuaPriv signale les tentatives d’ouverture d’objet qui échouent avec ACCESS_DENIED et des erreurs similaires.
ACE Refuser Si un objet a des ACE Refuser dans sa DACL, il refuse explicitement l’accès à des entités spécifiques.
Cela est rare et rend la prédiction difficile, de sorte que LuaPriv signale les ACE Refuser quand il les trouve.
Accès restreint Si une application tente d’ouvrir un objet pour les droits qui ne sont pas accordés aux utilisateurs normaux (par exemple, en essayant d’écrire dans un fichier qui est uniquement accessible en écriture par les administrateurs), l’application ne fonctionnera probablement pas de la même façon lorsqu’elle est exécutée en tant qu’utilisateur normal.
LuaPriv signale ces opérations.
MAXIMUM_ALLOWED Si une application ouvre un objet pour MAXIMUM_ALLOWED, la vérification d’accès réelle sur l’objet se produit ailleurs. La plupart du code qui effectue cette opération ne fonctionne pas correctement, et fonctionnera presque certainement différemment lors de l’exécution sans privilège.
LuaPriv signale donc tous les incidents de MAXIMUM_ALLOWED.

 

Les problèmes couramment négligés sont capturés dans les vérifications diverses nébuleuses :

  • Détails d’arrêt des API dangereuses
  • Détails d’arrêt des piles à intégrité compromise
  • Substitution du temps

Nous avons ajouté un nouveau vérificateur d’impression. Cette couche permet de trouver et de résoudre les problèmes qui peuvent se produire lorsqu’une application appelle le sous-système d’impression. Le vérificateur d’impression cible les deux couches du sous-système d’impression, la couche PrintAPI et la couche PrintDriver.

Couche d’API d’impression

Le vérificateur d’impression teste l’interface entre un programme et Winspool.drv et prntvpt.dll et teste les interfaces de ces DLL.

Couche de pilote d’impression

Print Verifier teste également l’interface entre un pilote d’impression principal tel que UNIDRV.DLL, UNIDRUI.DLL, PSCRIPT5.DLL, PS5UI.DLL ou MXDWDRV.DLL, et les plug-ins du pilote d’impression.

Notez que certaines de ces vérifications concernent uniquement Windows 7, et d’autres fonctionnent mieux sous Windows 7.

En règle générale, seules les versions de débogage exécutent Application Verifier. Les performances ne sont donc pas généralement un problème. Si des problèmes de performances proviennent de l’utilisation de cette vérification ou d’une autre vérification d’Application Verifier, exécutez une vérification à la fois jusqu’à ce que vous ayez effectué toutes les vérifications nécessaires.

Près de 10 % des incidents d’application sur les systèmes Windows sont dus à un endommagement du tas. Ces incidents sont presque impossibles à déboguer après le fait. La meilleure façon d’éviter ces problèmes consiste à tester les fonctionnalités du tas de pages trouvées dans Application Verifier. Il existe deux types de tas de pages : « entier » et « léger ». Entier est la valeur par défaut ; il force un débogueur à s’arrêter instantanément lors de la détection de la corruption. Cette fonctionnalité DOIT être exécutée sous le débogueur. Toutefois, il s’agit également de la ressource la plus exigeante. Si un utilisateur rencontre des problèmes de minutage et qu’il a déjà exécuté un scénario sous le tas de pages « entier », le définir à la valeur « léger » va probablement résoudre ces problèmes. En outre, le tas de page entier ne se bloque pas tant que le processus n’est pas arrêté. Il fournit une arborescence des appels de procédure à l’allocation, mais peut prendre beaucoup plus de temps pour diagnostiquer que de tirer parti de son équivalent entier.

Surveillez l’état de fiabilité des applications via le portail Web Winqual. Ce portail affiche les rapports d’erreurs collectés via le Rapport d’erreurs Windows. Il est donc facile d’identifier les échecs les plus fréquents. En savoir plus sur ce problème dans Rapport d’erreurs Windows : Prise en main. Microsoft ne facture pas ce service.

Pour tirer parti de WinQual, vous devez :

  1. Inscrire votre entreprise pour WinQual, qui nécessite un ID VeriSign. Vous trouverez des informations Windows 7 sur WinQual dans le portail des développeurs regroupées sous Windows Vista SP1 \ Windows Server 2008. Il aura bientôt un emplacement Windows 7.
  2. Mappez les applications ISV à un nom de produit et au nom de l’ISV, ce qui lie les rapports d’échec à l’entreprise. Les autres ISV ne peuvent pas afficher vos rapports d’erreurs.
  3. Utilisez le portail pour identifier les principaux problèmes. Les ISV peuvent également créer des réponses qui informent les clients des étapes à suivre après un échec. Le système de réponse prend en charge plus de 10 langues dans le monde entier.

Une autre remarque : Application Verifier est aussi bon que les chemins de code que sur lesquels vous l’exécutez. La valeur de la combinaison de cet outil avec un outil de couverture de code ne peut pas être surévaluée.

Outils de débogage pour Windows :

Application Verifier :

WinQual :