Tests du Kit de certification des applications Windows

Vous trouverez ci-dessous des détails de test pour la certification des applications de bureau. Pour plus d’informations, consultez Utilisation du Kit de certification des applications Windows.

• Nettoyer l’installation réversible
• Installer sur le test de dossiers appropriés
• Test de fichier signé numériquement
• Prise en charge du test Windows x64
• Test de vérification de version du système d’exploitation
• Test du 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
• Test de blocages et de blocages
• Test de compatibilité et de résilience
• Sécurité Windows test des meilleures pratiques
• Test des fonctionnalités de sécurité Windows
• Test DPI élevé

Nettoyer l’installation réversible

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

• Arrière-plan
  • Une installation réversible propre permet aux utilisateurs de déployer et de supprimer des applications. Pour réussir 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 son exécution. 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 (SFN) 8.3. Les processus d’installation et de désinstallation de l’application doivent pouvoir utiliser des noms de fichiers longs et des chemins d’accès aux dossiers.
    • L’application ne bloque pas l’installation/désinstallation en mode silencieux
    • L’application crée 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 une détection et une désinstallation réussies.
  • Si vous utilisez un programme d’installation 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 pendant l’installation :
    • DisplayName
    • Emplacement de l’installation
    • Serveur de publication
    • UninstallString
    • VersionMajor ou MajorVersion
    • VersionMinor ou MinorVersion
  • L’application doit supprimer toutes ses entrées dans Ajout/Suppression de programmes.
• Détails du test
  • Ce test vérifie le comportement requis dans les processus d’installation et de désinstallation de l’application.
• Action 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 programme et de données dans les dossiers appropriés.

• Arrière-plan
  • Les applications doivent utiliser correctement le système utilisateur et les dossiers par utilisateur afin qu’elles puissent accéder aux données et aux paramètres dont elles ont besoin tout en protégeant les données et les paramètres de l’utilisateur contre tout 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 natives 32 bits et 64 bits, et %ProgramFiles(x86)% pour les applications 32 bits s’exécutant sur x64).
  • Note: L’application ne doit pas stocker de données utilisateur ou 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 permettent uniquement aux comptes d’administrateur de lire et d’écrire sur eux. 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’ils ne peuvent pas accéder à un fichier requis.
  • Les applications doivent utiliser les dossiers connus pour s’assurer qu’elles seront en mesure d’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 versions futures de Windows.
• Dossiers de données d’application spécifiques à l’utilisateur
  • Dans les installations « par machine », 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 ne doivent être écrites que lorsqu’un utilisateur démarre l’application pour la première fois. Cela est dû au fait qu’il n’existe pas d’emplacement utilisateur correct pour stocker les données au moment de l’installation. Les tentatives d’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 de l’autre.
  • 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 Utilisateurs\<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 :
    • Clés d’exécution du Registre HKLM et, ou HKCU sous Software\Microsoft\Windows\CurrentVersion
    • Clés d’exécution du Registre HKLM et ou HKCU sous Software\Wow6432Node\Microsoft\windows\CurrentVersion
    • Menu Démarrer Tous les programmes > DÉMARRAGE
• Détails du test
  • Ce test vérifie que l’application utilise les emplacements spécifiques dans le système de fichiers fourni par Windows 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
  • Vérifiez comment l’application utilise les dossiers du système et vérifiez qu’elle les utilise correctement.
• Exceptions et renonciations
  • Une exemption est requise pour les applications de bureau écrivant 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 atteignent le logo SW, uniquement dans la catégorie Principes 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 l’authenticité du fichier 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 du 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 des tiers d’usurper votre code, tant que vous sécurisez la clé privé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.
• Action corrective
  • Signez 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 renonciations
  • Les renonciations seront prises en compte uniquement 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 renonciation soit accordée.
  • Les packages logiciels à valeur ajoutée d’appareil 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 du test Windows x64

Testez l’application pour vous assurer que le .exe est conçu pour l’architecture de plateforme sur laquelle il sera installé.

• Arrière-plan
  • Le fichier exécutable doit être créé pour l’architecture du processeur sur laquelle il est installé. Certains fichiers exécutables peuvent s’exécuter sur une architecture de processeur différente, mais ce n’est pas fiable.
  • La compatibilité de l’architecture est importante, car les processus 32 bits ne peuvent pas charger les DLL 64 bits et les processus 64 bits ne peuvent pas charger les 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 et ne peuvent donc pas être passés aux 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 les versions 64 bits de Windows et doivent donc ê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. Il n’existe aucune couche de traduction équivalente 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 les 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.
    • Le programme d’installation 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 d’interpréteur de commandes doivent s’exécuter sur les 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 dans lesquels 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 de 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 de version du système d’exploitation

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

