Condividi tramite

Test del Kit di certificazione app Windows

  • Articolo

Di seguito sono riportati i dettagli dei test per certificare le app desktop. Per informazioni, vedere Uso del Kit di certificazione app Windows.

Installazione reversibile pulita

Installa e disinstalla l'app e verifica la presenza di file residui e voci del Registro di sistema.

  • Priorità bassa
    • Un'installazione pulita e reversibile consente agli utenti di distribuire e rimuovere app. Per superare questo test, l'app deve eseguire le operazioni seguenti:
      • L'app non forza il riavvio del sistema immediatamente dopo l'installazione o la disinstallazione dell'app. Il processo di installazione o disinstallazione di un'app non deve mai richiedere un riavvio del sistema subito dopo il completamento. Se è necessario riavviare il sistema, gli utenti devono essere in grado di riavviare il sistema per comodità.
      • L'app non dipende dai nomi di file brevi (SFN) 8.3. I processi di installazione e disinstallazione dell'app devono essere in grado di usare nomi di file lunghi e percorsi di cartella.
      • L'app non blocca l'installazione/disinstallazione invisibile all'utente
      • L'app crea le voci necessarie nel Registro di sistema. Gli strumenti di inventario di Windows e gli strumenti di telemetria richiedono informazioni complete sulle app installate. I programmi di installazione delle app devono creare le voci corrette del Registro di sistema per consentire il rilevamento e la disinstallazione riusciti.
    • Se si usa un programma di installazione basato su MSI, MSI crea automaticamente le voci del Registro di sistema seguenti. Se non si usa un programma di installazione MSI, il modulo di installazione deve creare le voci del Registro di sistema seguenti durante l'installazione:
      • DisplayName
      • InstallLocation
      • Publisher
      • UninstallString
      • VersionMajor o MajorVersion
      • VersionMinor o MinorVersion
    • L'app deve rimuovere tutte le relative voci in Installazione applicazioni.
  • Dettagli test
    • Questo test controlla i processi di installazione e disinstallazione dell'app per il comportamento richiesto.
  • Azione correttiva
    • Esaminare la progettazione e il comportamento dell'app in base ai requisiti descritti in precedenza.

Eseguire l'installazione nel test delle cartelle corrette

