Tests du Kit de certification des applications Windows

Vous trouverez ci-dessous des détails de test pour certifier des applications de bureau. Pour plus d’informations, reportez-vous au Kit de certification des applications Windows.

• Installation réversible propre
• Installer sur le test de dossiers appropriés
• Test de fichier signé numériquement
• Prise en charge des tests x64 Windows
• Test de vérification des versions du système d’exploitation
• Test de contrôle de compte d’utilisateur (UAC)
• Respecter les messages du gestionnaire de redémarrage du système
• Test en mode sans échec
• Test de session multiutilisateur
• Blocages et blocages de test
• Test de compatibilité et de résilience
• Test des meilleures pratiques de sécurité Windows
• Test des fonctionnalités de sécurité Windows
• Test DPI élevé

Installation réversible propre

Installe et désinstalle l’application et recherche les fichiers résiduels et les entrées de Registre.

• Arrière-plan
  • Une installation propre et réversible permet aux utilisateurs de déployer et de supprimer des applications. Pour effectuer ce test, l’application doit effectuer les opérations suivantes :
    • L’application ne force pas le système à redémarrer immédiatement après l’installation ou la désinstallation de l’application. Le processus d’installation ou de désinstallation d’une application ne doit jamais nécessiter un redémarrage du système juste après sa fin. Si cela nécessite le redémarrage du système, les utilisateurs doivent pouvoir redémarrer le système à leur convenance.
    • L’application ne dépend pas des noms de fichiers courts 8.3 (SFN). Les processus d’installation et de désinstallation de l’application doivent être en mesure d’utiliser des noms de fichiers longs et des chemins d’accès aux dossiers.
    • L’application ne bloque pas l’installation/désinstallation silencieuses
    • L’application effectue les entrées requises dans le Registre système. Les outils d’inventaire Windows et les outils de télémétrie nécessitent des informations complètes sur les applications installées. Les programmes d’installation d’applications doivent créer les entrées de Registre appropriées pour permettre la détection et les désinstallations réussies.
  • Si vous utilisez un programme d’installation basé sur MSI, MSI crée automatiquement les entrées de Registre ci-dessous. Si vous n’utilisez pas de programme d’installation MSI, le module d’installation doit créer les entrées de Registre suivantes lors de l’installation :
    • DisplayName
    • InstallLocation
    • Éditeur
    • UninstallString
    • VersionMajor ou MajorVersion
    • VersionMinor ou MinorVersion
  • L’application doit supprimer toutes ses entrées dans Add/Remove Programs.
• Détails du test
  • Ce test vérifie les processus d’installation et de désinstallation de l’application pour le comportement requis.
• Mesure corrective
  • Passez en revue la conception et le comportement de l’application par rapport aux exigences décrites ci-dessus.

Installer sur le test de dossiers appropriés

Vérifie que l’application écrit ses fichiers de données et de programme dans les dossiers appropriés.

• Arrière-plan
  • Les applications doivent utiliser correctement les dossiers système et par utilisateur afin qu’elles puissent accéder aux données et aux paramètres dont elle a besoin tout en protégeant les données et les paramètres de l’utilisateur contre l’accès non autorisé.
• Dossiers Program Files
  • L’application doit être installée dans le dossier Program Files par défaut (%ProgramFiles% pour les applications 32 bits et 64 bits natives, et %ProgramFiles(x86)% pour les applications 32 bits s’exécutant sur x64).
  • Note: L’application ne doit pas stocker les données utilisateur ou les données d’application dans un dossier Program Files en raison des autorisations de sécurité configurées pour ce dossier.
  • Les listes de contrôle d’accès sur les dossiers système Windows autorisent uniquement les comptes d’administrateur à lire et à écrire dans ces dossiers. Par conséquent, les comptes d’utilisateur standard n’auront pas accès à ces dossiers. Toutefois, la virtualisation de fichiers permet aux applications de stocker un fichier, tel qu’un fichier de configuration, dans un emplacement système généralement accessible en écriture uniquement par les administrateurs. L’exécution de programmes en tant qu’utilisateur standard dans cette situation peut entraîner un échec s’il ne peut pas accéder à un fichier requis.
  • Les applications doivent utiliser des dossiers connus pour s’assurer qu’elles pourront accéder à leurs données.
  • Note: Windows fournit la virtualisation de fichiers pour améliorer la compatibilité des applications et éliminer les problèmes lorsque les applications s’exécutent en tant qu’utilisateur standard sur Windows. Votre application ne doit pas compter sur la virtualisation présente dans les futures versions de Windows.
