Testes do Kit de Certificação de Aplicativos do Windows

Abaixo estão os detalhes de teste para certificar aplicativos da área de trabalho. Para obter informações, consulte Usando o Kit de Certificação de Aplicativos do Windows.

• Instalação reversível limpa
• Instalar no teste de pastas corretas
• de teste de arquivo assinado digitalmente
• suporte a de teste do Windows x64
• de teste de verificação de versão do sistema operacional
• de teste do UAC (controle de conta de usuário)
• Aderir às mensagens do gerenciador de reinicialização do sistema
• de teste do modo de segurança
• de teste de sessão multiusuário
• falha e trava de teste
• de teste de compatibilidade e resiliência
• de teste de melhores práticas de Segurança do Windows
• de teste de recursos de Segurança do Windows
• de teste de Alta DPI

Instalação reversível limpa

Instala e desinstala o aplicativo e verifica se há arquivos residuais e entradas do Registro.

• Fundo
  • Uma instalação limpa e reversível permite que os usuários implantem e removam aplicativos. Para passar neste teste, o aplicativo deve fazer o seguinte:
    • O aplicativo não força o sistema a reiniciar imediatamente após a instalação ou desinstalação do aplicativo. O processo de instalação ou desinstalação de um aplicativo nunca deve exigir uma reinicialização do sistema logo após a conclusão. Se isso exigir que o sistema seja reiniciado, os usuários deverão ser capazes de reiniciar o sistema à sua conveniência.
    • O aplicativo não depende de SFN (nomes de arquivo curtos) 8.3. os processos de instalação e desinstalação do aplicativo devem ser capazes de usar longos nomes de arquivo e caminhos de pasta.
    • O aplicativo não bloqueia a instalação/desinstalação silenciosa
    • O aplicativo faz as entradas necessárias no registro do sistema. Ferramentas de inventário do Windows e ferramentas de telemetria exigem informações completas sobre aplicativos instalados. Os instaladores de aplicativos devem criar as entradas corretas do Registro para permitir detecção e desinstalações bem-sucedidas.
  • Se você estiver usando um instalador baseado em MSI, o MSI criará automaticamente as entradas do Registro abaixo. Se você não estiver usando um instalador MSI, o módulo de instalação deverá criar as seguintes entradas do Registro durante a instalação:
    • DisplayName
    • InstallLocation
    • Editor
    • DesinstalarString
    • VersionMajor ou MajorVersion
    • VersionMinor ou MinorVersion
  • O aplicativo deve remover todas as suas entradas em Adicionar/Remover Programas.
• Detalhes do teste
  • Esse teste verifica os processos de instalação e desinstalação do aplicativo quanto ao comportamento necessário.
• Ação corretiva
  • Examine o design e o comportamento do aplicativo em relação aos requisitos descritos acima.

Instalar no teste de pastas correto

Verifica se o aplicativo grava seu programa e arquivos de dados nas pastas corretas.

• Fundo
  • Os aplicativos devem usar o sistema de usuário e as pastas por usuário corretamente para que possam acessar os dados e as configurações necessárias, protegendo os dados e as configurações do usuário contra acesso não autorizado.
• Pastas arquivos de programas
  • O aplicativo deve ser instalado na pasta Arquivos de Programas por padrão (%ProgramFiles% para aplicativos nativos de 32 bits e 64 bits e %ProgramFiles(x86)% para aplicativos de 32 bits em execução no x64).
  • Observação: O aplicativo não deve armazenar dados do usuário ou dados do aplicativo em uma pasta Arquivos de Programas devido às permissões de segurança configuradas para essa pasta.
  • As ACLs nas pastas do sistema Windows permitem que somente contas de administrador leiam e escrevam neles. Como resultado, as contas de usuário padrão não terão acesso a essas pastas. A virtualização de arquivos, no entanto, permite que os aplicativos armazenem um arquivo, como um arquivo de configuração, em um local do sistema que normalmente é gravável apenas por administradores. A execução de programas como um usuário padrão nessa situação poderá resultar em falha se ele não puder acessar um arquivo necessário.
  • Os aplicativos devem usar Pastas Conhecidas para garantir que eles possam acessar seus dados.
  • Observação: Windows fornece virtualização de arquivo para melhorar a compatibilidade do aplicativo e eliminar problemas quando os aplicativos são executados como um usuário padrão no Windows. Seu aplicativo não deve depender da virtualização estar presente em versões futuras do Windows.
