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

A continuación se muestran los detalles de prueba para certificar aplicaciones de escritorio. Para obtener información, consulte Uso del Kit para la certificación de aplicaciones de Windows.

• Instalación reversible limpia
• Instalación en la prueba de carpetas correcta
• Prueba de archivos firmado digitalmente
• Compatibilidad con la prueba de Windows x64
• Prueba de comprobación de versiones del sistema operativo
• Prueba de control de cuentas de usuario (UAC)
• Cumplir los mensajes del administrador de reinicio del sistema
• Prueba en modo seguro
• Prueba de sesión multiusuario
• Bloqueos y bloqueos de prueba
• Prueba de compatibilidad y resistencia
• prueba de procedimientos recomendados de Seguridad de Windows
• Prueba de características de seguridad de Windows
• Prueba de VALORES altos de PPP

Instalación reversible limpia

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

• Información previa
  • 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
    • Publicador
    • UninstallString
    • VersionMajor o MajorVersion
    • VersionMinor o MinorVersion
  • La aplicación debe quitar todas sus entradas en Agregar o quitar programas.
• Detalles de las pruebas
  • Esta prueba comprueba los procesos de instalación y desinstalación de la aplicación para el comportamiento necesario.
• Acción correctora
  • 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 datos y programa en las carpetas correctas.

• Información previa
  • 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 aplicación en una carpeta Archivos de programa debido a los permisos de seguridad configurados para esta carpeta.
  • Las ACL de las 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 un 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 se realizarán correctamente. En su lugar, los valores predeterminados se deben reclamar 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 para un usuario específico y no compartirse 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, como al agregar una entrada a una o varias de estas ubicaciones:
    • Claves de ejecución del Registro HKLM y, o HKCU en Software\Microsoft\Windows\CurrentVersion
    • Claves de ejecución del Registro HKLM y HKCU en Software\Wow6432Node\Microsoft\windows\CurrentVersion
    • Menú Inicio AllPrograms > STARTUP
• Detalles de las pruebas
  • 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 aplicaciones y datos de 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 firmado digitalmente

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

• Información previa
  • 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 kernel no 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 mensaje 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 las pruebas
  • 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 correctora
  • Firma los archivos ejecutables de la aplicación.
  • Use makecert.exe para generar un certificado u obtener una clave de firma de código de una de las entidades de certificación (CA) comerciales, como VeriSign, Thawte o una CA de Microsoft.
• Excepciones y exenciones
  • Las renuncias se considerarán solo 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 de controladores en 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 se compila para la arquitectura de la plataforma en la que se instalará.

• Información previa
  • 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 para que no se puedan 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 dispositivo 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 de 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 los 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 las pruebas
  • 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 ejecutables y los controladores 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.

• Información previa
  • 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 las pruebas
  • 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 criterios siguientes: (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.

• Información previa
  • 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 un usuario que tenga acceso de administrador total, 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 ejecutarlas. 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 las pruebas
  • Todos los exes orientados al usuario deben marcarse con el atributo asInvoker. Si están marcados como highestAvailable o requireAdministrator, deben estar firmados correctamente. Cualquier aplicación exe 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 conocer 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 highestAvailable). El proceso principal es el proceso que proporciona el punto de entrada del usuario a la aplicación.
  • Las exenciones se considerarán en los siguientes escenarios:
    • Herramientas administrativas o del sistema con el nivel de ejecución establecido en highestAvailable, requireAdministrator o 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.

Adhesión a los mensajes del administrador de reinicio del sistema

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

• Información previa
  • 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 las pruebas
  • 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 el estado de 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: Las 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 de modo seguro

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

• Información previa
  • 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 las pruebas
  • Los controladores instalados por la aplicación no deben marcarse para cargarse 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.

• Información previa
  • Los usuarios de Windows deben poder ejecutar sesiones simultáneas. Las aplicaciones deben asegurarse de que, cuando se ejecutan en varias sesiones, ya sea local o remotamente, 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 las pruebas
  • 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 están aisladas 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 esto, 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 indicarlo 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 ni 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 local o remotamente. La aplicación no debe depender de exclusiones 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 exclusiones mutuas y otros objetos con nombre.

Bloqueos y bloqueos de pruebas

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

• Segundo plano
  • 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 confiabilidad y la estabilidad 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 originar pérdidas de datos al usuario y que su experiencia no sea buena.