Verifica che l'app scriva il programma e i file di dati nelle cartelle corrette.

  • Priorità bassa
    • Le app devono essere di sistema e cartelle per utente correttamente in modo che possano accedere ai dati e alle impostazioni necessarie proteggendo al tempo stesso i dati e le impostazioni dell'utente da accessi non autorizzati.
  • Cartelle programmi
    • L'app deve essere installata nella cartella Programmi per impostazione predefinita (%ProgramFiles% per app native a 32 bit e a 64 bit e %ProgramFiles(x86)% per le app a 32 bit in esecuzione in x64.
    • Nota: l'app non deve archiviare i dati utente o i dati dell'app in una cartella Programmi a causa delle autorizzazioni di sicurezza configurate per questa cartella.
    • Gli elenchi di controllo di accesso nelle cartelle di sistema di Windows consentono solo agli account amministratore di leggere e scrivere. Di conseguenza, gli account utente standard non avranno accesso a queste cartelle. La virtualizzazione dei file, tuttavia, consente alle app di archiviare un file, ad esempio un file di configurazione, in un percorso di sistema che in genere è scrivibile solo dagli amministratori. L'esecuzione di programmi come utente standard in questa situazione potrebbe causare un errore se non riesce ad accedere a un file necessario.
    • Le app devono usare cartelle note per assicurarsi che possano accedere ai dati.
    • Nota: Windows fornisce la virtualizzazione dei file per migliorare la compatibilità delle app ed eliminare i problemi quando le app vengono eseguite come utente standard in Windows. L'app non deve basarsi sulla virtualizzazione presente nelle versioni future di Windows.
  • Cartelle dati dell'app specifiche dell'utente
    • Nelle installazioni "per computer", l'app non deve scrivere dati specifici dell'utente durante l'installazione. I dati di installazione specifici dell'utente devono essere scritti solo quando un utente avvia l'app per la prima volta. Ciò è dovuto al fatto che non esiste un percorso utente corretto in cui archiviare i dati al momento dell'installazione. I tentativi da parte di un'app di modificare i comportamenti di associazione predefiniti a livello di computer dopo l'installazione avranno esito negativo. Le impostazioni predefinite devono invece essere richieste a livello di utente, che impedisce a più utenti di sovrascrivere le impostazioni predefinite dell'altro.
    • Tutti i dati dell'app esclusivi di un utente specifico e non condivisi con altri utenti del computer devono essere archiviati in Users\<username>\AppData.
    • Tutti i dati dell'app che devono essere condivisi tra gli utenti nel computer devono essere archiviati all'interno di ProgramData.
  • Altre cartelle di sistema e chiavi del Registro di sistema
    • L'app non deve mai scrivere direttamente nella directory e nelle sottodirectory di Windows. Utilizzare i metodi corretti per l'installazione di file, ad esempio tipi di carattere o driver, in queste directory.
    • Le app non devono essere avviate automaticamente all'avvio, ad esempio aggiungendo una voce a una o più di queste posizioni:
      • Chiavi di esecuzione del Registro di sistema HKLM e HKCU in Software\Microsoft\Windows\CurrentVersion
      • Chiavi di esecuzione del Registro di sistema HKLM e o HKCU in Software\Wow6432Node\Microsoft\windows\CurrentVersion
      • Start Menu AllPrograms > STARTUP
  • Dettagli test
    • Questo test verifica che l'app usi i percorsi specifici nel file system fornito da Windows per archiviare programmi e componenti software, dati di app condivisi e dati dell'app specifici di un utente.
  • Azioni correttive
    • Esaminare il modo in cui l'app usa le cartelle del sistema e assicurarsi che vengano usate correttamente.
  • Eccezioni e eccezioni
    • Una rinuncia è necessaria per le app desktop che scrivono nella Global Assembly Cache (GAC) (le app .NET devono mantenere private le dipendenze degli assembly e archiviarla nella directory dell'app, a meno che non sia richiesta esplicitamente la condivisione di un assembly).
    • L'installazione nella cartella Programmi file non è un requisito per i pacchetti SW desktop per ottenere il logo SW, solo nella categoria SW Fundamentals.

Test dei file con firma digitale

Verifica i file eseguibili e i driver di dispositivo per verificare che abbiano una firma digitale valida.

  • Priorità bassa
    • I file firmati digitalmente consentono di verificare che il file sia originale e di rilevare se il file è stato manomesso.
    • L'imposizione della firma del codice in modalità kernel è una funzionalità di Windows nota anche come integrità del codice (CI). L'integrazione continua migliora la sicurezza di Windows verificando l'integrità di un file ogni volta che viene caricato in memoria. Ci rileva se il codice dannoso ha modificato un file binario di sistema e genera un evento del log di diagnostica e di controllo del sistema quando la firma di un modulo kernel non riesce a verificarsi correttamente.
    • Se l'app richiede autorizzazioni elevate, la richiesta di elevazione dei privilegi visualizza informazioni contestuali sul file eseguibile che richiede l'accesso con privilegi elevati. A seconda che l'app sia autenticata, l'utente potrebbe visualizzare la richiesta di consenso o la richiesta di credenziali.
    • I nomi sicuri impediscono a terze parti di eseguire lo spoofing del codice, purché la chiave privata venga protetta. .NET Framework verifica la firma digitale quando carica l'assembly o lo installa nella GAC. Senza l'accesso alla chiave privata, un utente malintenzionato non può modificare il codice e firmarlo di nuovo.
  • Dettagli test
    • Tutti i file eseguibili, ad esempio quelli con estensioni di file con estensione exe, dll, .ocx, .sys, .cpl, .drv e .scr, devono essere firmati con un certificato Authenticode.
    • Tutti i driver in modalità kernel installati dall'app devono avere una firma Microsoft ottenuta tramite il programma WHQL o DRS. Tutti i driver di filtro del file system devono essere firmati WHQL.
  • Azione correttiva
    • Firmare i file eseguibili dell'app.
    • Usare makecert.exe per generare un certificato o ottenere una chiave di firma del codice da una delle autorità di certificazione commerciali , ad esempio VeriSign, Thawte o una CA Microsoft.
  • Eccezioni e rinuncia
    • Le rinunce saranno considerate solo per i ridistribuibili non firmati di terze parti. È necessaria una prova di comunicazione che richiede una versione firmata dei ridistribuibili per concedere questa rinuncia.
    • I pacchetti software aggiunti a valore del dispositivo sono esenti dalla certificazione del driver in modalità kernel, perché i driver devono essere certificati in da Certificazione hardware Windows.

Supportare il test di Windows x64

Testare l'app per assicurarsi che il file exe sia compilato per l'architettura della piattaforma in cui verrà installato.

  • Priorità bassa
    • Il file eseguibile deve essere compilato per l'architettura del processore in cui è installato. Alcuni file eseguibili potrebbero essere eseguiti in un'architettura del processore diversa, ma questo non è affidabile.
    • La compatibilità dell'architettura è importante perché i processi a 32 bit non possono caricare DLL a 64 bit e i processi a 64 bit non possono caricare DLL a 32 bit. Analogamente, le versioni a 64 bit di Windows non supportano l'esecuzione di applicazioni basate su Windows a 16 bit perché gli handle hanno 32 bit significativi in Windows a 64 bit, in modo che non possano essere passati alle applicazioni a 16 bit. Pertanto, il tentativo di avviare un'applicazione a 16 bit avrà esito negativo nelle versioni a 64 bit di Windows.
    • I driver di dispositivo a 32 bit non possono essere eseguiti in versioni a 64 bit di Windows e pertanto devono essere trasferiti nell'architettura a 64 bit.
    • Per le applicazioni in modalità utente, Windows a 64 bit include WOW64, che consente l'esecuzione di applicazioni Windows a 32 bit nei sistemi che eseguono Windows a 64 bit, anche se con alcune perdite di prestazioni. Non esiste alcun livello di conversione equivalente per i driver di dispositivo.
    • Per mantenere la compatibilità con le versioni a 64 bit di Windows, le app devono supportare in modo nativo a 64 bit o, almeno, le app basate su Windows a 32 bit devono essere eseguite senza problemi nei sistemi a 64 bit:
      • Le app e i relativi programmi di installazione non devono contenere codice a 16 bit o basarsi su qualsiasi componente a 16 bit.
      • L'installazione dell'app deve rilevare e installare i driver e i componenti appropriati nelle versioni a 64 bit di Windows.
      • Tutti i plug-in della shell devono essere eseguiti in versioni a 64 bit di Windows.
      • Le app eseguite nell'emulatore WoW64 non devono tentare di ignorare i meccanismi di virtualizzazione Wow64. Se esistono scenari specifici in cui le app devono rilevare se sono in esecuzione in un emulatore WoW64, devono farlo chiamando IsWow64Process.
  • Dettagli test
    • L'app non deve installare file binari a 16 bit. L'app non deve installare un driver in modalità kernel a 32 bit se dovrebbe essere eseguito in un computer a 64 bit.
  • Azioni correttive
    • Compilare i file eseguibili e i driver per l'architettura del processore per cui si desidera installarli.

Test di controllo della versione del sistema operativo

Verifica come l'app verifica la versione di Windows in cui è in esecuzione.

  • Priorità bassa
    • Le app controllano la versione del sistema operativo testando una versione maggiore o uguale alla versione necessaria per garantire la compatibilità con le versioni future di Windows.
  • Dettagli test
    • Simula l'esecuzione dell'app in versioni diverse di Windows per vedere come reagisce.
  • Azioni correttive
    • Testare la versione corretta di Windows testando se la versione corrente è maggiore o uguale alla versione necessaria per l'app, il servizio o il driver.
    • I programmi di installazione dei driver e i moduli di disinstallazione non devono mai controllare la versione del sistema operativo.
  • Eccezioni e eccezioni
    • Le rinuncia verranno considerate per le app che soddisfano i criteri seguenti: (si applica solo alla certificazione dell'app desktop)
      • Le app recapitate come pacchetto eseguito in Windows XP, Windows Vista e Windows 7 devono controllare la versione del sistema operativo per determinare quali componenti installare in un determinato sistema operativo.
      • Le app che controllano solo la versione minima del sistema operativo (solo durante l'installazione, non in fase di esecuzione) usando solo le chiamate API approvate ed elencano il requisito di versione minima nel manifesto dell'app in base alle esigenze.
      • App di sicurezza come app antivirus e firewall, utilità di sistema come utilità di deframmentazione e app di backup e strumenti di diagnostica che controllano la versione del sistema operativo usando solo le chiamate API approvate.

Test del Controllo dell'account utente

Testa l'app per verificare che non siano necessarie autorizzazioni inutilmente elevate per l'esecuzione.

  • Priorità bassa
    • Un'app che opera o installa solo quando l'utente è un amministratore impone agli utenti di eseguire l'app con autorizzazioni inutilmente elevate, che possono consentire al malware di accedere al computer dell'utente.
    • Quando gli utenti sono sempre costretti a eseguire app con token di accesso elevati, l'app può essere server come punto di ingresso per codice ingannevole o dannoso. Questo malware può facilmente modificare il sistema operativo, o peggio, influenzare altri utenti. È quasi impossibile controllare un utente con accesso amministratore completo, perché Amministrazione istrator può installare le app ed eseguire qualsiasi app o script nel computer. I responsabili IT cercano sempre modi per creare "desktop standard" in cui gli utenti accedono come utenti standard. I desktop standard riducono notevolmente i costi dell'help desk e riducono il sovraccarico IT.
    • La maggior parte delle applicazioni non richiede privilegi di amministratore in fase di esecuzione. Un account utente standard deve essere in grado di eseguirli. Le app di Windows devono avere un manifesto (incorporato o esterno) per definire il livello di esecuzione che indica al sistema operativo i privilegi necessari per eseguire l'app. Il manifesto dell'app si applica solo ai file con estensione exe, non ai file DLL. Il controllo dell'account utente non controlla le DLL durante la creazione del processo. Le regole di controllo dell'account utente non si applicano alle servizi Microsoft. Il manifesto dell'app può essere incorporato o esterno.
    • Per creare un manifesto, creare un file con il nome <app_name.exe.manifest> e archiviarlo nella stessa directory del file EXE. Si noti che qualsiasi manifesto esterno viene ignorato se l'app ha un manifesto interno.
      • Ad esempio, <requestedExecutionLevel level=""asInvoker | highestAvailable | require Amministrazione istrator"" uiAccess=""true|false""/>
      • Il processo principale dell'app deve essere eseguito come utente standard (asInvoker). Tutte le funzionalità amministrative devono essere spostate in un processo separato eseguito con privilegi amministrativi.
      • Le app rivolte agli utenti che richiedono privilegi elevati devono essere firmate Authenticode.
  • Dettagli test
    • Tutti gli exe con connessione utente devono essere contrassegnati con l'attributo asInvoker. Se sono contrassegnati come highestAvailable o require Amministrazione istrator, devono essere firmati correttamente authenticode. Qualsiasi exe dell'app non deve avere l'attributo uiAccess impostato su true. Qualsiasi exe eseguito come servizio viene escluso da questo particolare controllo.
  • Azioni correttive
    • Esaminare il file manifesto dell'app per individuare le voci corrette e i livelli di autorizzazione.
  • Eccezioni e rinuncia
    • Una rinuncia è necessaria per le app che eseguono il processo principale con privilegi elevati (richiedono Amministrazione istrator o più altaDisponibile). Il processo principale è il processo che fornisce all'app il punto di ingresso dell'utente.
    • Le rinunce verranno considerate per gli scenari seguenti:
      • Amministrazione istrative o strumenti di sistema con livello di esecuzione impostato su highestAvailable, require Amministrazione istrator o entrambi.
      • Solo l'accessibilità o l'app framework di automazione interfaccia utente imposta il flag uiAccess su TRUE per ignorare l'isolamento dei privilegi dell'interfaccia utente.Only Accessibility or UI automation framework app set the uiAccess flag to TRUE to bypass the user interface privilege isolation (UIPI). Per avviare correttamente l'utilizzo dell'app, questo flag deve essere firmato Authenticode e deve trovarsi in un percorso protetto nel file system, ad esempio Programmi.

Rispettare i messaggi di gestione del riavvio del sistema

Verifica il modo in cui l'app risponde ai messaggi di arresto e riavvio del sistema.

test della modalità Cassaforte

Verifica se il driver o il servizio è configurato per l'avvio in modalità provvisoria.

  • Priorità bassa
    • Cassaforte modalità consente agli utenti di diagnosticare e risolvere i problemi relativi a Windows. Solo i driver e i servizi necessari per il funzionamento di base del sistema operativo o fornire servizi di diagnostica e ripristino devono essere caricati in modalità provvisoria. Il caricamento di altri file in modalità provvisoria rende più difficile risolvere i problemi relativi al sistema operativo.
    • Per impostazione predefinita, solo i driver e i servizi preinstallati con Windows vengono avviati in modalità provvisoria. Tutti gli altri driver e servizi devono essere disabilitati a meno che il sistema non li richieda per operazioni di base o per scopi di diagnostica e ripristino.
  • Dettagli test
    • I driver installati dall'app non devono essere contrassegnati per il caricamento in modalità provvisoria.
  • Azioni correttive
    • Se il driver o il servizio non deve essere avviato in modalità provvisoria, rimuovere le voci dell'app dalle chiavi del Registro di sistema.
  • Eccezioni e rinuncia
    • I driver e i servizi che devono essere avviati in modalità provvisoria richiedono la certificazione di una rinuncia. La richiesta di rinuncia deve includere ogni driver e servizio da aggiungere alle chiavi del Registro di sistema Cassaforte Boot e descrivere i motivi tecnici per cui il driver o il servizio deve essere eseguito in modalità provvisoria. Il programma di installazione dell'app deve registrare tutti questi driver e servizi in queste chiavi del Registro di sistema:
      • HKLM/System/CurrentControlSet/Control/Cassaforte Boot/Minimal
      • HKLM/System/CurrentControlSet/Control/Cassaforte Boot/Network
  • Nota: è necessario testare i driver e i servizi da avviare in modalità provvisoria per assicurarsi che funzionino in modalità provvisoria senza errori.

Test di sessione multiutente

Testare il comportamento dell'app durante l'esecuzione in più sessioni contemporaneamente.

  • Priorità bassa
    • Gli utenti di Windows devono essere in grado di eseguire sessioni simultanee. Le app devono assicurarsi che quando vengono eseguite in più sessioni, in locale o in remoto, la normale funzionalità dell'app non influisce negativamente. Le impostazioni dell'app e i file di dati devono essere specifici dell'utente e la privacy e le preferenze dell'utente devono essere limitate alla sessione dell'utente.
  • Dettagli test
    • Esegue più istanze simultanee dell'app per testare quanto segue:
      • Più istanze di un'app in esecuzione contemporaneamente sono isolate l'una dall'altra.
    • Ciò significa che i dati utente di un'istanza non sono visibili a un'altra istanza. Il suono in una sessione utente inattiva non deve essere sentito in una sessione utente attiva. Nei casi in cui più istanze dell'app usano risorse condivise, l'app deve assicurarsi che non si verifichi un conflitto.
      • Se l'app è stata installata per più utenti, archivia i dati nelle cartelle corrette e nei percorsi del Registro di sistema.
      • L'app può essere eseguita in più sessioni utente (cambio rapido utente) sia per l'accesso locale che per l'accesso remoto.
    • Per garantire questo problema, l'app deve controllare altre sessioni del servizio terminale (TS) per le istanze esistenti dell'app. Se l'app non supporta più sessioni utente o accesso remoto, deve indicare chiaramente questo valore all'utente quando viene avviato da una sessione di questo tipo.
  • Azione correttiva
    • Assicurarsi che l'app non archivii file di dati o impostazioni a livello di sistema in archivi dati specifici dell'utente, ad esempio Profilo utente o HKCU. In tal caso, tali informazioni non saranno disponibili per altri utenti.
    • L'app deve installare file di dati e di configurazione a livello di sistema durante l'installazione e creare i file e le impostazioni specifici dell'utente dopo l'installazione quando un utente lo esegue.
    • Assicurarsi che l'app non blocchi più sessioni simultanee, in locale o in remoto. L'app non deve dipendere da mutex globali o da altri oggetti denominati per verificare o bloccare più sessioni simultanee.
    • Se l'app non può consentire più sessioni simultanee per utente, usare gli spazi dei nomi per utente o per sessione per mutex e altri oggetti denominati.

Arresti anomali e blocchi di test

Monitoraggio dell'app durante il test per la certificazione per registrare eventuali arresti anomali o blocchi.

  • Priorità bassa
    • Gli errori delle app, ad esempio arresti anomali e blocchi, rappresentano un'interruzione importante per gli utenti e causano frustrazioni. L'eliminazione di tali errori migliora la stabilità e l'affidabilità delle app e, in generale, offre agli utenti un'esperienza app migliore. Le app che smettono di rispondere o si arrestano in modo anomalo possono provocare perdite di dati e non offrono un'esperienza utente ottimale.
  • Dettagli test
    • Testiamo l'app per verificarne la resilienza e la stabilità per l'intera durata del test di certificazione.
    • Il Kit di certificazione app Windows chiama IApplicationActivationManager::ActivateApplication per avviare le app di Windows Store. Per avviare un’app mediante ActivateApplication, è necessario che Controllo dell’account utente sia abilitato e che la risoluzione dello schermo sia almeno 1024 x 768 o 768 x 1024. In assenza di queste due condizioni, l'app non supererà questo test.
  • Azioni correttive
    • Assicurati che Controllo account utente sia attivato nel computer di prova.
    • Assicurati che il test venga eseguito su un computer con uno schermo sufficientemente ampio.
    • Se la tua app non si avvia e la tua piattaforma di prova soddisfa i requisiti preliminari per ActivateApplication, puoi indagare sul problema esaminando il registro eventi di attivazione. Per trovare queste voci nel registro eventi:
      1. Aprire eventvwr.exe e passare al nodo \Windows Logs\Application.
      2. Filtra la visualizzazione in modo da mostrare gli ID degli eventi: 5900-6000.
      3. Esamina le voci del registro con l'obiettivo di trovare una spiegazione al fatto che l'app non si è avviata.
    • Cerca il file che ha causato il problema, identifica l'errore e correggilo. Ricompila ed esegui un nuovo test dell'app.
  • Risorse aggiuntive

Test di compatibilità e resilienza

  • Priorità bassa
    • Questo controllo convaliderà due aspetti di un'app, i file eseguibili principali dell'app, ad esempio il punto di ingresso dell'app rivolto all'utente, devono essere manifestati per la compatibilità, oltre a dichiarare il GUID corretto. Per supportare questo nuovo test, il report avrà un sottonodo in "Compatibilità e resilienza". L'app avrà esito negativo se manca una o entrambe queste condizioni.
  • Dettagli test
    • Compatibilità: le app devono essere completamente funzionanti senza usare le modalità di compatibilità di Windows, i messaggi AppHelp o altre correzioni di compatibilità. Un manifesto di compatibilità consente a Windows di fornire all'app il comportamento di compatibilità appropriato nelle diverse versioni del sistema operativo
    • AppInit: le app non devono elencare le DLL da caricare nella chiave del Registro di sistema HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Nt\CurrentVersion\Windows\AppInit_DLLs.
    • Switchback: l'applicazione deve fornire il manifesto di switchback. Se il manifesto non è presente, il Kit di certificazione app Windows visualizza un messaggio di avviso. Il Kit di certificazione app Windows verificherà anche che il manifesto contenga un GUID del sistema operativo valido.
  • Azioni correttive
    • Correggere il componente dell'app che usa la correzione di compatibilità.
    • Assicurarsi che l'app non si basi sulle correzioni di compatibilità per la relativa funzionalità.
    • Verificare che l'app sia manifestata e che la sezione relativa alla compatibilità includa i valori appropriati
  • Informazioni aggiuntive
    • Per altre informazioni, vedi DLL AppInit.

Sicurezza di Windows test delle procedure consigliate

  • Priorità bassa
    • Un'app non deve modificare le impostazioni di sicurezza predefinite di Windows
  • Dettagli test
    • Testa la sicurezza dell'app eseguendo Attack Surface Analyzer. L'approccio consiste nell'aggiungere categorie di errori per ogni test. Ad esempio, alcune categorie per i test di sicurezza possono includere:
      • Errore di inizializzazione
      • Errore dell'architettura di sicurezza
      • Possibile errore di overflow del buffer
      • Errore di arresto anomalo
    • Per informazioni dettagliate, vedere qui.
  • Azioni correttive
    • Risolvere e risolvere il problema identificato dai test. Ricompila ed esegui un nuovo test dell'app.

Test delle funzionalità di sicurezza di Windows

  • Priorità bassa
    • Le applicazioni devono acconsentire esplicitamente alle funzionalità di sicurezza di Windows. La modifica delle protezioni di sicurezza di Windows predefinite può comportare maggiori rischi per gli utenti.
  • Dettagli test
    • Testa la sicurezza dell’app tramite l’esecuzione dello strumento BinScope Binary Analyzer. Per informazioni dettagliate, vedere qui.
  • Azioni correttive
    • Risolvere e risolvere il problema identificato dai test. Ricompila ed esegui un nuovo test dell'app.

Test DPI elevato

È consigliabile che le app Win32 siano consapevoli di dpi. È la chiave per rendere coerente l'interfaccia utente dell'app in un'ampia gamma di impostazioni di visualizzazione con valori DPI elevati. Un'app non compatibile con DPI in esecuzione su un'impostazione di visualizzazione con valori DPI elevati può avere problemi, ad esempio il ridimensionamento errato degli elementi dell'interfaccia utente, il testo ritagliato e le immagini sfocate. Esistono due modi per dichiarare che un'app è compatibile con dpi. Uno consiste nel dichiarare dpi.

  • Priorità bassa
    • Questo controllo convaliderà due aspetti di un'app, ovvero i file eseguibili principali, ad esempio i punti di ingresso dell'app rivolti agli utenti devono essere manifestati per la consapevolezza high-DPI e che le API appropriate vengono chiamate per supportare valori DPI ELEVATI. L'app avrà esito negativo se manca una o entrambe queste condizioni. Questo controllo introduce una nuova sezione nel report desktop, vedere l'esempio seguente.
  • Dettagli test
    • Il test genererà un avviso quando viene rilevato uno dei seguenti elementi:
      • Il file EXE principale non dichiara la consapevolezza DPI nel manifesto e non chiama l'API SetProcessDPIAware. Avvisare lo sviluppatore se dimentica di aggiungere il manifesto di consapevolezza DPI.
      • Il file EXE principale non dichiara la consapevolezza DPI nel manifesto, ma chiama l'API SetProcessDPIAware (avvisare lo sviluppatore che deve usare il manifesto per dichiarare la consapevolezza DPI anziché chiamare l'API).
      • MainEXE dichiara la consapevolezza DPI nel manifesto, ma chiama anche l'API SetProcessDPIAware (avvisa lo sviluppatore che chiama tale API non è necessaria).
      • Per i file binari che non sono exes principali, se chiamano l'API, dare un avviso (la chiamata all'API non è consigliata).
  • Azioni correttive
    • L'uso della funzione SetProcessDPIAware() è sconsigliato. Se una DLL memorizza nella cache le impostazioni DPI durante l'inizializzazione, richiamare SetProcessDPIAware() nell'app può generare una race condition. Chiamare la funzione SetProcessDPIAware() in una DLL non è una procedura consigliata.
  • Informazioni aggiuntive