• Pastas de dados de aplicativo específicas do usuário
  • Em instalações "por computador", o aplicativo não deve gravar dados específicos do usuário durante a instalação. Os dados de instalação específicos do usuário só devem ser gravados quando um usuário inicia o aplicativo pela primeira vez. Isso ocorre porque não há um local de usuário correto no qual armazenar dados no momento da instalação. As tentativas de um aplicativo de modificar comportamentos de associação padrão em um nível de computador após a instalação não terão êxito. Em vez disso, os padrões devem ser reivindicados em um nível por usuário, o que impede que vários usuários substituam os padrões uns dos outros.
  • Todos os dados do aplicativo exclusivos para um usuário específico e que não devem ser compartilhados com outros usuários do computador devem ser armazenados em Usuários\<nome de usuário>\AppData.
  • Todos os dados do aplicativo que devem ser compartilhados entre os usuários no computador devem ser armazenados no ProgramData.
• Outras pastas do sistema e chaves do Registro
  • O aplicativo nunca deve gravar diretamente no diretório do Windows e ou subdiretórios. Use os métodos corretos para instalar arquivos, como fontes ou drivers, nesses diretórios.
  • Os aplicativos não devem começar automaticamente na inicialização, como adicionando uma entrada a um ou mais desses locais:
    • HKLM de chaves de execução do Registro e ou HKCU em Software\Microsoft\Windows\CurrentVersion
    • HKLM de chaves de execução do Registro e ou HKCU em Software\Wow6432Node\Microsoft\windows\CurrentVersion
    • Iniciar Menu AllPrograms > STARTUP
• Detalhes do teste
  • Este teste verifica se o aplicativo usa os locais específicos no sistema de arquivos que o Windows fornece para armazenar programas e componentes de software, dados compartilhados do aplicativo e dados de aplicativo específicos para um usuário.
• Ações corretivas
  • Examine como o aplicativo usa as pastas do sistema e verifique se ele está usando-as corretamente.
• Exceções e renúncias
  • Uma renúncia é necessária para aplicativos da área de trabalho que gravam no GAC (cache de assembly global) (os aplicativos .NET devem manter as dependências do assembly privadas e armazená-la no diretório do aplicativo, a menos que o compartilhamento de um assembly seja explicitamente necessário).
  • A instalação na pasta Arquivos de Programas não é um requisito para que os pacotes SW da área de trabalho alcancem o Logotipo SW, somente na categoria de Conceitos Básicos do SW.

Teste de arquivo assinado digitalmente

Testa arquivos executáveis e drivers de dispositivo para verificar se eles têm uma assinatura digital válida.

• Fundo
  • Arquivos assinados digitalmente possibilitam verificar se o arquivo é genuíno e detectar se o arquivo foi adulterado.
  • A imposição de assinatura de código no modo kernel é um recurso do Windows que também é conhecido como CI (integridade de código). A CI melhora a segurança do Windows verificando a integridade de um arquivo sempre que ele é carregado na memória. A CI detecta se o código mal-intencionado modificou um arquivo binário do sistema e gera um evento de log de diagnóstico e auditoria do sistema quando a assinatura de um módulo do kernel falha ao verificar corretamente.
  • Se o aplicativo exigir permissões elevadas, o prompt de elevação exibirá informações contextuais sobre o arquivo executável que está solicitando acesso elevado. Dependendo se o aplicativo é assinado pelo Authenticode, o usuário pode ver o prompt de consentimento ou o prompt de credencial.
  • Nomes fortes impedem que terceiros falsifiquem seu código, desde que você mantenha a chave privada segura. O .NET Framework verifica a assinatura digital quando carrega o assembly ou o instala no GAC. Sem acesso à chave privada, um usuário mal-intencionado não pode modificar seu código e assiná-lo novamente.
• Detalhes do teste
  • Todos os arquivos executáveis, como aqueles com extensões de arquivo de .exe, .dll, .ocx, .sys, .cpl, .drv e .scr, devem ser assinados com um certificado Authenticode.
  • Todos os drivers de modo kernel instalados pelo aplicativo devem ter uma assinatura da Microsoft obtida por meio do programa WHQL ou DRS. Todos os drivers de filtro do sistema de arquivos devem ser assinados por WHQL.