• Dossiers de données d’application spécifiques à l’utilisateur
  • Dans les installations « par ordinateur », l’application ne doit pas écrire de données spécifiques à l’utilisateur pendant l’installation. Les données d’installation spécifiques à l’utilisateur doivent être écrites uniquement lorsqu’un utilisateur démarre l’application pour la première fois. Cela est dû au fait qu’il n’existe aucun emplacement d’utilisateur correct auquel stocker les données au moment de l’installation. Les tentatives effectuées par une application pour modifier les comportements d’association par défaut au niveau de l’ordinateur après l’installation échouent. Au lieu de cela, les valeurs par défaut doivent être revendiquées au niveau de chaque utilisateur, ce qui empêche plusieurs utilisateurs de remplacer les valeurs par défaut des autres.
  • Toutes les données d’application exclusives à un utilisateur spécifique et ne doivent pas être partagées avec d’autres utilisateurs de l’ordinateur doivent être stockées dans Users\<username>\AppData.
  • Toutes les données d’application qui doivent être partagées entre les utilisateurs sur l’ordinateur doivent être stockées dans ProgramData.
• Autres dossiers système et clés de Registre
  • L’application ne doit jamais écrire directement dans le répertoire Windows et ou les sous-répertoires. Utilisez les méthodes appropriées pour installer des fichiers, tels que des polices ou des pilotes, dans ces répertoires.
  • Les applications ne doivent pas démarrer automatiquement au démarrage, par exemple en ajoutant une entrée à un ou plusieurs de ces emplacements :
    • Les clés d’exécution du Registre HKLM et, ou HKCU, sous Software\Microsoft\Windows\CurrentVersion
    • Les clés d’exécution du Registre HKLM et ou HKCU sous Software\Wow6432Node\Microsoft\windows\CurrentVersion
    • Démarrer le menu AllPrograms > STARTUP
• Détails du test
  • Ce test vérifie que l’application utilise les emplacements spécifiques dans le système de fichiers que Windows fournit pour stocker des programmes et des composants logiciels, des données d’application partagées et des données d’application spécifiques à un utilisateur.
• Actions correctives
  • Passez en revue la façon dont l’application utilise les dossiers du système et assurez-vous qu’elle les utilise correctement.
• Exceptions et exceptions
  • Une exemption est requise pour les applications de bureau qui écrivent dans le Global Assembly Cache (GAC) (les applications .NET doivent conserver les dépendances d’assembly privées et les stocker dans le répertoire de l’application, sauf si le partage d’un assembly est explicitement requis).
  • L’installation dans le dossier Fichiers de programmes n’est pas requise pour que les packages SW de bureau obtiennent le logo SW, uniquement sous la catégorie Notions de base de SW.

Test de fichier signé numériquement

Teste les fichiers exécutables et les pilotes de périphérique pour vérifier qu’ils ont une signature numérique valide.

• Arrière-plan
  • Les fichiers signés numériquement permettent de vérifier que le fichier est authentique et de détecter si le fichier a été falsifié.
  • L’application de la signature de code en mode noyau est une fonctionnalité Windows également appelée intégrité du code (CI). CI améliore la sécurité de Windows en vérifiant l’intégrité d’un fichier chaque fois qu’il est chargé en mémoire. CI détecte si le code malveillant a modifié un fichier binaire système et génère un événement de journal de diagnostic et d’audit système lorsque la signature d’un module de noyau ne parvient pas à vérifier correctement.
  • Si l’application nécessite des autorisations élevées, l’invite d’élévation affiche des informations contextuelles sur le fichier exécutable qui demande un accès élevé. Selon que l’application est signée Authenticode, l’utilisateur peut voir l’invite de consentement ou l’invite d’informations d’identification.
  • Les noms forts empêchent les tiers d’usurper votre code, tant que vous conservez la clé privée sécurisée. Le .NET Framework vérifie la signature numérique lorsqu’il charge l’assembly ou l’installe dans le GAC. Sans accès à la clé privée, un utilisateur malveillant ne peut pas modifier votre code et le signer à nouveau.
