Compartir a través de

Pruebas del Kit para la certificación de aplicaciones de Windows

A continuación se muestran los detalles de las pruebas para certificar aplicaciones de escritorio. Para obtener información, consulte Using the Windows App Certification Kit.

Instalación reversible limpia

Instala y desinstala la aplicación y comprueba si hay archivos residuales y entradas del Registro.

  • Fondo
    • Una instalación limpia y reversible permite a los usuarios implementar y quitar aplicaciones. Para superar esta prueba, la aplicación debe hacer lo siguiente:
      • La aplicación no obliga al sistema a reiniciarse inmediatamente después de instalar o desinstalar la aplicación. El proceso de instalación o desinstalación de una aplicación nunca debe requerir un reinicio del sistema justo después de que se complete. Si esto requiere que se reinicie el sistema, los usuarios deben poder reiniciar el sistema en su comodidad.
      • La aplicación no depende de los nombres de archivo cortos (SFN) 8.3. los procesos de instalación y desinstalación de la aplicación deben poder usar nombres de archivo largos y rutas de acceso de carpeta.
      • La aplicación no bloquea la instalación o desinstalación silenciosas
      • La aplicación realiza las entradas necesarias en el registro del sistema. Las herramientas de inventario de Windows y las herramientas de telemetría requieren información completa sobre las aplicaciones instaladas. Los instaladores de aplicaciones deben crear las entradas del Registro correctas para permitir la detección y desinstalación correctas.
    • Si usa un instalador basado en MSI, MSI crea automáticamente las entradas del Registro siguientes. Si no usa un instalador MSI, el módulo de instalación debe crear las siguientes entradas del Registro durante la instalación:
      • DisplayName
      • InstallLocation
      • Editor
      • UninstallString
      • VersionMajor o MajorVersion
      • VersionMinor o MinorVersion
    • La aplicación debe quitar todas sus entradas en Agregar o quitar programas.
  • Detalles de la prueba
    • Esta prueba comprueba los procesos de instalación y desinstalación de la aplicación para el comportamiento necesario.
  • Acción correctiva
    • Revise el diseño y el comportamiento de la aplicación con respecto a los requisitos descritos anteriormente.

Instalación en la prueba de carpetas correcta

Comprueba que la aplicación escribe sus archivos de programa y datos en las carpetas correctas.

  • Fondo
    • Las aplicaciones deben usar el sistema y las carpetas por usuario correctamente para que pueda acceder a los datos y la configuración que necesita al tiempo que protege los datos y la configuración del usuario frente al acceso no autorizado.
  • Carpetas de archivos de programa
    • La aplicación debe instalarse en la carpeta Archivos de programa de forma predeterminada (%ProgramFiles% para aplicaciones nativas de 32 y 64 bits, y %ProgramFiles(x86)% para aplicaciones de 32 bits que se ejecutan en x64).
    • Nota: La aplicación no debe almacenar datos de usuario ni datos de la aplicación en una carpeta Archivos de programa debido a los permisos de seguridad configurados para esta carpeta.
    • Las ACL en carpetas del sistema de Windows solo permiten que las cuentas de administrador lean y escriban en ellas. Como resultado, las cuentas de usuario estándar no tendrán acceso a estas carpetas. Sin embargo, la virtualización de archivos permite a las aplicaciones almacenar un archivo, como un archivo de configuración, en una ubicación del sistema que normalmente solo los administradores pueden escribir. La ejecución de programas como usuario estándar en esta situación podría producir un error si no puede acceder a un archivo necesario.
    • Las aplicaciones deben usar carpetas conocidas para asegurarse de que podrán acceder a sus datos.
    • Nota: Windows proporciona virtualización de archivos para mejorar la compatibilidad de aplicaciones y eliminar problemas cuando las aplicaciones se ejecutan como usuario estándar en Windows. La aplicación no debe depender de que la virtualización esté presente en versiones futuras de Windows.
  • Carpetas de datos de aplicaciones específicas del usuario
    • En las instalaciones "por máquina", la aplicación no debe escribir datos específicos del usuario durante la instalación. Los datos de instalación específicos del usuario solo deben escribirse cuando un usuario inicia la aplicación por primera vez. Esto se debe a que no hay ninguna ubicación de usuario correcta en la que almacenar los datos en el momento de la instalación. Los intentos de una aplicación para modificar los comportamientos de asociación predeterminados en un nivel de máquina después de la instalación no serán correctos. En su lugar, los valores predeterminados deben reclamarse en un nivel por usuario, lo que impide que varios usuarios sobrescriban los valores predeterminados de los demás.
    • Todos los datos de la aplicación exclusivos de un usuario específico y no compartirlos con otros usuarios del equipo deben almacenarse en Users\<username>\AppData.
    • Todos los datos de la aplicación que se deben compartir entre los usuarios del equipo deben almacenarse en ProgramData.
  • Otras carpetas del sistema y claves del Registro
    • La aplicación nunca debe escribir directamente en el directorio o subdirectorios de Windows. Use los métodos correctos para instalar archivos, como fuentes o controladores, en estos directorios.
    • Las aplicaciones no deben iniciarse automáticamente al iniciarse, por ejemplo, agregando una entrada a una o varias de estas ubicaciones:
      • El Registro ejecuta claves HKLM y, o HKCU en Software\Microsoft\Windows\CurrentVersion
      • El Registro ejecuta claves HKLM y HKCU en Software\Wow6432Node\Microsoft\windows\CurrentVersion
      • Menú Inicio TodosProgramas > INICIO
  • Detalles de la prueba
    • Esta prueba comprueba que la aplicación usa las ubicaciones específicas del sistema de archivos que Windows proporciona para almacenar programas y componentes de software, datos compartidos de la aplicación y datos de la aplicación específicos de un usuario.
  • Acciones correctivas
    • Revise cómo la aplicación usa las carpetas del sistema y asegúrese de que las usa correctamente.
  • Excepciones y exenciones
    • Se requiere una exención para las aplicaciones de escritorio que escriben en la caché global de ensamblados (GAC) (las aplicaciones .NET deben mantener las dependencias de ensamblado privadas y almacenarlas en el directorio de la aplicación a menos que se requiera explícitamente compartir un ensamblado).
    • La instalación en la carpeta Archivos de programas no es un requisito para que los paquetes SW de escritorio logren el logotipo sw, solo en la categoría Aspectos básicos de SW.