• Ação corretiva
  • Assine os arquivos executáveis do aplicativo.
  • Use makecert.exe para gerar um certificado ou obter uma chave de assinatura de código de uma das autoridades de certificação comerciais (CAs), como VeriSign, Thawte ou uma AC da Microsoft.
• Exceções e renúncias
  • As renúncias serão consideradas apenas para redistribuíveis de terceiros não assinados. Uma prova de comunicação solicitando uma versão assinada dos redistribuíveis é necessária para que essa renúncia seja concedida.
  • Os pacotes de software com valor agregado do dispositivo são isentos da certificação do driver do modo kernel, pois os drivers devem ser certificados pela Certificação de Hardware do Windows.

Suporte ao teste do Windows x64

Teste o aplicativo para verificar se o .exe foi criado para a arquitetura da plataforma na qual ele será instalado.

• Fundo
  • O arquivo executável deve ser criado para a arquitetura do processador na qual ele está instalado. Alguns arquivos executáveis podem ser executados em uma arquitetura de processador diferente, mas isso não é confiável.
  • A compatibilidade de arquitetura é importante porque os processos de 32 bits não podem carregar DLLs de 64 bits e os processos de 64 bits não podem carregar DLLs de 32 bits. Da mesma forma, as versões de 64 bits do Windows não dão suporte à execução de aplicativos baseados no Windows de 16 bits porque as alças têm 32 bits significativos no Windows de 64 bits, portanto, não podem ser passadas para aplicativos de 16 bits. Portanto, a tentativa de iniciar um aplicativo de 16 bits falhará em versões de 64 bits do Windows.
  • Os drivers de dispositivo de 32 bits não podem ser executados em versões de 64 bits do Windows e, portanto, devem ser portados para a arquitetura de 64 bits.
  • Para aplicativos no modo de usuário, o Windows de 64 bits inclui o WOW64, que permite que aplicativos Windows de 32 bits sejam executados em sistemas que executam o Windows de 64 bits, embora com alguma perda de desempenho. Não existe nenhuma camada de tradução equivalente para drivers de dispositivo.
  • Para manter a compatibilidade com versões de 64 bits do Windows, os aplicativos devem dar suporte nativo a 64 bits ou, no mínimo, aplicativos baseados no Windows de 32 bits devem ser executados perfeitamente em sistemas de 64 bits:
    • Os aplicativos e seus instaladores não devem conter nenhum código de 16 bits ou depender de nenhum componente de 16 bits.
    • A instalação do aplicativo deve detectar e instalar os drivers e componentes adequados em versões de 64 bits do Windows.
    • Todos os plug-ins de shell devem ser executados em versões de 64 bits do Windows.
    • Os aplicativos executados no emulador WoW64 não devem tentar ignorar os mecanismos de virtualização do Wow64. Se houver cenários específicos em que os aplicativos precisam detectar se estão em execução em um emulador WoW64, eles devem fazer isso chamando IsWow64Process.
• Detalhes do teste
  • O aplicativo não deve instalar binários de 16 bits. O aplicativo não deve instalar um driver de modo kernel de 32 bits se ele deve ser executado em um computador de 64 bits.
• Ações corretivas
  • Crie os arquivos executáveis e drivers para a arquitetura do processador para a qual você deseja instalá-los.

Teste de verificação de versão do sistema operacional

Testa como o aplicativo verifica a versão do Windows na qual ele está em execução.

• Fundo
  • Os aplicativos verificam a versão do sistema operacional testando uma versão maior ou igual à versão necessária para garantir a compatibilidade com versões futuras do Windows.
• Detalhes do teste
  • Simula a execução do aplicativo em diferentes versões do Windows para ver como ele reage.
• Ações corretivas
  • Teste a versão correta do Windows testando se a versão atual é maior ou igual à versão que seu aplicativo, serviço ou driver precisa.
  • Os instaladores de driver e os módulos de desinstalação nunca devem verificar a versão do sistema operacional.
• Exceções e renúncias
  • As renúncias serão consideradas para aplicativos que atendem aos seguintes critérios: (aplica-se somente à certificação de aplicativos da área de trabalho)
    • Aplicativos que são entregues como um pacote executado no Windows XP, Windows Vista e Windows 7 e precisam verificar a versão do sistema operacional para determinar quais componentes instalar em um determinado sistema operacional.
    • Aplicativos que verificam apenas a versão mínima do sistema operacional (somente durante a instalação, não em runtime) usando apenas as chamadas de API aprovadas e listam o requisito mínimo de versão no manifesto do aplicativo, conforme necessário.
    • Aplicativos de segurança, como aplicativos antivírus e firewall, utilitários do sistema, como utilitários de desfrag e aplicativos de backup, e ferramentas de diagnóstico que verificam a versão do sistema operacional usando apenas as chamadas de API aprovadas.