• Détails du test
  • Tous les fichiers exécutables, tels que ceux avec des extensions de fichier de .exe, .dll, .ocx, .sys, .cpl, .drv et .scr, doivent être signés avec un certificat Authenticode.
  • Tous les pilotes en mode noyau installés par l’application doivent avoir une signature Microsoft obtenue via le programme WHQL ou DRS. Tous les pilotes de filtre de système de fichiers doivent être signés WHQL.
• Mesure corrective
  • Signer les fichiers exécutables de l’application.
  • Utilisez makecert.exe pour générer un certificat ou obtenir une clé de signature de code auprès de l’une des autorités de certification commerciales, telles que VeriSign, Thawte ou une autorité de certification Microsoft.
• Exceptions et exceptions
  • Les dérogations ne seront prises en compte que pour les redistribuables tiers non signés. Une preuve de communication demandant une version signée du ou des redistribuables est requise pour que cette exemption soit accordée.
  • Les packages logiciels à valeur ajoutée de périphérique sont exemptés de la certification du pilote en mode noyau, car les pilotes doivent être certifiés par la certification matérielle Windows.

Prise en charge des tests x64 Windows

Testez l’application pour vous assurer que la .exe est générée pour l’architecture de plateforme sur laquelle elle sera installée.

• Arrière-plan
  • Le fichier exécutable doit être généré pour l’architecture du processeur sur laquelle il est installé. Certains fichiers exécutables peuvent s’exécuter sur une autre architecture de processeur, mais ce n’est pas fiable.
  • La compatibilité de l’architecture est importante, car les processus 32 bits ne peuvent pas charger des DLL 64 bits et des processus 64 bits ne peuvent pas charger des DLL 32 bits. De même, les versions 64 bits de Windows ne prennent pas en charge l’exécution d’applications Windows 16 bits, car les handles ont 32 bits significatifs sur Windows 64 bits. Ils ne peuvent donc pas être passés à des applications 16 bits. Par conséquent, la tentative de lancement d’une application 16 bits échoue sur les versions 64 bits de Windows.
  • Les pilotes de périphérique 32 bits ne peuvent pas s’exécuter sur des versions 64 bits de Windows et, par conséquent, ils doivent être portés vers l’architecture 64 bits.
  • Pour les applications en mode utilisateur, Windows 64 bits inclut WOW64, qui permet aux applications Windows 32 bits de s’exécuter sur des systèmes exécutant Windows 64 bits, mais avec une certaine perte de performances. Aucune couche de traduction équivalente n’existe pour les pilotes de périphérique.
  • Pour maintenir la compatibilité avec les versions 64 bits de Windows, les applications doivent prendre en charge en mode natif 64 bits ou, au minimum, les applications Windows 32 bits doivent s’exécuter en toute transparence sur des systèmes 64 bits :
    • Les applications et leurs programmes d’installation ne doivent pas contenir de code 16 bits ni s’appuyer sur un composant 16 bits.
    • La configuration de l’application doit détecter et installer les pilotes et composants appropriés sur les versions 64 bits de Windows.
    • Tous les plug-ins shell doivent s’exécuter sur des versions 64 bits de Windows.
    • Les applications qui s’exécutent sous l’émulateur WoW64 ne doivent pas tenter de contourner les mécanismes de virtualisation Wow64. S’il existe des scénarios spécifiques où les applications doivent détecter si elles s’exécutent dans un émulateur WoW64, elles doivent le faire en appelant IsWow64Process.