Prueba de archivos firmada digitalmente

Prueba los archivos ejecutables y los controladores de dispositivo para comprobar que tienen una firma digital válida.

  • Fondo
    • Los archivos firmados digitalmente permiten comprobar que el archivo es auténtico y detectar si el archivo se ha alterado.
    • El cumplimiento de la firma de código en modo kernel es una característica de Windows que también se conoce como integridad de código (CI). CI mejora la seguridad de Windows comprobando la integridad de un archivo cada vez que se carga en la memoria. CI detecta si el código malintencionado ha modificado un archivo binario del sistema y genera un evento de registro de diagnóstico y auditoría del sistema cuando la firma de un módulo de kernel no se puede comprobar correctamente.
    • Si la aplicación requiere permisos elevados, el símbolo del sistema de elevación muestra información contextual sobre el archivo ejecutable que solicita acceso elevado. Dependiendo de si la aplicación está firmada por Authenticode, el usuario puede ver el mensaje de consentimiento o el símbolo del sistema de credenciales.
    • Los nombres seguros impiden que terceros suplantan el código, siempre y cuando mantenga la clave privada segura. .NET Framework comprueba la firma digital cuando carga el ensamblado o lo instala en la GAC. Sin acceso a la clave privada, un usuario malintencionado no puede modificar el código y volver a firmarlo.
  • Detalles de la prueba
    • Todos los archivos ejecutables, como los que tienen extensiones de archivo de .exe, .dll, .ocx, .sys, .cpl, .drv y .scr, deben estar firmados con un certificado Authenticode.
    • Todos los controladores de modo kernel instalados por la aplicación deben tener una firma de Microsoft obtenida a través del programa WHQL o DRS. Todos los controladores de filtro del sistema de archivos deben estar firmados con WHQL.
  • Acción correctiva
    • Firma los archivos ejecutables de la aplicación.
    • Use makecert.exe para generar un certificado o obtener una clave de firma de código de una de las entidades de certificación comerciales (CA), como VeriSign, Thawte o una CA de Microsoft.
  • Excepciones y exenciones
    • Las exenciones solo se considerarán para los redistribuibles de terceros sin firmar. Se requiere una prueba de comunicación que solicite una versión firmada de los redistribuibles para que se conceda esta exención.
    • Los paquetes de software de valor agregado de dispositivo están exentos de la certificación del controlador del modo kernel, ya que los controladores deben estar certificados en mediante la certificación de hardware de Windows.