• Detalles de las pruebas
  • Probamos la estabilidad y resistencia de la aplicación durante 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 que ActivateApplication inicie una aplicación, el Control de cuentas de usuario (UAC) debe estar habilitado y la pantalla debe tener una resolución de al menos 1024 x 768 o 768 x 1024. Si alguna de estas condiciones no se cumple, tu aplicación no pasará esta prueba.
• Acciones correctivas
  • Asegúrate de que UAC esté habilitado en el equipo de prueba.
  • Asegúrate de ejecutar la prueba en un equipo que tenga una pantalla lo suficientemente amplia.
  • Si tu aplicación no puede iniciarse aun cuando la plataforma de prueba cumple con los requisitos de ActivateApplication, puedes solucionar el problema revisando el registro de eventos de activación. Para encontrar estas entradas en el registro de eventos:
    1. Abra eventvwr.exe y vaya al nodo \Windows Logs\Application.
    2. Filtra la vista para que se muestren los identificadores de eventos: 5900-6000.
    3. Revisa las entradas del registro para encontrar información que pueda explicar por qué la aplicación no se inicia.
  • Soluciona los problemas del archivo mediante identificación y corrección. Recompila y vuelve a probar la aplicación.
• Recursos adicionales
  • Uso del comprobador de aplicaciones en el ciclo de vida de desarrollo de software
  • Comprobador de aplicación
  • Uso del comprobador de aplicaciones
  • Archivos DLL de AppInit
  • Minimizar el tiempo de inicio (aplicaciones de la Tienda Windows con C#/VB/C++ y XAML)

Prueba de compatibilidad y resistencia

• Información previa
  • 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 compatibilidad, así como declarar el GUID correcto. Para admitir esta nueva prueba, el informe tendrá un subdo en "Resistencia de compatibilidad & ". Se producirá un error en la aplicación si falta una o ambas condiciones.
• Detalles de las pruebas
  • Compatibilidad: Las aplicaciones deben ser totalmente funcionales sin usar modos de compatibilidad de Windows, mensajes de 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: Las aplicaciones no deben enumerar los archivos DLL para cargarlos en la clave del Registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs.
  • Switchback: La aplicación debe proporcionar el manifiesto de conmutación por recuperación. Si falta el manifiesto, el Kit para la certificación de aplicaciones de Windows muestra un mensaje de advertencia. El Kit para la certificación de aplicaciones de Windows también comprobará que el manifiesto contiene un 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 se basa en 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
  • Consulta Archivos DLL de AppInit para obtener más información.

prueba de procedimientos recomendados de Seguridad de Windows

• Información previa
  • Una aplicación no debe cambiar la configuración de seguridad predeterminada de Windows.
• Detalles de las pruebas
  • Prueba 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 prueba 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. Recompila y vuelve a probar la aplicación.

Prueba de características de seguridad de Windows

• Información previa
  • Las aplicaciones deben participar en las características de seguridad de Windows. Cambiar las protecciones de seguridad de Windows predeterminadas puede causar grandes riesgos a los clientes.
• Detalles de las pruebas
  • Prueba la seguridad de la aplicación ejecutando el analizador binario BinScope. Para obtener más información, consulte aquí.
• Acciones correctivas
  • Solucione y corrija el problema identificado por las pruebas. Recompila y vuelve a probar la aplicación.

Prueba de valores altos de PPP

Se recomienda encarecidamente que las aplicaciones Win32 tengan en cuenta 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 pantalla de valores altos de PPP. Una aplicación no compatible con PPP que se ejecuta en una configuración de visualización de valores altos de 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.

• Información previa
  • Esta comprobación validará dos aspectos de una aplicación, los ejecutables principales, por ejemplo, los puntos de entrada de la aplicación accesibles desde el usuario deben manifestarse para el reconocimiento de valores altos de PPP y que se llama a las API adecuadas para admitir valores altos de 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, consulte el ejemplo siguiente.
• Detalles de las pruebas
  • 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 SetProcessDPIAware API. (Advertir al desarrollador si se olvida de agregar el 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 SetProcessDPIAware API (advierte al desarrollador de que no es necesario llamar a esa API).
    • 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 una buena práctica.
• Información adicional
  • Escritura de aplicaciones de valores altos de PPP