Teste de UAC (controle de conta de usuário)

Testa o aplicativo para verificar se ele não precisa de permissões desnecessariamente elevadas para ser executado.

• Fundo
  • Um aplicativo que opera ou instala somente quando o usuário é um administrador força os usuários a executar o aplicativo com permissões desnecessariamente elevadas, o que pode permitir que malware insira o computador do usuário.
  • Quando os usuários são sempre forçados a executar aplicativos com tokens de acesso elevados, o aplicativo pode ser servidor como um ponto de entrada para código enganoso ou mal-intencionado. Esse malware pode modificar facilmente o sistema operacional ou, pior, afetar outros usuários. É quase impossível controlar um usuário que tenha acesso total ao administrador, pois os administradores podem instalar aplicativos e executar qualquer aplicativo ou script no computador. Os gerentes de TI estão sempre buscando maneiras de criar "áreas de trabalho padrão" em que os usuários fazem logon como usuários padrão. As áreas de trabalho padrão reduzem consideravelmente os custos do suporte técnico e reduzem a sobrecarga de TI.
  • A maioria dos aplicativos não exige privilégios de administrador em tempo de execução. Uma conta de usuário padrão deve ser capaz de executá-las. Os aplicativos do Windows devem ter um manifesto (inserido ou externo) para definir seu nível de execução que informa aos sistemas operacionais os privilégios necessários para executar o aplicativo. O manifesto do aplicativo só se aplica a arquivos .exe, não .dll arquivos. O UAC (Controle de Conta de Usuário) não inspeciona as DLLs durante a criação do processo. As regras UAC não se aplicam aos serviços da Microsoft. O manifesto do aplicativo pode ser inserido ou externo.
  • Para criar um manifesto, crie um arquivo com o nome <app_name>.exe.manifest e armazene-o no mesmo diretório que o EXE. Observe que qualquer manifesto externo será ignorado se o aplicativo tiver um manifesto interno.
    • Por exemplo, <requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true|false""/>
    • O processo principal do aplicativo deve ser executado como um usuário padrão (asInvoker). Todos os recursos administrativos devem ser movidos para um processo separado que é executado com privilégios administrativos.
    • Os aplicativos voltados para o usuário que exigem privilégios elevados devem ser assinados pelo Authenticode.
• Detalhes do teste
  • Todos os ex-usuários voltados para o usuário devem ser marcados com o atributo asInvoker. Se estiverem marcados como highestAvailable ou requireAdministrator, eles deverão ser assinados corretamente. Qualquer aplicativo exe não deve ter o atributo uiAccess definido como true. Qualquer exe que é executado como um serviço é excluído dessa verificação específica.
• Ações corretivas
  • Examine o arquivo de manifesto do aplicativo para obter as entradas corretas e os níveis de permissão.
• Exceções e renúncias
  • Uma renúncia é necessária para aplicativos que executam seu processo principal com privilégios elevados (requireAdministrator ou mais altas disponíveis). O processo principal é o processo que fornece o ponto de entrada do usuário para o aplicativo.
  • As renúncias serão consideradas para os seguintes cenários:
    • Ferramentas administrativas ou do sistema com nível de execução definido como mais altas Disponíveis, requireAdministrator ou ambos.
    • Somente o aplicativo da estrutura de automação de interface do usuário ou acessibilidade define o sinalizador uiAccess como TRUE para ignorar o isolamento de privilégio de interface do usuário (UIPI). Para iniciar corretamente a utilização do aplicativo, esse sinalizador deve ser assinado pelo Authenticode e deve residir em um local protegido no sistema de arquivos, como Arquivos de Programas.

Aderir às mensagens do gerenciador de reinicialização do sistema

Testa como o aplicativo responde ao desligamento do sistema e reinicia as mensagens.