Compatibilidad con pruebas de Windows x64

Pruebe la aplicación para asegurarse de que el .exe está creado para la arquitectura de la plataforma en la que se instalará.

  • Fondo
    • El archivo ejecutable debe compilarse para la arquitectura del procesador en la que está instalado. Algunos archivos ejecutables se pueden ejecutar en una arquitectura de procesador diferente, pero esto no es confiable.
    • La compatibilidad de la arquitectura es importante porque los procesos de 32 bits no pueden cargar archivos DLL de 64 bits y los procesos de 64 bits no pueden cargar archivos DLL de 32 bits. Del mismo modo, las versiones de 64 bits de Windows no admiten la ejecución de aplicaciones basadas en Windows de 16 bits porque los identificadores tienen 32 bits significativos en Windows de 64 bits, por lo que no se pueden pasar a aplicaciones de 16 bits. Por lo tanto, al intentar iniciar una aplicación de 16 bits se producirá un error en versiones de 64 bits de Windows.
    • Los controladores de dispositivos de 32 bits no se pueden ejecutar en versiones de 64 bits de Windows y, por lo tanto, deben migrarse a la arquitectura de 64 bits.
    • En el caso de las aplicaciones en modo de usuario, Windows de 64 bits incluye WOW64, lo que permite que las aplicaciones windows de 32 bits se ejecuten en sistemas que ejecutan Windows de 64 bits, aunque con cierta pérdida de rendimiento. No existe ninguna capa de traducción equivalente para controladores de dispositivos.
    • Para mantener la compatibilidad con versiones de 64 bits de Windows, las aplicaciones deben admitir de forma nativa 64 bits o, como mínimo, las aplicaciones basadas en Windows de 32 bits deben ejecutarse sin problemas en sistemas de 64 bits:
      • Las aplicaciones y sus instaladores no deben contener ningún código de 16 bits ni depender de ningún componente de 16 bits.
      • La configuración de la aplicación debe detectar e instalar los controladores y componentes adecuados en versiones de 64 bits de Windows.
      • Los complementos de shell deben ejecutarse en versiones de 64 bits de Windows.
      • Las aplicaciones que se ejecutan en el emulador woW64 no deben intentar omitir los mecanismos de virtualización wow64. Si hay escenarios específicos en los que las aplicaciones necesitan detectar si se ejecutan en un emulador de WoW64, deben hacerlo llamando a IsWow64Process.
  • Detalles de la prueba
    • La aplicación no debe instalar archivos binarios de 16 bits. La aplicación no debe instalar un controlador de modo kernel de 32 bits si se supone que se ejecuta en una máquina de 64 bits.
  • Acciones correctivas
    • Compile los archivos y controladores ejecutables para la arquitectura del procesador para la que desea instalarlos.

Prueba de comprobación de versiones del sistema operativo

Comprueba cómo comprueba la aplicación la versión de Windows en la que se ejecuta.

  • Fondo
    • Las aplicaciones comprueban la versión del sistema operativo probando una versión mayor o igual que la versión necesaria para garantizar la compatibilidad con versiones futuras de Windows.
  • Detalles de la prueba
    • Simula la ejecución de la aplicación en diferentes versiones de Windows para ver cómo reacciona.
  • Acciones correctivas
    • Pruebe la versión correcta de Windows probando si la versión actual es mayor o igual que la versión que necesita la aplicación, el servicio o el controlador.
    • Los instaladores de controladores y los módulos de desinstalación nunca deben comprobar la versión del sistema operativo.
  • Excepciones y exenciones
    • Las exenciones se considerarán para las aplicaciones que cumplan los siguientes criterios: (solo se aplica a la certificación de aplicaciones de escritorio)
      • Las aplicaciones que se entregan como un paquete que se ejecuta en Windows XP, Windows Vista y Windows 7 y necesitan comprobar la versión del sistema operativo para determinar qué componentes instalar en un sistema operativo determinado.
      • Las aplicaciones que comprueban solo la versión mínima del sistema operativo (solo durante la instalación, no en tiempo de ejecución) mediante solo las llamadas API aprobadas y enumeran el requisito de versión mínima en el manifiesto de aplicación según sea necesario.
      • Aplicaciones de seguridad como aplicaciones antivirus y de firewall, utilidades del sistema, como utilidades de desfragmentación y aplicaciones de copia de seguridad, y herramientas de diagnóstico que comprueban la versión del sistema operativo mediante solo las llamadas API aprobadas.