• Arrière-plan
  • Les applications case activée la version du système d’exploitation en testant une version supérieure ou égale à la version requise pour garantir la compatibilité avec les versions futures 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 case activée la version du système d’exploitation.
• Exceptions et renonciations
  • 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 qui sont livrées sous forme d’un package qui s’exécute sur Windows XP, Windows Vista et Windows 7 et qui doivent case activée la version du système d’exploitation pour déterminer les composants à installer sur un système d’exploitation donné.
    • Les applications qui case activée 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 la version minimale requise dans le manifeste de l’application en fonction des besoins.
    • Les 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, et diagnostics outils qui case activée la version du système d’exploitation en utilisant uniquement les appels d’API approuvés.

Test du 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 servir de 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 des applications ou des scripts sur l’ordinateur. Les responsables informatiques recherchent 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 n’ont pas besoin 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 d’application s’applique uniquement aux fichiers .exe, et non 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 d’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 main 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 destinées aux utilisateurs qui nécessitent des privilèges élevés doivent être signées Authenticode.
• Détails du test
  • Tous les exes destinés aux utilisateurs doivent être marqués avec l’attribut asInvoker. S’ils sont marqués comme plus élevéAvailable ou requireAdministrator, ils doivent être correctement authenticode signés. Un 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 ce case activée particulier.
• Actions correctives
  • Passez en revue le fichier manifeste de l’application pour connaître les entrées et les niveaux d’autorisation corrects.
• Exceptions et renonciations
  • Une exemption est requise pour les applications qui exécutent leur processus main avec des privilèges élevés (requireAdministrator ou highestAvailable). Le processus main 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 le niveau le plus élevéAvailable, 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 de l’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 se fermer aussi rapidement que possible lorsqu’elles sont informées de l’arrêt du système pour fournir une expérience d’arrêt ou de mise hors tension réactive pour l’utilisateur.
  • Lors d’un arrêt critique, les applications qui retournent la valeur FALSE à WM_QUERYENDSESSION sont envoyées WM_ENDSESSION et fermées, tandis que celles qui expirent en réponse à WM_QUERYENDSESSION sont arrêtées de force.
• Détails du test
  • Examine la façon dont l’application répond aux messages d’arrêt et de sortie.
• Actions correctives
  • Si votre application échoue à ce test, vérifiez comment elle gère ces messages Windows :
    • WM_QUERYENDSESSION avec LPARAM = ENDSESSION_CLOSEAPP(0x1) : les applications de bureau doivent répondre (TRUE) immédiatement en vue 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 0 dans les 30 secondes et s’arrêter. Au minimum, les applications doivent se préparer en enregistrant 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 leur 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 à 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 se charger 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 en a besoin pour les 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 renonciations
  • Les pilotes et les services qui doivent démarrer en mode sans échec nécessitent une dérogation pour être certifiés. La demande de renonciation 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 échec sans erreur.

Test de session multiutilisateur

Testez le comportement de l’application en cas d’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, les fonctionnalités normales de l’application ne sont pas affectées. Les paramètres d’application et les fichiers de données doivent être spécifiques à l’utilisateur et la confidentialité et les préférences de l’utilisateur doivent être limitées à 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’un instance ne sont pas visibles par un 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 le ou les dossiers et emplacements de Registre appropriés.
    • L’application peut s’exécuter dans plusieurs sessions utilisateur (basculement rapide de l’utilisateur) pour l’accès local et à distance.
  • Pour ce faire, l’application doit case activée d’autres sessions de service terminal (TS) pour les instances existantes de l’application. Si l’application ne prend pas en charge plusieurs sessions utilisateur ou l’accès à distance, elle doit le dire clairement à l’utilisateur lorsqu’elle est lancée à partir d’une telle session.
• Action corrective
  • Assurez-vous que l’application ne stocke pas de fichiers de données ou de 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 les autres utilisateurs.
  • Votre application doit installer des fichiers de configuration et de données à 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 case activée 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 autres objets nommés.

Test de blocages et de blocages

Surveille l’application au cours des tests de certification afin d’enregistrer quand elle cesse de répondre ou se bloque.