• Détails du test
  • L’application ne doit pas installer de fichiers binaires 16 bits. L’application ne doit pas installer un pilote en mode noyau 32 bits s’il est censé s’exécuter sur un ordinateur 64 bits.
• Actions correctives
  • Générez les fichiers exécutables et les pilotes pour l’architecture du processeur pour laquelle vous souhaitez les installer.

Test de vérification des versions du système d’exploitation

Teste la façon dont l’application recherche la version de Windows sur laquelle elle s’exécute.

• Arrière-plan
  • Les applications vérifient la version du système d’exploitation en testant une version supérieure ou égale à la version requise pour garantir la compatibilité avec les futures versions de Windows.
• Détails du test
  • Simule l’exécution de l’application sur différentes versions de Windows pour voir comment elle réagit.
• Actions correctives
  • Testez la version correcte de Windows en testant si la version actuelle est supérieure ou égale à la version dont votre application, service ou pilote a besoin.
  • Les programmes d’installation de pilotes et les modules de désinstallation ne doivent jamais vérifier la version du système d’exploitation.
• Exceptions et exceptions
  • Les dérogations seront prises en compte pour les applications qui répondent aux critères suivants : (S’applique uniquement à la certification des applications de bureau)
    • Les applications fournies sous la forme d’un package qui s’exécutent sur Windows XP, Windows Vista et Windows 7, doivent vérifier la version du système d’exploitation pour déterminer les composants à installer sur un système d’exploitation donné.
    • Les applications qui vérifient uniquement la version minimale du système d’exploitation (pendant l’installation uniquement, et non au moment de l’exécution) en utilisant uniquement les appels d’API approuvés et répertorient les exigences de version minimale dans le manifeste de l’application en fonction des besoins.
    • Applications de sécurité telles que les applications antivirus et de pare-feu, les utilitaires système tels que les utilitaires de défragmentation et les applications de sauvegarde, ainsi que les outils de diagnostic qui vérifient la version du système d’exploitation à l’aide uniquement des appels d’API approuvés.

Test de contrôle de compte d’utilisateur (UAC)

Teste l’application pour vérifier qu’elle n’a pas besoin d’autorisations inutilement élevées pour s’exécuter.

