Testes do Kit de Certificação de Aplicativos 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 Windows.

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

Instalação reversível limpa

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

• Tela de fundo
  • Uma instalação reversível limpo permite que os usuários implantem e removam aplicativos. Para passar nesse 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 nomes de arquivo longos 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
    • Publisher
    • UninstallString
    • 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 o programa e os arquivos de dados nas pastas corretas.

• Tela de 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 de que precisam, 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).
  • Nota: O aplicativo não deve armazenar dados de usuário ou de 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 nelas. 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.
  • Nota: 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 presença da virtualização 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 serão bem-sucedidas. 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 não devem ser compartilhados com outros usuários do computador devem ser armazenados em Users\<username>\AppData.
  • Todos os dados do aplicativo que devem ser compartilhados entre os usuários no computador devem ser armazenados em 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 iniciar automaticamente na inicialização, como adicionando uma entrada a um ou mais desses locais:
    • Chaves de execução do Registro HKLM e ou HKCU em Software\Microsoft\Windows\CurrentVersion
    • Chaves de execução do Registro HKLM e ou HKCU em Software\Wow6432Node\Microsoft\windows\CurrentVersion
    • Iniciar Menu AllPrograms > STARTUP
• Detalhes do teste
  • Esse 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 de aplicativos compartilhados 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 do SW, somente na categoria 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.