• Fundo
  • Os aplicativos devem sair o mais rápido possível quando forem notificados de que o sistema está sendo desligado para fornecer uma experiência de desligamento responsivo ou de desligamento para o usuário.
  • Em um desligamento crítico, os aplicativos que retornam FALSE para WM_QUERYENDSESSION serão enviados WM_ENDSESSION e fechados, enquanto aqueles que perderem tempo em resposta a WM_QUERYENDSESSION serão encerrados à força.
• Detalhes do teste
  • Examina como o aplicativo responde para desligar e sair das mensagens.
• Ações corretivas
  • Se o aplicativo falhar neste teste, examine como ele lida com essas mensagens do Windows:
    • WM_QUERYENDSESSION com = ENDSESSION_CLOSEAPPLPARAM (0x1): os aplicativos de área de trabalho devem responder (TRUE) imediatamente em preparação para uma reinicialização. Os aplicativos de console podem chamar SetConsoleCtrlHandler para receber uma notificação de desligamento. Os serviços podem chamar RegisterServiceCtrlHandlerEx para receber notificações de desligamento em uma rotina de manipulador.
    • WM_ENDSESSION com = ENDSESSION_CLOSEAPPLPARAM (0x1): os aplicativos devem retornar um valor 0 dentro de 30 segundos e desligar. No mínimo, os aplicativos devem se preparar salvando todos os dados do usuário e indicar as informações necessárias após uma reinicialização.
  • Os aplicativos de console que recebem a notificação de CTRL_C_EVENT devem ser desligados imediatamente. Os motoristas não devem vetar um evento de desligamento do sistema.
  • Observação: Aplicativos que devem bloquear o desligamento devido a uma operação que não pode ser interrompida devem usar ShutdownBlockReasonCreate para registrar uma cadeia de caracteres que explique o motivo para o usuário. Quando a operação for concluída, o aplicativo deverá chamar ShutdownBlockReasonDestroy para indicar que o sistema pode ser desligado.

Teste de modo seguro

Testa se o driver ou serviço está configurado para iniciar no modo de segurança.

• Fundo
  • O modo de segurança permite que os usuários diagnosticem e solucionem problemas com o Windows. Somente os drivers e os serviços necessários para a operação básica do sistema operacional ou que fornecem serviços de diagnóstico e recuperação devem ser carregados no modo de segurança. Carregar outros arquivos no modo de segurança torna mais difícil solucionar problemas com o sistema operacional.
  • Por padrão, somente os drivers e os serviços que vêm pré-instalados com o Windows começam no modo de segurança. Todos os outros drivers e serviços devem ser desabilitados, a menos que o sistema os exija para operações básicas ou para fins de diagnóstico e recuperação.
• Detalhes do teste
  • Os drivers instalados pelo aplicativo não devem ser marcados para carregamento no modo de segurança.
• Ações corretivas
  • Se o driver ou serviço não deve começar no modo de segurança, remova as entradas do aplicativo das chaves do Registro.
• Exceções e renúncias
  • Os drivers e os serviços que devem começar no modo de segurança exigem que uma renúncia seja certificada. A solicitação de renúncia deve incluir cada driver e serviço para adicionar às chaves do Registro SafeBoot e descrever os motivos técnicos pelos quais o driver ou serviço deve ser executado no modo de segurança. O instalador de aplicativo deve registrar todos esses drivers e serviços nessas chaves do Registro:
    • HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal
    • HKLM/System/CurrentControlSet/Control/SafeBoot/Network
• Observação: Você deve testar os drivers e os serviços que deseja iniciar no modo de segurança para garantir que eles funcionem no modo de segurança sem erros.

Teste de sessão multiusuário

Teste como o aplicativo se comporta quando executado em várias sessões ao mesmo tempo.

• Fundo
  • Os usuários do Windows devem ser capazes de executar sessões simultâneas. Os aplicativos devem garantir que, quando forem executados em várias sessões, local ou remotamente, a funcionalidade normal do aplicativo não seja afetada negativamente. As configurações do aplicativo e os arquivos de dados devem ser específicos do usuário e a privacidade e as preferências do usuário devem ser restritas à sessão do usuário.