Prueba de control de cuentas de usuario (UAC)

Prueba la aplicación para comprobar que no necesita permisos elevados innecesariamente para ejecutarse.

  • Fondo
    • Una aplicación que opera o se instala solo cuando el usuario es un administrador obliga a los usuarios a ejecutar la aplicación con permisos elevados innecesariamente, lo que puede permitir que el malware entre en el equipo del usuario.
    • Cuando los usuarios siempre se ven obligados a ejecutar aplicaciones con tokens de acceso elevados, la aplicación puede servidor como punto de entrada para código engañoso o malintencionado. Este malware puede modificar fácilmente el sistema operativo, o peor, afectar a otros usuarios. Es casi imposible controlar a un usuario que tiene acceso de administrador completo, ya que los administradores pueden instalar aplicaciones y ejecutar cualquier aplicación o script en el equipo. Los administradores de TI siempre buscan formas de crear "escritorios estándar" en los que los usuarios inicien sesión como usuarios estándar. Los escritorios estándar reducen considerablemente los costos del departamento de soporte técnico y reducen la sobrecarga de TI.
    • La mayoría de las aplicaciones no requieren privilegios de administrador en tiempo de ejecución. Una cuenta de usuario estándar debe poder ejecutarla. Las aplicaciones de Windows deben tener un manifiesto (incrustado o externo) para definir su nivel de ejecución que indique al sistema operativo los privilegios necesarios para ejecutar la aplicación. El manifiesto de la aplicación solo se aplica a .exe archivos, no a archivos .dll. El Control de cuentas de usuario (UAC) no inspecciona los archivos DLL durante la creación del proceso. Las reglas de UAC no se aplican a los servicios de Microsoft. El manifiesto de la aplicación se puede incrustar o externo.
    • Para crear un manifiesto, cree un archivo con el nombre <app_name>.exe.manifest y almacénelo en el mismo directorio que exe. Tenga en cuenta que cualquier manifiesto externo se omite si la aplicación tiene un manifiesto interno.
      • Por ejemplo, <requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true|false""/>
      • El proceso principal de la aplicación debe ejecutarse como un usuario estándar (asInvoker). Las características administrativas deben moverse a un proceso independiente que se ejecute con privilegios administrativos.
      • Las aplicaciones orientadas al usuario que requieren privilegios elevados deben estar firmadas por Authenticode.
  • Detalles de la prueba
    • Todos los exes orientados al usuario deben marcarse con el atributo asInvoker. Si se marcan como highestAvailable o requireAdministrator, deben estar firmados correctamente. Cualquier exe de aplicación no debe tener el atributo uiAccess establecido en true. Cualquier exe que se ejecute como servicio se excluye de esta comprobación en particular.
  • Acciones correctivas
    • Revise el archivo de manifiesto de la aplicación para obtener las entradas y los niveles de permisos correctos.
  • Excepciones y exenciones
    • Se requiere una exención para las aplicaciones que ejecutan su proceso principal con privilegios elevados (requireAdministrator o más altoAvailable). El proceso principal es el proceso que proporciona el punto de entrada del usuario a la aplicación.
    • Las exenciones se considerarán para los siguientes escenarios:
      • Herramientas administrativas o del sistema con el nivel de ejecución establecido en más altoDisponible requerirAdministratoro ambos.
      • Solo la aplicación de marco de automatización de la interfaz de usuario o accesibilidad establece la marca uiAccess en TRUE para omitir el aislamiento de privilegios de la interfaz de usuario (UIPI). Para iniciar correctamente el uso de la aplicación, esta marca debe estar firmada con Authenticode y debe residir en una ubicación protegida en el sistema de archivos, como Archivos de programa.

Cumplir los mensajes del administrador de reinicio del sistema