• Arrière-plan
  • Une application qui fonctionne ou s’installe uniquement lorsque l’utilisateur est un administrateur force les utilisateurs à exécuter l’application avec des autorisations inutilement élevées, ce qui peut autoriser les programmes malveillants à entrer sur l’ordinateur de l’utilisateur.
  • Lorsque les utilisateurs sont toujours obligés d’exécuter des applications avec des jetons d’accès élevés, l’application peut serveurr comme point d’entrée pour du code trompeur ou malveillant. Ce programme malveillant peut facilement modifier le système d’exploitation, ou pire, affecter d’autres utilisateurs. Il est presque impossible de contrôler un utilisateur disposant d’un accès administrateur complet, car les administrateurs peuvent installer des applications et exécuter n’importe quelle application ou script sur l’ordinateur. Les responsables informatiques cherchent toujours des moyens de créer des « bureaux standard » où les utilisateurs se connectent en tant qu’utilisateurs standard. Les bureaux standard réduisent considérablement les coûts du support technique et réduisent la surcharge informatique.
  • La plupart des applications ne nécessitent pas de privilèges d’administrateur au moment de l’exécution. Un compte d’utilisateur standard doit pouvoir les exécuter. Les applications Windows doivent avoir un manifeste (incorporé ou externe) pour définir son niveau d’exécution qui indique au système d’exploitation les privilèges nécessaires pour exécuter l’application. Le manifeste de l’application s’applique uniquement aux fichiers .exe, pas aux fichiers .dll. Le contrôle de compte d’utilisateur (UAC) n’inspecte pas les DLL pendant la création du processus. Les règles UAC ne s’appliquent pas aux services Microsoft. Le manifeste de l’application peut être incorporé ou externe.
  • Pour créer un manifeste, créez un fichier portant le nom <app_name>.exe.manifest et stockez-le dans le même répertoire que l’EXE. Notez que tout manifeste externe est ignoré si l’application a un manifeste interne.
    • Par exemple, <requestedExecutionLevel level="""asInvoker | highestAvailable | requireAdministrator" » uiAccess=""true|false""/>
    • Le processus principal de l’application doit être exécuté en tant qu’utilisateur standard (asInvoker). Toutes les fonctionnalités administratives doivent être déplacées dans un processus distinct qui s’exécute avec des privilèges d’administration.
    • Les applications accessibles aux utilisateurs qui nécessitent des privilèges élevés doivent être signées Authenticode.
• Détails du test
  • Tous les exes accessibles à l’utilisateur doivent être marqués avec l’attribut AsInvoker. S’ils sont marqués comme highestAvailable ou requireAdministrator, ils doivent être correctement signés. Tout exe d’application ne doit pas avoir l’attribut uiAccess défini sur true. Tout exe qui s’exécute en tant que service est exclu de cette vérification particulière.
• Actions correctives
  • Passez en revue le fichier manifeste de l’application pour connaître les entrées et les niveaux d’autorisation appropriés.
• Exceptions et exceptions
  • Une exemption est requise pour les applications qui exécutent leur processus principal avec des privilèges élevés (requireAdministrator ou highestAvailable). Le processus principal est le processus qui fournit le point d’entrée de l’utilisateur à l’application.
  • Les dérogations seront prises en compte pour les scénarios suivants :
    • Outils d’administration ou système dont le niveau d’exécution est défini sur highestAvailable, requireAdministrator, ou les deux.
    • Seule l’application d’infrastructure d’accessibilité ou d’automatisation de l’interface utilisateur définit l’indicateur UIAccess sur TRUE pour contourner l’isolation des privilèges d’interface utilisateur (UIPI). Pour démarrer correctement l’utilisation de l’application, cet indicateur doit être signé Authenticode et doit résider dans un emplacement protégé dans le système de fichiers, tel que Program Files.

Respecter les messages du gestionnaire de redémarrage du système

Teste la façon dont l’application répond aux messages d’arrêt et de redémarrage du système.

• Arrière-plan
  • Les applications doivent quitter le plus rapidement possible lorsqu’elles sont averties que le système s’arrête pour fournir une expérience réactive d’arrêt ou de mise hors tension pour l’utilisateur.
  • Dans un arrêt critique, les applications qui retournent FALSE à WM_QUERYENDSESSION seront envoyées WM_ENDSESSION et fermées, tandis que celles qui expirent en réponse à WM_QUERYENDSESSION seront arrêtées de force.
• Détails du test
  • Examine la façon dont l’application répond pour arrêter et quitter les messages.
• Actions correctives
  • Si votre application échoue à ce test, passez en revue la façon dont elle gère ces messages Windows :
    • WM_QUERYENDSESSION avec LPARAM = ENDSESSION_CLOSEAPP(0x1) : les applications de bureau doivent répondre immédiatement en préparation d’un redémarrage. Les applications console peuvent appeler SetConsoleCtrlHandler pour recevoir une notification d’arrêt. Les services peuvent appeler RegisterServiceCtrlHandlerEx pour recevoir des notifications d’arrêt dans une routine de gestionnaire.
    • WM_ENDSESSION avec LPARAM = ENDSESSION_CLOSEAPP(0x1) : les applications doivent retourner une valeur de 0 dans les 30 secondes et s’arrêter. Au minimum, les applications doivent se préparer en enregistrant toutes les données utilisateur et en indiquant les informations nécessaires après un redémarrage.
  • Les applications console qui reçoivent la notification CTRL_C_EVENT doivent s’arrêter immédiatement. Les pilotes ne doivent pas opposer de veto à un événement d’arrêt du système.
  • Note: Les applications qui doivent bloquer l’arrêt en raison d’une opération qui ne peut pas être interrompue doivent utiliser ShutdownBlockReasonCreate pour inscrire une chaîne qui explique la raison de l’utilisateur. Une fois l’opération terminée, l’application doit appeler ShutdownBlockReasonDestroy pour indiquer que le système peut être arrêté.

Test en mode sans échec

Teste si le pilote ou le service est configuré pour démarrer en mode sans échec.

• Arrière-plan
  • Le mode sans échec permet aux utilisateurs de diagnostiquer et de résoudre les problèmes liés à Windows. Seuls les pilotes et services nécessaires au fonctionnement de base du système d’exploitation ou qui fournissent des services de diagnostic et de récupération doivent être chargés en mode sans échec. Le chargement d’autres fichiers en mode sans échec complique la résolution des problèmes liés au système d’exploitation.
  • Par défaut, seuls les pilotes et services préinstallés avec Windows démarrent en mode sans échec. Tous les autres pilotes et services doivent être désactivés, sauf si le système les requiert pour des opérations de base ou à des fins de diagnostic et de récupération.
• Détails du test
  • Les pilotes installés par l’application ne doivent pas être marqués pour le chargement en mode sans échec.
• Actions correctives
  • Si le pilote ou le service ne doit pas démarrer en mode sans échec, supprimez les entrées de l’application des clés de Registre.
• Exceptions et exceptions
  • Les pilotes et les services qui doivent commencer en mode sans échec nécessitent une exemption pour être certifiés. La demande de dispense doit inclure chaque pilote et service à ajouter aux clés de Registre SafeBoot et décrire les raisons techniques pour lesquelles le pilote ou le service doit s’exécuter en mode sans échec. Le programme d’installation de l’application doit inscrire tous ces pilotes et services dans ces clés de Registre :
    • HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal
    • HKLM/System/CurrentControlSet/Control/SafeBoot/Network
• Note: Vous devez tester les pilotes et les services que vous souhaitez démarrer en mode sans échec pour vous assurer qu’ils fonctionnent en mode sans erreur.

Test de session multiutilisateur

Testez le comportement de l’application lors de l’exécution dans plusieurs sessions en même temps.

• Arrière-plan
  • Les utilisateurs Windows doivent pouvoir exécuter des sessions simultanées. Les applications doivent s’assurer que lorsqu’elles s’exécutent dans plusieurs sessions, localement ou à distance, la fonctionnalité normale de l’application n’est pas affectée. Les paramètres d’application et les fichiers de données doivent être spécifiques à l’utilisateur et les préférences de l’utilisateur doivent être limités à la session de l’utilisateur.
• Détails du test
  • Exécute plusieurs instances simultanées de l’application pour tester les éléments suivants :
    • Plusieurs instances d’une application s’exécutant en même temps sont isolées les unes des autres.
  • Cela signifie que les données utilisateur d’une instance ne sont pas visibles par une autre instance. Le son dans une session utilisateur inactive ne doit pas être entendu dans une session utilisateur active. Dans les cas où plusieurs instances d’application utilisent des ressources partagées, l’application doit s’assurer qu’il n’y a pas de conflit.
    • Si l’application a été installée pour plusieurs utilisateurs, elle stocke les données dans les dossiers et emplacements de Registre appropriés.
    • L’application peut s’exécuter dans plusieurs sessions utilisateur (basculement rapide d’utilisateur) pour l’accès local et à distance.
  • Pour ce faire, l’application doit vérifier d’autres sessions TS (Terminal Service) pour les instances existantes de l’application. Si l’application ne prend pas en charge plusieurs sessions utilisateur ou accès à distance, cela doit clairement indiquer à l’utilisateur lorsqu’il est lancé à partir d’une telle session.
• Mesure corrective
  • Assurez-vous que l’application ne stocke pas les fichiers ou paramètres à l’échelle du système dans des magasins de données spécifiques à l’utilisateur, tels que profil utilisateur ou HKCU. Si c’est le cas, ces informations ne seront pas disponibles pour d’autres utilisateurs.
  • Votre application doit installer des fichiers de données et de configuration à l’échelle du système pendant l’installation et créer les fichiers et paramètres spécifiques à l’utilisateur après l’installation lorsqu’un utilisateur l’exécute.
  • Assurez-vous que l’application ne bloque pas plusieurs sessions simultanées, localement ou à distance. L’application ne doit pas dépendre de mutex globaux ou d’autres objets nommés pour rechercher ou bloquer plusieurs sessions simultanées.
  • Si l’application ne peut pas autoriser plusieurs sessions simultanées par utilisateur, utilisez des espaces de noms par utilisateur ou par session pour les mutex et d’autres objets nommés.

Blocages et blocages de test

Surveille l’application pendant les tests de certification pour enregistrer lorsqu’elle se bloque ou se bloque.

• Arrière-plan
  • Les échecs d’application tels que les blocages et les blocages sont une perturbation majeure pour les utilisateurs et provoquent de la frustration. L’élimination de ces défaillances améliore la stabilité et la fiabilité des applications, et en général, offre aux utilisateurs une meilleure expérience d’application. Les applications qui arrêtent de répondre ou se bloquent peuvent provoquer la perte de données par l’utilisateur et avoir une mauvaise expérience.
• Détails du test
  • Nous testons la résilience et la stabilité de l’application tout au long du test de certification.
  • Le Kit de certification des applications Windows appelle IApplicationActivationManager ::ActivateApplication pour lancer des applications du Windows Store. Pour que ActivateApplication lance une application, le contrôle de compte d’utilisateur (UAC) doit être activé et la résolution d’écran doit être au moins 1024 x 768 ou 768 x 1024. Si l’une ou l’autre condition n’est pas remplie, votre application échoue ce test.
• Actions correctives
  • Vérifiez que l’UAC est activée sur l’ordinateur de test.
  • Vérifiez que vous exécutez le test sur un ordinateur avec suffisamment d’écran.
  • Si votre application ne parvient pas à démarrer et que votre plateforme de test répond aux conditions préalables d’ActivateApplication, vous pouvez résoudre le problème en examinant le journal des événements d’activation. Pour rechercher ces entrées dans le journal des événements :
    1. Ouvrez eventvwr.exe et accédez au nœud \Windows Logs\Application.
    2. Filtrez l’affichage pour afficher les ID d’événement : 5900-6000.
    3. Passez en revue les entrées de journal pour obtenir des informations qui peuvent expliquer pourquoi l’application n’a pas lancé.
  • Résolvez le fichier avec le problème, identifiez et corrigez le problème. Regénérer et retester l’application.
• Ressources additionnelles
  • Utilisation du vérificateur d’application dans votre cycle de vie de développement logiciel
  • Vérificateur d’application
  • Utilisation du vérificateur d’application
  • DLL AppInit
  • Réduire le temps de démarrage (applications du Windows Store à l’aide de C#/VB/C++ et XAML)

Test de compatibilité et de résilience

• Arrière-plan
  • Cette vérification valide deux aspects d’une application, le ou les exécutables principaux de l’application, par exemple, le point d’entrée d’application accessible par l’utilisateur doit être manifeste pour la compatibilité, ainsi que la déclaration du GUID approprié. Pour prendre en charge ce nouveau test, le rapport aura un sous-nœud sous « Compatibilité et résilience ». L’application échoue si une ou les deux conditions sont manquantes.
• Détails du test
  • Compatibilité: Les applications doivent être entièrement fonctionnelles sans utiliser les modes de compatibilité Windows, les messages AppHelp ou d’autres correctifs de compatibilité. Un manifeste de compatibilité permet à Windows de fournir à votre application le comportement de compatibilité approprié sous les différentes versions du système d’exploitation
  • AppInit : Les applications ne doivent pas répertorier les DLL à charger dans la clé de Registre HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs.
  • Switchback: L’application doit fournir le manifeste de basculement. Si le manifeste est manquant, le Kit de certification des applications Windows fournit un message d’avertissement. Le Kit de certification des applications Windows vérifie également que le manifeste contient un GUID de système d’exploitation valide.
• Actions correctives
  • Corrigez le composant de l’application qui utilise le correctif de compatibilité.
  • Assurez-vous que l’application ne s’appuie pas sur les correctifs de compatibilité pour ses fonctionnalités.
  • Vérifiez que votre application est manifeste et que la section de compatibilité inclut les valeurs appropriées
• Informations supplémentaires
  • Pour plus d’informations, consultez les DLL AppInit .

Test des meilleures pratiques de sécurité Windows

• Arrière-plan
  • Une application ne doit pas modifier les paramètres de sécurité Windows par défaut
• Détails du test
  • Teste la sécurité de l’application en exécutant l’analyseur surface d’attaque. L’approche consiste à ajouter des catégories de défaillances par test. Par exemple, certaines catégories pour le test de sécurité peuvent inclure :
    • Échec d’initialisation
    • Échec de l’architecture de sécurité
    • Échec possible du dépassement de mémoire tampon
    • Échec d’incident
  • Pour plus d’informations, reportez-vous ici.
• Actions correctives
  • Résolvez et corrigez le problème identifié par les tests. Regénérer et retester l’application.

Test des fonctionnalités de sécurité Windows

• Arrière-plan
  • Les applications doivent accepter les fonctionnalités de sécurité Windows. La modification des protections de sécurité Windows par défaut peut mettre les clients à risque accru.
• Détails du test
  • Teste la sécurité de l’application en exécutant l’analyseur binaire BinScope. Pour plus d’informations, reportez-vous ici.
• Actions correctives
  • Résolvez et corrigez le problème identifié par les tests. Regénérer et retester l’application.

Test DPI élevé

Il est vivement recommandé pour les applications Win32 d’être conscientes des ppp. Il est essentiel de faire en sorte que l’interface utilisateur de l’application soit cohérente sur un large éventail de paramètres d’affichage haute résolution. Une application non prenant en charge les ppp s’exécutant sur un paramètre d’affichage haute résolution peut rencontrer des problèmes tels que la mise à l’échelle incorrecte des éléments d’interface utilisateur, le texte clippé et les images floues. Il existe deux façons de déclarer qu’une application est consciente d’un ppp. L’une consiste à déclarer un ppp.

• Arrière-plan
  • Cette vérification valide deux aspects d’une application, le ou les principaux exécutables, par exemple, les points d’entrée d’application accessibles par l’utilisateur doivent être manifestes pour HIGH-DPI sensibilisation et que les API appropriées sont appelées pour prendre en charge HIGH-DPI. L’application échoue si une ou les deux conditions sont manquantes. Cette vérification présente une nouvelle section dans le rapport de bureau, voir l’exemple ci-dessous.
• Détails du test
  • Le test génère un avertissement lorsque nous détectons l’un des éléments suivants :
    • L’EXE principal ne déclare pas la reconnaissance DPI dans son manifeste et n’appelle pas l’API SetProcessDPIAware. (Avertissez le développeur s’il oublie d’ajouter le manifeste de sensibilisation aux ppp).
    • L’EXE principal ne déclare pas la prise en charge DPI dans son manifeste, mais appelle l’API SetProcessDPIAware (avertit le développeur qu’il doit utiliser le manifeste pour déclarer la sensibilisation DPI au lieu d’appeler l’API).
    • Le mainEXE déclare la reconnaissance DPI dans son manifeste, mais il appelle également l’API SetProcessDPIAware (avertir le développeur que l’appel de cette API n’est pas nécessaire).
    • Pour les fichiers binaires qui ne sont pas des exEs principaux, s’ils appellent l’API, donnez un avertissement (l’appel de l’API n’est pas recommandé).
• Actions correctives
  • L’utilisation de la fonction SetProcessDPIAware() est déconseillée. Si une DLL met en cache les paramètres DPI pendant son initialisation, l’appel de SetProcessDPIAware() dans l’application peut générer une condition de concurrence. L’appel de la fonction SetProcessDPIAware() dans une DLL n’est pas une bonne pratique non plus.
• Informations supplémentaires
  • Écriture d’applications High-DPI