• Detalhes do teste
  • Executa várias instâncias simultâneas do aplicativo para testar o seguinte:
    • Várias instâncias de um aplicativo em execução ao mesmo tempo são isoladas umas das outras.
  • Isso significa que os dados do usuário de uma instância não estão visíveis para outra instância. O som em uma sessão de usuário inativa não deve ser ouvido em uma sessão de usuário ativa. Nos casos em que várias instâncias de aplicativo usam recursos compartilhados, o aplicativo deve garantir que não haja conflito.
    • Se o aplicativo foi instalado para vários usuários, ele armazena dados nas pastas corretas e nos locais do Registro.
    • O aplicativo pode ser executado em várias sessões de usuário (Comutação Rápida de Usuário) para acesso local e remoto.
  • Para garantir isso, o aplicativo deve verificar outras sessões de serviço de terminal (TS) em busca de instâncias existentes do aplicativo. Se o aplicativo não der suporte a várias sessões de usuário ou acesso remoto, ele deverá dizer isso claramente ao usuário quando ele for iniciado de tal sessão.
• Ação corretiva
  • Verifique se o aplicativo não armazena arquivos de dados em todo o sistema ou configurações em armazenamentos de dados específicos do usuário, como Perfil de Usuário ou HKCU. Se isso acontecer, essas informações não estarão disponíveis para outros usuários.
  • Seu aplicativo deve instalar arquivos de dados e configuração em todo o sistema durante a instalação e criar os arquivos e configurações específicos do usuário após a instalação quando um usuário o executa.
  • Verifique se o aplicativo não bloqueia várias sessões simultâneas, local ou remotamente. O aplicativo não deve depender de mutexes globais ou outros objetos nomeados para verificar ou bloquear várias sessões simultâneas.
  • Se o aplicativo não puder permitir várias sessões simultâneas por usuário, use namespaces por usuário ou por sessão para mutexes e outros objetos nomeados.

Falha e trava o teste

Monitora o aplicativo durante o teste de certificação para registrar quando ele falha ou trava.

• Fundo
  • Falhas de aplicativo, como falhas e travamentos, são uma grande interrupção para os usuários e causam frustração. Eliminar essas falhas melhora a estabilidade e a confiabilidade do aplicativo e, no geral, fornece aos usuários uma melhor experiência de aplicativo. Aplicativos que param de responder ou falha podem fazer com que o usuário perca dados e tenha uma experiência ruim.
• Detalhes do teste
  • Testamos a resiliência e a estabilidade do aplicativo durante o teste de certificação.
  • O Kit de Certificação de Aplicativos do Windows chama IApplicationActivationManager::ActivateApplication para iniciar aplicativos da Windows Store. Para ActivateApplication para iniciar um aplicativo, o Controle de Conta de Usuário (UAC) deve estar habilitado e a resolução da tela deve ser pelo menos 1024 x 768 ou 768 x 1024. Se qualquer uma das condições não for atendida, seu aplicativo falhará neste teste.
• Ações corretivas
  • Verifique se o UAC está habilitado no computador de teste.
  • Verifique se você está executando o teste em um computador com tela grande o suficiente.
  • Se o aplicativo não for iniciado e sua plataforma de teste atender aos pré-requisitos de ActivateApplication, você poderá solucionar o problema examinando o log de eventos de ativação. Para localizar essas entradas no log de eventos:
    1. Abra eventvwr.exe e navegue até o nó \Windows Logs\Application.
    2. Filtre a exibição para mostrar IDs de evento: 5900-6000.
    3. Examine as entradas de log para obter informações que possam explicar por que o aplicativo não foi iniciado.
  • Solucione o arquivo com o problema, identifique e corrija o problema. Recompile e teste novamente o aplicativo.