• Contexte
  • Les échecs d’application tels que les plantages et les blocages sont une perturbation majeure pour les utilisateurs et provoquent de la frustration. L’élimination de telles défaillances améliore la stabilité et la fiabilité des applications et, dans l’ensemble, offre aux utilisateurs une meilleure expérience d’application. Les applications qui cessent de répondre ou qui se bloquent peuvent conduire à la perte de données ou une expérience médiocre du point de vue de l’utilisateur.
• Détails du test
  • Nous testons la résilience et la stabilité de l’application tout au long des tests de certification.
  • Le Kit de certification des applications Windows appelle IApplicationActivationManager::ActivateApplication pour lancer des applications du Windows Store. Pour que la méthode ActivateApplication lance une application, il faut que le contrôle de compte d’utilisateur (UAC) soit activé et que la résolution de l’écran soit d’au moins 1 024 × 768 ou 768 × 1 024. Si l’une de ces conditions n’est pas respectée, votre application échouera à ce test.
• Actions correctives
  • Assurez-vous que le contrôle UAC est activé sur l’ordinateur de test.
  • Veillez à exécuter le test sur un ordinateur dont l’écran est suffisamment grand.
  • Si le lancement de votre application échoue et que votre plateforme de test satisfait aux exigences liées à la méthode 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 \Journaux Windows\Application.
    2. Filtrez la vue de manière à afficher les ID d’événement 5900 à 6000.
    3. Dans les entrées du journal, recherchez les informations susceptibles d’expliquer l’échec du lancement de l’application.
  • Identifiez le fichier posant problème et corrigez-le. Générez et testez de nouveau l’application.
• Ressources supplémentaires
  • Utilisation du vérificateur d’applications dans votre cycle de vie de développement logiciel
  • Application Verifier
  • Utilisation du vérificateur d’application
  • DLL AppInit
  • Réduire le temps de démarrage (applications du Windows Store en C#/VB/C++ et XAML)

Test de compatibilité et de résilience

• Arrière-plan
  • Cette case activée valide deux aspects d’une application: l’application main exécutable(s), par exemple, le point d’entrée de l’application face à l’utilisateur doit être manifesté 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 « Résilience & de compatibilité ». L’application échoue si l’une de ces conditions ou les deux 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 affiche 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 des 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 DLL AppInit .

Sécurité Windows test des meilleures pratiques

• 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 d’échecs par test. Par exemple, certaines catégories de test de sécurité peuvent inclure :
    • Échec de l’initialisation
    • Échec de l’architecture de sécurité
    • Échec possible du dépassement de mémoire tampon
    • Échec de l’incident
  • Pour plus d’informations, reportez-vous ici.
• Actions correctives
  • Résolvez et résolvez le problème identifié par les tests. Générez et testez de nouveau 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 exposer les clients à des risques accrus.
• Détails du test
  • Teste la sécurité de l’application en exécutant BinScope Binary Analyzer. Pour plus d’informations, reportez-vous ici.
• Actions correctives
  • Résolvez et résolvez le problème identifié par les tests. Générez et testez de nouveau l’application.

Test DPI élevé

Il est vivement recommandé pour les applications Win32 de prendre en compte DPI. Il est essentiel de faire en sorte que l’interface utilisateur de l’application soit toujours bonne dans un large éventail de paramètres d’affichage à haute résolution. Une application qui ne prend pas en charge les PPP s’exécutant sur un paramètre d’affichage à haute résolution peut présenter des problèmes tels que la mise à l’échelle incorrecte des éléments d’interface utilisateur, le texte rogné et les images floues. Il existe deux façons de déclarer qu’une application prend en charge les ppp. L’une consiste à déclarer DPI.

• Arrière-plan
  • Cette case activée valide deux aspects d’une application, les main exécutables, par exemple, les points d’entrée d’application orientés utilisateur doivent se manifester pour la prise en charge de HIGH-DPI et le fait que les API appropriées sont appelées pour prendre en charge HIGH-DPI. L’application échoue si l’une de ces conditions ou les deux sont manquantes. Cette case activée introduit 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 :
    • Le main EXE 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 un manifeste de reconnaissance DPI).
    • L’exe main ne déclare pas la prise de conscience DPI dans son manifeste, mais appelle l’API SetProcessDPIAware (avertissez le développeur qu’il doit utiliser le manifeste pour déclarer la reconnaissance 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 qu’appeler cette API n’est pas nécessaire).
    • Pour les fichiers binaires qui ne sont pas main LESE, 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. Appeler la fonction SetProcessDPIAware() dans une DLL n’est pas non plus une bonne pratique.
• Informations supplémentaires
  • Écriture d’applications haute résolution