Comprueba cómo responde la aplicación a los mensajes de apagado y reinicio del sistema.

  • Fondo
    • Las aplicaciones deben salir lo antes posible cuando se les notifique que el sistema se apaga para proporcionar una experiencia de apagado o apagado dinámico para el usuario.
    • En un apagado crítico, las aplicaciones que devuelven FALSE a WM_QUERYENDSESSION se enviarán WM_ENDSESSION y se cerrarán, mientras que las que agotan el tiempo de espera en respuesta a WM_QUERYENDSESSION se terminarán forzosamente.
  • Detalles de la prueba
    • Examina cómo responde la aplicación a los mensajes de cierre y salida.
  • Acciones correctivas
    • Si la aplicación produce un error en esta prueba, revise cómo controla estos mensajes de Windows:
      • WM_QUERYENDSESSION con LPARAM = ENDSESSION_CLOSEAPP(0x1): las aplicaciones de escritorio deben responder (TRUE) inmediatamente como preparación para un reinicio. Las aplicaciones de consola pueden llamar a setConsoleCtrlHandler para recibir una notificación de apagado. Los servicios pueden llamar a RegisterServiceCtrlHandlerEx para recibir notificaciones de apagado en una rutina de controlador.
      • WM_ENDSESSION con LPARAM = ENDSESSION_CLOSEAPP(0x1): las aplicaciones deben devolver un valor de 0 en un plazo de 30 segundos y apagarse. Como mínimo, las aplicaciones deben prepararse guardando los datos de usuario y estableciendo la información necesaria después de un reinicio.
    • Las aplicaciones de consola que reciben la notificación de CTRL_C_EVENT deben apagarse inmediatamente. Los controladores no deben vetar un evento de apagado del sistema.
    • Nota: Aplicaciones que deben bloquear el apagado debido a una operación que no se puede interrumpir deben usar ShutdownBlockReasonCreate para registrar una cadena que explique el motivo para el usuario. Una vez completada la operación, la aplicación debe llamar a ShutdownBlockReasonDestroy para indicar que el sistema se puede apagar.

Prueba en modo seguro

Comprueba si el controlador o servicio está configurado para iniciarse en modo seguro.

  • Fondo
    • El modo seguro permite a los usuarios diagnosticar y solucionar problemas con Windows. Solo los controladores y servicios necesarios para el funcionamiento básico del sistema operativo o proporcionar servicios de diagnóstico y recuperación deben cargarse en modo seguro. Cargar otros archivos en modo seguro hace que sea más difícil solucionar problemas con el sistema operativo.
    • De forma predeterminada, solo los controladores y servicios que vienen preinstalados con Windows se inician en modo seguro. Todos los demás controladores y servicios deben deshabilitarse a menos que el sistema los requiera para operaciones básicas o con fines de diagnóstico y recuperación.
  • Detalles de la prueba
    • Los controladores instalados por la aplicación no deben marcarse para cargarlos en modo seguro.
  • Acciones correctivas
    • Si el controlador o el servicio no deben iniciarse en modo seguro, quite las entradas de la aplicación de las claves del Registro.
  • Excepciones y exenciones
    • Los conductores y servicios que deben iniciarse en modo seguro requieren que se certifique una exención. La solicitud de exención debe incluir cada controlador y servicio para agregar a las claves del Registro SafeBoot y describir las razones técnicas por las que el controlador o el servicio deben ejecutarse en modo seguro. El instalador de la aplicación debe registrar todos estos controladores y servicios en estas claves del Registro:
      • HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal
      • HKLM/System/CurrentControlSet/Control/SafeBoot/Network
  • Nota: Debe probar los controladores y servicios que desea iniciar en modo seguro para asegurarse de que funcionan en modo seguro sin errores.

Prueba de sesión multiusuario