• Recursos adicionais
  • usando o Verificador de Aplicativos em seu ciclo de vida de desenvolvimento de software
  • do Verificador de Aplicativos
  • usando do Verificador de Aplicativos
  • de DLLs do AppInit
  • Minimizar o tempo de inicialização (aplicativos da Windows Store usando C#/VB/C++ e XAML)

Teste de compatibilidade e resiliência

• Fundo
  • Essa verificação validará dois aspectos de um aplicativo, os principais executáveis do aplicativo, por exemplo, o ponto de entrada do aplicativo voltado para o usuário deve ser manifestado para compatibilidade, além de declarar o GUID correto. Para dar suporte a esse novo teste, o relatório terá um sub nó em 'Compatibilidade & resiliência'. O aplicativo falhará se uma ou ambas as condições estiverem ausentes.
• Detalhes do teste
  • Compatibilidade: Aplicativos devem ser totalmente funcionais sem usar modos de compatibilidade do Windows, mensagens AppHelp ou outras correções de compatibilidade. Um manifesto de compatibilidade permite que o Windows forneça ao seu aplicativo o comportamento de compatibilidade adequado nas diferentes versões do sistema operacional
  • AppInit: Apps não devem listar DLLs para carregar na chave do registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs.
  • Alternância: O aplicativo deve fornecer o manifesto de alternância. Se o manifesto estiver ausente, o Kit de Certificação de Aplicativos do Windows fornecerá uma mensagem de aviso. O Kit de Certificação de Aplicativos do Windows também verificará se o manifesto contém GUID do sistema operacional válido.
• Ações corretivas
  • Corrija o componente do aplicativo que usa a correção de compatibilidade.
  • Verifique se o aplicativo não depende de correções de compatibilidade para sua funcionalidade.
  • Verifique se o aplicativo está manifestado e se a seção de compatibilidade inclui os valores apropriados
• Informações adicionais
  • Consulte de DLLs do AppInit para obter mais informações.

Teste de práticas recomendadas de Segurança do Windows

• Fundo
  • Um aplicativo não deve alterar as configurações de segurança padrão do Windows
• Detalhes do teste
  • Testa a segurança do aplicativo executando o Analisador de Superfície de Ataque. A abordagem será adicionar categorias de falha por teste. Por exemplo, algumas categorias para teste de segurança podem incluir:
    • Falha de inicialização
    • Falha na arquitetura de segurança
    • Possível falha de estouro do buffer
    • Falha de falha
  • Para obter detalhes, consulte aqui.
• Ações corretivas
  • Solucione e corrija o problema identificado pelos testes. Recompile e teste novamente o aplicativo.

Teste de recursos de segurança do Windows

• Fundo
  • Os aplicativos devem aceitar os recursos de segurança do Windows. Alterar as proteções de segurança padrão do Windows pode colocar os clientes em maior risco.
• Detalhes do teste
  • Testa a segurança do aplicativo executando o BinScope Binary Analyzer. Para obter detalhes, consulte aqui.
• Ações corretivas
  • Solucione e corrija o problema identificado pelos testes. Recompile e teste novamente o aplicativo.

Teste de DPI alto

É altamente recomendável que os aplicativos Win32 estejam cientes do DPI. É a chave para fazer com que a interface do usuário do aplicativo pareça consistentemente boa em uma ampla variedade de configurações de exibição de alta DPI. Um aplicativo sem reconhecimento de DPI em execução em uma configuração de exibição de alta DPI pode ter problemas como dimensionamento incorreto de elementos de interface do usuário, texto recortado e imagens desfocadas. Há duas maneiras de declarar que um aplicativo está ciente do DPI. Uma delas é declarar o DPI.

• Fundo
  • Essa verificação validará dois aspectos de um aplicativo, por exemplo, os principais pontos de entrada de aplicativo voltados para o usuário devem ser manifestados para HIGH-DPI reconhecimento e que as APIs adequadas estão sendo chamadas para dar suporte a HIGH-DPI. O aplicativo falhará se uma ou ambas as condições estiverem ausentes. Essa verificação apresentará uma nova seção no relatório da área de trabalho, veja o exemplo abaixo.
• Detalhes do teste
  • O teste gerará um aviso quando detectarmos qualquer um dos seguintes:
    • O EXE principal não declara reconhecimento de DPI em seu manifesto e não chama a API SetProcessDPIAware. (Avisar o desenvolvedor se ele esquecer de adicionar o manifesto de reconhecimento de DPI).
    • O EXE principal não declara reconhecimento de DPI em seu manifesto, mas chama a API SetProcessDPIAware (avisar o desenvolvedor de que ele deve usar o manifesto para declarar reconhecimento de DPI em vez de chamar a API).
    • O mainEXE declara reconhecimento de DPI em seu manifesto, mas também chama a API SetProcessDPIAware (avisar o desenvolvedor de que chamar essa API não é necessária).
    • Para os binários que não são EXEs principais, se eles chamarem a API, dê um aviso (não é recomendável chamar a API).
• Ações corretivas
  • O uso da função SetProcessDPIAware() é desencorajado. Se uma DLL armazenar em cache as configurações de DPI durante sua inicialização, invocar SetProcessDPIAware() no aplicativo poderá gerar uma condição de corrida. Chamar a função SetProcessDPIAware() em uma DLL também não é uma boa prática.
• Informações adicionais
  • de High-DPI gravação de aplicativos