• Tela de fundo
  • Arquivos assinados digitalmente possibilitam verificar se o arquivo é original 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 de 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 a 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 pelo 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 comercial (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. É necessária uma prova de comunicação solicitando uma versão assinada dos redistribuíveis 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.

• Tela de 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 os identificadores têm 32 bits significativos no Windows de 64 bits para que não possam ser passados para aplicativos de 16 bits. Portanto, tentar 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 sob o emulador WoW64 não devem tentar ignorar os mecanismos de virtualização 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.

• Tela de fundo
  • Os aplicativos marcar 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 de que seu aplicativo, serviço ou driver precisa.
  • Os instaladores de driver e os módulos de desinstalação nunca devem marcar 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 marcar a versão do sistema operacional para determinar quais componentes instalar em um determinado sistema operacional.
    • Aplicativos que marcar 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 desfragmento e aplicativos de backup, e ferramentas de diagnóstico que marcar a versão do sistema operacional usando apenas as chamadas de API aprovadas.

Teste do 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.

• Tela de 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 entre no 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 tem acesso total de 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 de 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 ao sistema operacional 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 DLLs durante a criação do processo. As regras do 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 de main 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 pela Authenticode.
• Detalhes do teste
  • Todos os exes voltados para o usuário devem ser marcados com o atributo asInvoker. Se estiverem marcados como mais altos Disponíveis ou exigirEmAdministrador, eles deverão ser assinados corretamente. Qualquer aplicativo exe não deve ter o atributo uiAccess definido como true. Qualquer exe executado como um serviço é excluído deste marcar específico.
• Ações corretivas
  • Examine o arquivo de manifesto do aplicativo para obter as entradas e os níveis de permissão corretos.
• Exceções e renúncias
  • Uma renúncia é necessária para aplicativos que executam seu processo de main com privilégios elevados (requireAdministrator ou highestAvailable). O processo main é 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 alto Disponível, 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égios de interface do usuário (UIPI). Para iniciar corretamente a utilização do aplicativo, esse sinalizador deve ser assinado pela 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 reinicializa as mensagens.

• Tela de 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 atingirem o tempo limite 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 seu aplicativo falhar neste teste, examine como ele lida com essas mensagens do Windows:
    • WM_QUERYENDSESSION com LPARAM = ENDSESSION_CLOSEAPP(0x1): os aplicativos da área de trabalho devem responder (TRUE) imediatamente em preparação para uma reinicialização. Os aplicativos de console podem chamar SetConsoleCtrlHandler para receber notificação de desligamento. Os serviços podem chamar RegisterServiceCtrlHandlerEx para receber notificações de desligamento em uma rotina de manipulador.
    • WM_ENDSESSION com LPARAM = ENDSESSION_CLOSEAPP(0x1): os aplicativos devem retornar um valor 0 dentro de 30 segundos e desligar. No mínimo, os aplicativos devem se preparar salvando os dados do usuário e declarar 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 drivers não devem vetar um evento de desligamento do sistema.
  • Nota: Os 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 explica 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 do modo de segurança

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

• Tela de fundo
  • O modo de segurança permite que os usuários diagnosticem e solucionem problemas com o Windows. Somente os drivers e 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 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 iniciar no modo de segurança, remova as entradas do aplicativo das chaves do Registro.
• Exceções e renúncias
  • Os drivers e serviços que devem começar no modo de segurança exigem a certificação de uma renúncia. 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
• Nota: 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.

• Tela de fundo
  • Os usuários do Windows devem ser capazes de executar sessões simultâneas. Os aplicativos devem garantir que, quando 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 um 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 marcar outras sessões de TS (serviço de terminal) para 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 ou configurações de dados em todo o sistema 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 marcar 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.

• Tela de fundo
  • Falhas de aplicativo, como falhas e travamentos, são uma grande interrupção para os usuários e causam frustração. A eliminação dessas 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 travam podem provocar a perda de dados do usuário ou uma experiência insatisfatória.
• Detalhes do teste
  • Testamos a resiliência e a estabilidade do aplicativo por meio do teste de certificação.
  • O Kit de Certificação de Aplicativos Windows chama IApplicationActivationManager::ActivateApplication para iniciar aplicativos da Windows Store. Para que o ActivateApplication inicie um aplicativo, o UAC (Controle de Conta de Usuário) deve estar habilitado, e a resolução da tela deve ser de pelo menos 1024 x 768 ou 768 x 1024. Se nenhuma condição for atendida, o aplicativo falhará nesse 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 uma tela grande o suficiente.
  • Se o aplicativo falhar para iniciar e sua plataforma de teste satisfizer os pré-requisitos do ActivateApplication, você poderá solucionar o problema analisando o log de eventos de ativação. Para encontrar essas entradas no log de eventos:
    1. Abra eventvwr.exe e navegue até o nó \Logs do Windows\Aplicativo.
    2. Filtre a exibição para mostrar as IDs de Evento: 5900-6000.
    3. Analise as entradas do log para obter informações que possam explicar por que o aplicativo não foi iniciado.
  • Identifique e solucione o problema com o arquivo. Compile e teste novamente o aplicativo.
• Recursos adicionais
  • Usando o Verificador de Aplicativos em seu ciclo de vida de desenvolvimento de software
  • Verificador de Aplicativos
  • Usando o Verificador de Aplicativos
  • AppInit DLLs
  • {1&gt;{2&gt;Minimizar o tempo de inicialização (aplicativos da Windows Store usando C#/VB/C++ e XAML)&lt;2}&lt;1}

Teste de compatibilidade e resiliência

• Tela de fundo
  • Essa marcar validará dois aspectos de um aplicativo, o aplicativo main executáveis, por exemplo, o ponto de entrada do aplicativo voltado para o usuário deve ser manifestado para compatibilidade, bem como declarar o GUID correto. Para dar suporte a esse novo teste, o relatório terá um sub nó em "Resiliência de compatibilidade & ". O aplicativo falhará se uma ou ambas as condições estiverem ausentes.
• Detalhes do teste
  • Compatibilidade: Os 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: Os aplicativos não devem listar DLLs para carregar na chave do Registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs.
  • Switchback: O aplicativo deve fornecer o manifesto de retorno de alternância. Se o manifesto estiver ausente, o Kit de Certificação de Aplicativos Windows fornecerá uma mensagem de aviso. O Kit de Certificação de Aplicativos 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 DLLs appInit para obter mais informações.

Segurança do Windows teste de práticas recomendadas

• Tela de 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 de buffer
    • Falha na falha
  • Para obter detalhes, consulte aqui.
• Ações corretivas
  • Solucione e corrija o problema identificado pelos testes. Compile e teste novamente o aplicativo.

Teste de recursos de segurança do Windows

• Tela de 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 risco elevado.
• Detalhes do teste
  • Testa a segurança do aplicativo executando o Analisador de Binários BinScope. Para obter detalhes, consulte aqui.
• Ações corretivas
  • Solucione e corrija o problema identificado pelos testes. Compile e teste novamente o aplicativo.

Teste de alto DPI

É 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 alto 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.

• Tela de fundo
  • Essa marcar validará dois aspectos de um aplicativo, os main executáveis, por exemplo, os pontos de entrada do aplicativo voltados para o usuário devem ser manifestados para reconhecimento de ALTO DPI 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. Este marcar 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:
    • A main EXE não declara reconhecimento de DPI em seu manifesto e não chama a API SetProcessDPIAware. (Avise o desenvolvedor se ele esquecer de adicionar o manifesto de reconhecimento de DPI).
    • O main EXE não declara reconhecimento de DPI em seu manifesto, mas chama a API SetProcessDPIAware (avise o desenvolvedor de que ele deve usar o manifesto para declarar a conscientização de DPI em vez de chamar a API).
    • O mainEXE declara reconhecimento de DPI em seu manifesto, mas também chama a API SetProcessDPIAware (avise o desenvolvedor de que chamar essa API não é necessária).
    • Para os binários que não são main EXEs, 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
  • Escrever aplicativos de Alta DPI