Pruebe cómo se comporta la aplicación cuando se ejecuta en varias sesiones al mismo tiempo.

  • Fondo
    • Los usuarios de Windows deben poder ejecutar sesiones simultáneas. Las aplicaciones deben asegurarse de que, cuando se ejecutan en varias sesiones, ya sea de forma local o remota, la funcionalidad normal de la aplicación no se ve afectada negativamente. La configuración de la aplicación y los archivos de datos deben ser específicos del usuario y la privacidad y las preferencias del usuario deben restringirse a la sesión del usuario.
  • Detalles de la prueba
    • Ejecuta varias instancias simultáneas de la aplicación para probar lo siguiente:
      • Varias instancias de una aplicación que se ejecuta al mismo tiempo se aíslan entre sí.
    • Esto significa que los datos de usuario de una instancia no son visibles para otra instancia. El sonido de una sesión de usuario inactiva no debe escucharse en una sesión de usuario activa. En los casos en los que varias instancias de aplicación usan recursos compartidos, la aplicación debe asegurarse de que no haya un conflicto.
      • Si la aplicación se instaló para varios usuarios, almacena los datos en las carpetas y ubicaciones del Registro correctas.
      • La aplicación se puede ejecutar en varias sesiones de usuario (Cambio rápido de usuario) para el acceso local y remoto.
    • Para asegurarse de ello, la aplicación debe comprobar otras sesiones de Terminal Service (TS) para las instancias existentes de la aplicación. Si la aplicación no admite varias sesiones de usuario o acceso remoto, debe decir esto claramente al usuario cuando se inicia desde dicha sesión.
  • Acción correctiva
    • Asegúrese de que la aplicación no almacena los archivos de datos o la configuración de todo el sistema en almacenes de datos específicos del usuario, como perfil de usuario o HKCU. Si es así, esa información no estará disponible para otros usuarios.
    • La aplicación debe instalar archivos de datos y configuración de todo el sistema durante la instalación y crear los archivos y la configuración específicos del usuario después de la instalación cuando un usuario lo ejecuta.
    • Asegúrese de que la aplicación no bloquee varias sesiones simultáneas, ya sea de forma local o remota. La aplicación no debe depender de las exclusión mutuas globales u otros objetos con nombre para comprobar o bloquear varias sesiones simultáneas.
    • Si la aplicación no puede permitir varias sesiones simultáneas por usuario, use espacios de nombres por usuario o por sesión para las exclusión mutuas y otros objetos con nombre.

Bloqueos y bloqueos de pruebas

Supervisa la aplicación durante las pruebas de certificación para registrar cuándo se bloquea o se bloquea.

  • Fondo
    • Los errores de la aplicación, como bloqueos y bloqueos, son una interrupción importante para los usuarios y provocan frustración. La eliminación de estos errores mejora la estabilidad y confiabilidad de la aplicación y, en general, proporciona a los usuarios una mejor experiencia de aplicación. Las aplicaciones que dejan de responder o se bloquean pueden hacer que el usuario pierda datos y tenga una mala experiencia.
  • Detalles de la prueba
    • Probamos la resistencia y la estabilidad de la aplicación a lo largo de las pruebas de certificación.
    • El Kit para la certificación de aplicaciones de Windows llama a IApplicationActivationManager::ActivateApplication para iniciar aplicaciones de la Tienda Windows. Para activateApplication para iniciar una aplicación, el control de cuentas de usuario (UAC) debe estar habilitado y la resolución de pantalla debe ser al menos 1024 x 768 o 768 x 1024. Si no se cumple alguna condición, la aplicación producirá un error en esta prueba.
  • Acciones correctivas
    • Asegúrese de que UAC está habilitado en el equipo de prueba.
    • Asegúrese de que está ejecutando la prueba en un equipo con una pantalla lo suficientemente grande.
    • Si la aplicación no se inicia y la plataforma de prueba cumple los requisitos previos de ActivateApplication, puede solucionar el problema revisando el registro de eventos de activación. Para buscar estas entradas en el registro de eventos:
      1. Abra eventvwr.exe y vaya al nodo \Registros de Windows\Aplicación.
      2. Filtre la vista para mostrar los identificadores de evento: 5900-6000.
      3. Revise las entradas de registro para obtener información que podría explicar por qué la aplicación no se ha lanzado.
    • Solucione el archivo con el problema, identifique y corrija el problema. Recompile y vuelva a probar la aplicación.
  • Recursos adicionales

Prueba de compatibilidad y resistencia

  • Fondo
    • Esta comprobación validará dos aspectos de una aplicación, los ejecutables principales de la aplicación, por ejemplo, el punto de entrada de la aplicación orientado al usuario deben manifestarse por motivos de compatibilidad, así como declarar el GUID correcto. Para admitir esta nueva prueba, el informe tendrá un subdo en "Compatibilidad & resistencia". Se producirá un error en la aplicación si falta una o ambas condiciones.
  • Detalles de la prueba
    • Compatibilidad: las aplicaciones de deben ser totalmente funcionales sin usar modos de compatibilidad de Windows, mensajes appHelp u otras correcciones de compatibilidad. Un manifiesto de compatibilidad permite a Windows proporcionar a la aplicación el comportamiento de compatibilidad adecuado en las distintas versiones del sistema operativo.
    • AppInit: Apps no debe enumerar los archivos DLL para cargarlos en la clave del Registro de HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs.
    • Switchback: La aplicación debe proporcionar el manifiesto de conmutación. Si falta el manifiesto, el Kit de certificación de aplicaciones de Windows proporciona un mensaje de advertencia. El Kit de certificación de aplicaciones de Windows también comprobará que el manifiesto contiene GUID de sistema operativo válido.
  • Acciones correctivas
    • Corrija el componente de la aplicación que usa la corrección de compatibilidad.
    • Asegúrese de que la aplicación no depende de las correcciones de compatibilidad para su funcionalidad.
    • Asegúrese de que la aplicación se manifiesta y que la sección de compatibilidad incluya los valores adecuados.
  • Información adicional

Prueba de procedimientos recomendados de seguridad de Windows

  • Fondo
    • Una aplicación no debe cambiar la configuración predeterminada de seguridad de Windows
  • Detalles de la prueba
    • Comprueba la seguridad de la aplicación mediante la ejecución del Analizador de superficie expuesta a ataques. El enfoque será agregar categorías de error por prueba. Por ejemplo, algunas categorías de pruebas de seguridad pueden incluir:
      • Error de inicialización
      • Error de arquitectura de seguridad
      • Posible error de desbordamiento del búfer
      • Error de bloqueo
    • Para obtener más información, consulte aquí.
  • Acciones correctivas
    • Solucione y corrija el problema identificado por las pruebas. Recompile y vuelva a probar la aplicación.

Prueba de características de seguridad de Windows

  • Fondo
    • Las aplicaciones deben participar en las características de seguridad de Windows. Cambiar las protecciones de seguridad predeterminadas de Windows puede poner a los clientes en mayor riesgo.
  • Detalles de la prueba
    • Comprueba la seguridad de la aplicación mediante la ejecución del Analizador binario BinScope. Para obtener más información, consulte aquí.
  • Acciones correctivas
    • Solucione y corrija el problema identificado por las pruebas. Recompile y vuelva a probar la aplicación.

Prueba de valores altos de PPP

Se recomienda encarecidamente que las aplicaciones Win32 sean compatibles con PPP. Es la clave para que la interfaz de usuario de la aplicación tenga un aspecto coherente en una amplia variedad de configuraciones de visualización de valores altos de PPP. Una aplicación no compatible con PPP que se ejecuta en una configuración de pantalla de alto PPP puede tener problemas como el escalado incorrecto de elementos de la interfaz de usuario, el texto recortado y las imágenes borrosas. Hay dos maneras de declarar que una aplicación es compatible con PPP. Uno es declarar PPP.

  • Fondo
    • Esta comprobación validará dos aspectos de una aplicación, los ejecutables principales, por ejemplo, los puntos de entrada de la aplicación orientados al usuario deben manifestarse para HIGH-DPI reconocimiento y que se llama a las API adecuadas para admitir HIGH-PPP. Se producirá un error en la aplicación si falta una o ambas condiciones. Esta comprobación presentará una nueva sección en el informe de escritorio, vea el ejemplo siguiente.
  • Detalles de la prueba
    • La prueba generará una advertencia cuando detectemos cualquiera de las siguientes opciones:
      • El EXE principal no declara el reconocimiento de PPP en su manifiesto y no llama a la API SetProcessDPIAware. (Advertir al desarrollador si olvida agregar un manifiesto de reconocimiento de PPP).
      • El EXE principal no declara el reconocimiento de PPP en su manifiesto, pero llama a SetProcessDPIAware API (advierte al desarrollador de que debe usar el manifiesto para declarar el reconocimiento de PPP en lugar de llamar a la API).
      • MainEXE declara el reconocimiento de PPP en su manifiesto, pero también llama a La API SetProcessDPIAware (advierte al desarrollador que llama a esa API no es necesaria).
      • Para los archivos binarios que no son EXE principales, si llaman a la API, proporcione una advertencia (no se recomienda llamar a la API).
  • Acciones correctivas
    • No se recomienda el uso de la función SetProcessDPIAware(). Si un archivo DLL almacena en caché la configuración de PPP durante su inicialización, invocar SetProcessDPIAware() en la aplicación puede generar una condición de carrera. Llamar a la función SetProcessDPIAware() en un archivo DLL tampoco es un procedimiento recomendado.
  • Información adicional