Tests im Zertifizierungskit für Windows-Apps

Im Folgenden finden Sie Testdetails für die Zertifizierung von Desktop-Apps. Weitere Informationen finden Sie unter Verwenden des Zertifizierungskits für Windows-Apps.

• Bereinigen der umkehrbaren Installation
• Installieren im richtigen Ordnertest
• Digital signierter Dateitest
• Unterstützung von x64 Windows-Tests
• Test zur Überprüfung der Betriebssystemversion
• Test der Benutzerkontensteuerung (UAC)
• Befolgen von Systemneustart-Manager-Meldungen
• Test im abgesicherten Modus
• Mehrbenutzersitzungstest
• Test stürzt ab und hängt ab
• Kompatibilitäts- und Resilienztest
• Windows-Sicherheit Best Practices–Test
• Test der Windows-Sicherheitsfeatures
• Test mit hoher DPI-Auflösung

Bereinigen der umkehrbaren Installation

Installiert und deinstalliert die App und sucht auf reste Dateien und Registrierungseinträge.

• Hintergrund
  • Eine sauber, umkehrbare Installation ermöglicht Es Benutzern, Apps bereitzustellen und zu entfernen. Um diesen Test zu bestehen, muss die App folgendes ausführen:
    • Die App erzwingt nicht, dass das System unmittelbar nach der Installation oder Deinstallation der App neu gestartet wird. Der Installations- oder Deinstallationsprozess einer App sollte niemals direkt nach Abschluss eines Systemneustarts erforderlich sein. Wenn das System neu gestartet werden muss, sollten Benutzer das System nach Belieben neu starten können.
    • Die App ist nicht von 8.3 Short File Names (SFN) abhängig. Die Installations- und Deinstallationsprozesse der App müssen lange Dateinamen und Ordnerpfade verwenden können.
    • Die App blockiert die automatische Installation/Deinstallation nicht.
    • Die App nimmt die erforderlichen Einträge in der Systemregistrierung vor. Windows-Inventurtools und Telemetrietools erfordern vollständige Informationen zu installierten Apps. App-Installationsprogramme müssen die richtigen Registrierungseinträge erstellen, um eine erfolgreiche Erkennung und Deinstallation zu ermöglichen.
  • Wenn Sie ein MSI-basiertes Installationsprogramm verwenden, erstellt MSI automatisch die folgenden Registrierungseinträge. Wenn Sie kein MSI-Installationsprogramm verwenden, muss das Installationsmodul während der Installation die folgenden Registrierungseinträge erstellen:
    • DisplayName
    • InstallLocation
    • Publisher
    • UninstallString
    • VersionMajor oder MajorVersion
    • VersionMinor oder MinorVersion
  • Die App muss alle Einträge in "Programme hinzufügen/entfernen" entfernen.
• Testdetails
  • Dieser Test überprüft die Installations- und Deinstallationsprozesse der App auf das erforderliche Verhalten.
• Korrekturmaßnahme
  • Überprüfen Sie den Entwurf und das Verhalten der App anhand der oben beschriebenen Anforderungen.

Installieren im richtigen Ordnertest

Überprüft, ob die App ihre Programm- und Datendateien in die richtigen Ordner schreibt.

• Hintergrund
  • Apps müssen systeminterne und benutzerspezifische Ordner ordnungsgemäß verwenden, damit sie auf die benötigten Daten und Einstellungen zugreifen können und gleichzeitig die Daten und Einstellungen des Benutzers vor nicht autorisiertem Zugriff schützen.
• Ordner "Programmdateien"
  • Die App muss standardmäßig im Ordner "Programme" installiert werden (%ProgramFiles% für native 32-Bit- und 64-Bit-Apps und %ProgramFiles(x86)% für 32-Bit-Apps, die unter x64 ausgeführt werden.
  • Hinweis: Die App darf aufgrund der für diesen Ordner konfigurierten Sicherheitsberechtigungen keine Benutzerdaten oder App-Daten in einem Ordner "Programme" speichern.
  • Die ACLs in Windows-Systemordnern ermöglichen nur Administratorkonten das Lesen und Schreiben. Daher haben Standardbenutzerkonten keinen Zugriff auf diese Ordner. Bei der Dateivirtualisierung können Apps jedoch eine Datei, z. B. eine Konfigurationsdatei, an einem Systemspeicherort speichern, der normalerweise nur von Administratoren geschrieben werden kann. Das Ausführen von Programmen als Standardbenutzer in dieser Situation kann zu einem Fehler führen, wenn sie nicht auf eine erforderliche Datei zugreifen können.
  • Apps sollten bekannte Ordner verwenden, um sicherzustellen, dass sie auf ihre Daten zugreifen können.
  • Hinweis: Windows bietet Dateivirtualisierung, um die App-Kompatibilität zu verbessern und Probleme zu beseitigen, wenn Apps als Standardbenutzer unter Windows ausgeführt werden. Ihre App sollte sich nicht darauf verlassen, dass die Virtualisierung in zukünftigen Versionen von Windows vorhanden ist.
• Benutzerspezifische App-Datenordner
  • Bei Computerinstallationen darf die App während der Installation keine benutzerspezifischen Daten schreiben. Benutzerspezifische Installationsdaten sollten nur geschrieben werden, wenn ein Benutzer die App zum ersten Mal startet. Dies liegt daran, dass es zum Zeitpunkt der Installation keinen richtigen Benutzerspeicherort gibt, an dem Daten gespeichert werden sollen. Versuche einer App, das Standardzuordnungsverhalten auf Computerebene nach der Installation zu ändern, sind nicht erfolgreich. Stattdessen müssen Standardwerte auf benutzerspezifischer Ebene beansprucht werden, wodurch verhindert wird, dass mehrere Benutzer die Standardwerte des anderen überschreiben.
  • Alle App-Daten, die nur für einen bestimmten Benutzer gelten und nicht für andere Benutzer des Computers freigegeben werden sollen, müssen unter Benutzer\<Benutzername>\AppData gespeichert werden.
  • Alle App-Daten, die für Benutzer auf dem Computer freigegeben werden müssen, sollten in ProgramData gespeichert werden.
• Andere Systemordner und Registrierungsschlüssel
  • Die App sollte niemals direkt in das Windows-Verzeichnis und in die Unterverzeichnisse schreiben. Verwenden Sie die richtigen Methoden zum Installieren von Dateien, z. B. Schriftarten oder Treibern, in diesen Verzeichnissen.
  • Apps sollten beim Start nicht automatisch gestartet werden, z. B. durch Hinzufügen eines Eintrags an einem oder mehreren dieser Speicherorte:
    • Registrierungsausführungsschlüssel HKLM und oder HKCU unter Software\Microsoft\Windows\CurrentVersion
    • Registrierungsausführungsschlüssel HKLM und oder HKCU unter Software\Wow6432Node\Microsoft\windows\CurrentVersion
    • Startmenü AlleProgramme > STARTUP
• Testdetails
  • Dieser Test überprüft, ob die App die spezifischen Speicherorte im Dateisystem verwendet, die Windows bereitstellt, um Programme und Softwarekomponenten, freigegebene App-Daten und Benutzerspezifische App-Daten zu speichern.
• Maßnahmen
  • Überprüfen Sie, wie die App die Ordner des Systems verwendet, und stellen Sie sicher, dass sie ordnungsgemäß verwendet werden.
• Ausnahmen und Verzichtserklärungen
  • Für Desktop-Apps, die in den globalen Assemblycache (GAC) schreiben, ist eine Verzichtserklärung erforderlich (.NET-Apps sollten Assemblyabhängigkeiten privat halten und im Verzeichnis der App speichern, es sei denn, die Freigabe einer Assembly ist explizit erforderlich).
  • Die Installation im Ordner "Programme" ist für Desktop-SW-Pakete nicht erforderlich, um das SW-Logo zu erreichen, nur unter der Kategorie SW-Grundlagen.

Digital signierter Dateitest

Testet ausführbare Dateien und Gerätetreiber, um zu überprüfen, ob sie über eine gültige digitale Signatur verfügen.

• Hintergrund
  • Digital signierte Dateien ermöglichen es, zu überprüfen, ob die Datei original ist, und zu erkennen, ob die Datei manipuliert wurde.
  • Die Erzwingung von Codesignaturen im Kernelmodus ist ein Windows-Feature, das auch als Codeintegrität (CI) bezeichnet wird. CI verbessert die Sicherheit von Windows, indem die Integrität einer Datei bei jedem Laden in den Arbeitsspeicher überprüft wird. CI erkennt, ob böswilliger Code eine Binärdatei des Systems geändert hat, und generiert ein Diagnose- und Systemüberwachungsprotokollereignis, wenn die Signatur eines Kernelmoduls nicht ordnungsgemäß überprüft werden kann.
  • Wenn die App erhöhte Berechtigungen erfordert, zeigt die Eingabeaufforderung zur Erhöhung kontextbezogene Informationen zu der ausführbaren Datei an, die erhöhte Zugriffsberechtigungen anfordert. Je nachdem, ob die App authenticode signiert ist, wird dem Benutzer möglicherweise die Zustimmungsaufforderung oder die Anmeldeinformationsaufforderung angezeigt.
  • Starke Namen verhindern, dass Dritte Ihren Code spoofen, solange Sie den privaten Schlüssel sicher halten. Die .NET Framework überprüft die digitale Signatur entweder, wenn die Assembly geladen oder im GAC installiert wird. Ohne Zugriff auf den privaten Schlüssel kann ein böswilliger Benutzer Ihren Code nicht ändern und erneut signieren.
• Testdetails
  • Alle ausführbaren Dateien, z. B. dateien mit den Dateierweiterungen .exe, .dll, OCX, .sys, .cpl, .drv und .scr, müssen mit einem Authenticode-Zertifikat signiert werden.
  • Alle von der App installierten Kernelmodustreiber müssen über eine Microsoft-Signatur verfügen, die über das WHQL- oder DRS-Programm abgerufen wird. Alle Dateisystemfiltertreiber müssen WHQL-signiert sein.
• Korrekturmaßnahme
  • Signieren Sie die ausführbaren Dateien der App.
  • Verwenden Sie makecert.exe, um ein Zertifikat zu generieren oder einen Codesignaturschlüssel von einer der kommerziellen Zertifizierungsstellen (CAs) wie VeriSign, Thawte oder einer Microsoft-Zertifizierungsstelle zu erhalten.
• Ausnahmen und Verzichtserklärungen
  • Verzichtserklärungen werden nur für nicht signierte Verteiler von Drittanbietern in Betracht gezogen. Ein Kommunikationsnachweis, der eine signierte Version der Verteiler anfordert, ist erforderlich, damit dieser Verzicht gewährt wird.
  • Softwarepakete mit Mehrwert für Geräte sind von der Kernelmodustreiberzertifizierung ausgenommen, da Treiber durch die Windows-Hardwarezertifizierung zertifiziert werden müssen.

Unterstützung von x64 Windows-Tests

Testen Sie die App, um sicherzustellen, dass die .exe für die Plattformarchitektur erstellt wurde, auf der sie installiert wird.

• Hintergrund
  • Die ausführbare Datei muss für die Prozessorarchitektur erstellt werden, auf der sie installiert ist. Einige ausführbare Dateien können auf einer anderen Prozessorarchitektur ausgeführt werden, aber dies ist nicht zuverlässig.
  • Architekturkompatibilität ist wichtig, da 32-Bit-Prozesse keine 64-Bit-DLLs und 64-Bit-Prozesse keine 32-Bit-DLLs laden können. Ebenso unterstützen 64-Bit-Versionen von Windows die Ausführung von 16-Bit-Windows-basierten Anwendungen nicht, da Handles 32 wichtige Bits unter 64-Bit-Windows und aufweisen, sodass sie nicht an 16-Bit-Anwendungen übergeben werden können. Daher schlägt der Versuch, eine 16-Bit-Anwendung zu starten, unter 64-Bit-Versionen von Windows fehl.
  • 32-Bit-Gerätetreiber können nicht unter 64-Bit-Versionen von Windows ausgeführt werden und müssen daher auf die 64-Bit-Architektur portiert werden.
  • Für Benutzermodusanwendungen umfasst 64-Bit-Windows WOW64, mit dem 32-Bit-Windows-Anwendungen auf Systemen mit 64-Bit-Windows ausgeführt werden können, wenn auch mit einem gewissen Leistungsverlust. Für Gerätetreiber ist keine gleichwertige Übersetzungsebene vorhanden.
  • Um die Kompatibilität mit 64-Bit-Versionen von Windows aufrechtzuerhalten, müssen Apps nativ 64-Bit unterstützen, oder mindestens 32-Bit-Windows-basierte Apps müssen nahtlos auf 64-Bit-Systemen ausgeführt werden:
    • Apps und ihre Installationsprogramme dürfen keinen 16-Bit-Code enthalten oder sich auf eine 16-Bit-Komponente verlassen.
    • Das App-Setup muss die richtigen Treiber und Komponenten unter 64-Bit-Versionen von Windows erkennen und installieren.
    • Shell-Plug-Ins müssen unter 64-Bit-Versionen von Windows ausgeführt werden.
    • Apps, die unter dem WoW64-Emulator ausgeführt werden, sollten nicht versuchen, Wow64-Virtualisierungsmechanismen zu umgehen. Wenn es bestimmte Szenarien gibt, in denen Apps erkennen müssen, ob sie in einem WoW64-Emulator ausgeführt werden, sollten sie dazu IsWow64Process aufrufen.
• Testdetails
  • Die App sollte keine 16-Bit-Binärdateien installieren. Die App sollte keinen 32-Bit-Kernelmodustreiber installieren, wenn sie auf einem 64-Bit-Computer ausgeführt werden soll.
• Korrekturmaßnahmen
  • Erstellen Sie die ausführbaren Dateien und Treiber für die Prozessorarchitektur, für die Sie sie installieren möchten.

Test zur Überprüfung der Betriebssystemversion

Testet, wie die App nach der Version von Windows sucht, unter der sie ausgeführt wird.

• Hintergrund
  • Apps überprüfen die Betriebssystemversion, indem sie auf eine Version testen, die größer oder gleich der erforderlichen Version ist, um die Kompatibilität mit zukünftigen Versionen von Windows sicherzustellen.
• Testdetails
  • Simuliert die Ausführung der App unter verschiedenen Versionen von Windows, um zu sehen, wie sie reagiert.
• Maßnahmen
  • Testen Sie die richtige Version von Windows, indem Sie testen, ob die aktuelle Version größer oder gleich der Version ist, die Ihre App, Ihr Dienst oder Ihr Treiber benötigt.
  • Treiberinstallations- und Deinstallationsmodule dürfen niemals die Betriebssystemversion überprüfen.
• Ausnahmen und Verzichtserklärungen
  • Verzichtserklärungen werden für Apps berücksichtigt, die die folgenden Kriterien erfüllen: (Gilt nur für die Zertifizierung von Desktop-Apps)
    • Apps, die als ein Paket bereitgestellt werden, das unter Windows XP, Windows Vista und Windows 7 ausgeführt wird und die die Betriebssystemversion überprüfen müssen, um zu ermitteln, welche Komponenten auf einem bestimmten Betriebssystem installiert werden sollen.
    • Apps, die nur die Mindestversion des Betriebssystems (nur während der Installation, nicht zur Laufzeit) überprüfen, indem sie nur die genehmigten API-Aufrufe verwenden und die Mindestversionsanforderung im App-Manifest als erforderlich auflisten.
    • Sicherheits-Apps wie Antiviren- und Firewall-Apps, Systemhilfsprogramme wie Defragmentierungsprogramme und Sicherungs-Apps sowie Diagnose Tools, die die Betriebssystemversion nur mithilfe der genehmigten API-Aufrufe überprüfen.

Test der Benutzerkontensteuerung (UAC)

Testet die App, um zu überprüfen, ob sie für die Ausführung nicht unnötig erhöhte Berechtigungen benötigt.

• Hintergrund
  • Eine App, die nur dann ausgeführt oder installiert wird, wenn der Benutzer ein Administrator ist, zwingt Benutzer, die App mit unnötig erhöhten Berechtigungen auszuführen, wodurch Schadsoftware in den Computer des Benutzers gelangen kann.
  • Wenn Benutzer immer gezwungen sind, Apps mit erhöhten Zugriffstoken auszuführen, kann die App als Einstiegspunkt für betrügerischen oder böswilligen Code servern. Diese Schadsoftware kann das Betriebssystem leicht ändern oder schlimmer noch, andere Benutzer beeinflussen. Es ist nahezu unmöglich, einen Benutzer zu steuern, der über vollzugriff auf Administratoren verfügt, da Administratoren Apps installieren und alle Apps oder Skripts auf dem Computer ausführen können. IT-Manager suchen immer nach Möglichkeiten, "Standarddesktops" zu erstellen, auf denen sich Benutzer als Standardbenutzer anmelden. Standarddesktops reduzieren die Helpdeskkosten erheblich und reduzieren den IT-Mehraufwand.
  • Die meisten Anwendungen erfordern zur Laufzeit keine Administratorrechte. Ein Standardbenutzerkonto sollte in der Lage sein, sie auszuführen. Windows-Apps müssen über ein Manifest (eingebettet oder extern) verfügen, um die Ausführungsebene zu definieren, die dem Betriebssystem die Berechtigungen mitteilt, die zum Ausführen der App erforderlich sind. Das App-Manifest gilt nur für .exe Dateien, nicht für .dll Dateien. Die Benutzerkontensteuerung (User Account Control, UAC) überprüft während der Erstellung des Prozesses keine DLLs. UAC-Regeln gelten nicht für Microsoft-Dienste. Das App-Manifest kann eingebettet oder extern sein.
  • Um ein Manifest zu erstellen, erstellen Sie eine Datei mit dem Namen <app_name>.exe.manifest, und speichern Sie sie im selben Verzeichnis wie die EXE. Beachten Sie, dass jedes externe Manifest ignoriert wird, wenn die App über ein internes Manifest verfügt.
    • Beispiel <: requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true|false"""/>
    • Der Standard Prozess der App muss als Standardbenutzer (asInvoker) ausgeführt werden. Alle administrativen Features müssen in einen separaten Prozess verschoben werden, der mit Administratorrechten ausgeführt wird.
    • Benutzerseitige Apps, die erhöhte Berechtigungen erfordern, müssen Authenticode signiert sein.
• Testdetails
  • Alle benutzerseitigen Exes sollten mit dem AsInvoker-Attribut gekennzeichnet werden. Wenn sie als "highestAvailable" oder "requireAdministrator" gekennzeichnet sind, sollten sie ordnungsgemäß authentifiziert sein. Für jede App-Exe sollte das uiAccess-Attribut nicht auf true festgelegt sein. Jede exe, die als Dienst ausgeführt wird, ist von dieser speziellen Überprüfung ausgeschlossen.
• Maßnahmen
  • Überprüfen Sie die Manifestdatei der App auf die richtigen Einträge und Berechtigungsstufen.
• Ausnahmen und Verzichtserklärungen
  • Für Apps, die ihren Standard Prozess mit erhöhten Rechten ausführen (requireAdministrator oder highestAvailable), ist ein Verzicht erforderlich. Der Standard Prozess ist der Prozess, der den Einstiegspunkt des Benutzers in die App bereitstellt.
  • Verzichtserklärungen werden für die folgenden Szenarien berücksichtigt:
    • Verwaltungs- oder Systemtools, deren Ausführungsebene auf "highestAvailable", "requireAdministrator" oder beides festgelegt ist.
    • Nur die Framework-App für Barrierefreiheit oder Benutzeroberflächenautomatisierung legt das uiAccess-Flag auf TRUE fest, um die Benutzeroberflächenberechtigungsisolation (UIPI) zu umgehen. Um die App-Auslastung ordnungsgemäß zu starten, muss dieses Flag Authenticode signiert sein und sich an einem geschützten Speicherort im Dateisystem befinden, z. B. Programme.

Befolgen von Systemneustart-Manager-Meldungen

Testet, wie die App auf Meldungen zum Herunterfahren und Neustarten des Systems reagiert.

• Hintergrund
  • Apps müssen so schnell wie möglich beendet werden, wenn sie benachrichtigt werden, dass das System heruntergefahren wird, um dem Benutzer ein reaktionsfähiges Herunterfahren oder Ausschalten zu ermöglichen.
  • Beim kritischen Herunterfahren werden Apps, die FALSE an WM_QUERYENDSESSION zurückgeben, WM_ENDSESSION gesendet und geschlossen, während apps, die als Reaktion auf WM_QUERYENDSESSION ein Timeout ausführen, erzwungen beendet werden.
• Testdetails
  • Untersucht, wie die App auf Das Herunterfahren und Beenden von Nachrichten reagiert.
• Maßnahmen
  • Wenn Ihre App bei diesem Test fehlschlägt, überprüfen Sie, wie diese Windows-Meldungen behandelt werden:
    • WM_QUERYENDSESSION mit LPARAM = ENDSESSION_CLOSEAPP(0x1): Desktop-Apps müssen sofort reagieren (TRUE), um einen Neustart vorzubereiten. Konsolen-Apps können SetConsoleCtrlHandler aufrufen, um eine Benachrichtigung zum Herunterfahren zu erhalten. Dienste können RegisterServiceCtrlHandlerEx aufrufen, um Benachrichtigungen zum Herunterfahren in einer Handlerroutine zu empfangen.
    • WM_ENDSESSION mit LPARAM = ENDSESSION_CLOSEAPP(0x1): Apps müssen innerhalb von 30 Sekunden einen Wert von 0 zurückgeben und heruntergefahren werden. Apps sollten sich mindestens vorbereiten, indem sie Benutzerdaten speichern und die informationen angeben, die nach einem Neustart benötigt werden.
  • Konsolen-Apps, die die CTRL_C_EVENT Benachrichtigung erhalten, sollten sofort heruntergefahren werden. Treiber dürfen kein Veto gegen ein Ereignis zum Herunterfahren des Systems einzulegen.
  • Hinweis: Apps, die das Herunterfahren aufgrund eines Vorgangs blockieren müssen, der nicht unterbrochen werden kann, sollten ShutdownBlockReasonCreate verwenden, um eine Zeichenfolge zu registrieren, die dem Benutzer den Grund erläutert. Wenn der Vorgang abgeschlossen ist, sollte die App ShutdownBlockReasonDestroy aufrufen, um anzugeben, dass das System heruntergefahren werden kann.

Test im abgesicherten Modus

Testet, ob der Treiber oder Dienst für den Start im abgesicherten Modus konfiguriert ist.

• Hintergrund
  • Im abgesicherten Modus können Benutzer Probleme mit Windows diagnostizieren und beheben. Nur Treiber und Dienste, die für den grundlegenden Betrieb des Betriebssystems erforderlich sind oder Diagnose- und Wiederherstellungsdienste bereitstellen, sollten im abgesicherten Modus geladen werden. Das Laden anderer Dateien im abgesicherten Modus erschwert die Problembehandlung von Problemen mit dem Betriebssystem.
  • Standardmäßig werden nur die Treiber und Dienste, die mit Windows vorinstalliert sind, im abgesicherten Modus gestartet. Alle anderen Treiber und Dienste sollten deaktiviert werden, es sei denn, das System benötigt sie für grundlegende Vorgänge oder für Diagnose- und Wiederherstellungszwecke.
• Testdetails
  • Treiber, die von der App installiert werden, sollten nicht für das Laden im abgesicherten Modus markiert werden.
• Maßnahmen
  • Wenn der Treiber oder Dienst nicht im abgesicherten Modus gestartet werden soll, entfernen Sie die Einträge der App aus den Registrierungsschlüsseln.
• Ausnahmen und Verzichtserklärungen
  • Treiber und Dienste, die im abgesicherten Modus gestartet werden müssen, erfordern eine Ausnahmegenehmigung, um zertifiziert zu werden. Die Verzichtsanforderung muss alle Treiber und Dienste enthalten, die den SafeBoot-Registrierungsschlüsseln hinzugefügt werden sollen, und die technischen Gründe dafür beschreiben, warum der Treiber oder Dienst im abgesicherten Modus ausgeführt werden muss. Das App-Installationsprogramm muss alle diese Treiber und Dienste in den folgenden Registrierungsschlüsseln registrieren:
    • HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal
    • HKLM/System/CurrentControlSet/Control/SafeBoot/Network
• Hinweis: Sie müssen die Treiber und Dienste testen, die Sie im abgesicherten Modus starten möchten, um sicherzustellen, dass sie fehlerfrei im abgesicherten Modus funktionieren.

Sitzungstest mit mehreren Benutzern

Testen Sie, wie sich die App verhält, wenn sie in mehreren Sitzungen gleichzeitig ausgeführt wird.

• Hintergrund
  • Windows-Benutzer müssen in der Lage sein, gleichzeitige Sitzungen auszuführen. Apps müssen sicherstellen, dass die normale Funktionalität der App nicht beeinträchtigt wird, wenn sie in mehreren Sitzungen ausgeführt werden, entweder lokal oder remote. App-Einstellungen und Datendateien müssen benutzerspezifisch sein, und der Datenschutz und die Einstellungen des Benutzers müssen auf die Sitzung des Benutzers beschränkt sein.
• Testdetails
  • Führt mehrere gleichzeitige Instanzen der App aus, um Folgendes zu testen:
    • Mehrere Instanzen einer App, die gleichzeitig ausgeführt wird, sind voneinander isoliert.
  • Dies bedeutet, dass Benutzerdaten aus einem instance für einen anderen instance nicht sichtbar sind. Sound in einer inaktiven Benutzersitzung sollte in einer aktiven Benutzersitzung nicht gehört werden. In Fällen, in denen mehrere App-Instanzen freigegebene Ressourcen verwenden, muss die App sicherstellen, dass es keinen Konflikt gibt.
    • Wenn die App für mehrere Benutzer installiert wurde, speichert sie Daten in den richtigen Ordnern und Registrierungsspeicherorten.
    • Die App kann in mehreren Benutzersitzungen (Fast User Switching) sowohl für den lokalen Zugriff als auch für den Remotezugriff ausgeführt werden.
  • Um dies sicherzustellen, muss die App andere Terminaldienstsitzungen (Ts) auf vorhandene Instanzen der App überprüfen. Wenn die App mehrere Benutzersitzungen oder Remotezugriff nicht unterstützt, muss sie dies dem Benutzer klar sagen, wenn sie von einer solchen Sitzung gestartet wird.
• Korrekturmaßnahme
  • Stellen Sie sicher, dass die App keine systemweiten Datendateien oder -einstellungen in benutzerspezifischen Datenspeichern speichert, z. B. Benutzerprofil oder HKCU. Wenn dies der Fall ist, stehen diese Informationen für andere Benutzer nicht zur Verfügung.
  • Ihre App muss während der Installation systemweite Konfigurations- und Datendateien installieren und die benutzerspezifischen Dateien und Einstellungen nach der Installation erstellen, wenn ein Benutzer sie ausführt.
  • Stellen Sie sicher, dass die App nicht mehrere gleichzeitige Sitzungen blockiert, entweder lokal oder remote. Die App darf nicht von globalen Mutexes oder anderen benannten Objekten abhängig sein, um mehrere gleichzeitige Sitzungen zu überprüfen oder zu blockieren.
  • Wenn die App nicht mehrere gleichzeitige Sitzungen pro Benutzer zulassen kann, verwenden Sie Namespaces pro Benutzer oder pro Sitzung für Mutexes und andere benannte Objekte.

Test stürzt ab und hängt ab

Überwachen die App während des Zertifizierungstests, um aufzuzeichnen, wann sie abstürzt oder sich aufhängt.

• Hintergrund
  • App-Fehler wie Abstürze und Abbrüche sind eine große Störung für Benutzer und verursachen Frustration. Die Beseitigung solcher Fehler verbessert die Stabilität und Zuverlässigkeit der App und bietet benutzern insgesamt eine bessere App-Erfahrung. Apps, die nicht mehr reagieren oder abstürzen, können zu einem Datenverlust und zu einer Beeinträchtigung des Benutzererlebnisses führen.
• Testdetails
  • Die App wird beim Zertifizierungstest durchgehend auf Flexibilität und Stabilität geprüft.
  • Das Windows App Certification Kit ruft IApplicationActivationManager::ActivateApplication auf, um Windows Store-Apps zu starten. Damit eine App mit ActivateApplication gestartet werden kann, muss die Benutzerkontensteuerung (UAC) aktiviert sein und die Bildschirmauflösung mindestens 1024 x 768 oder 768 x 1024 betragen. Ist eine dieser Bedingungen nicht erfüllt, fällt die App bei diesem Test durch.
• Korrekturmaßnahmen
  • Stellen Sie sicher, dass die Benutzerkontensteuerung (UAC) auf dem Test-PC aktiviert ist.
  • Führen Sie den Test auf einem PC mit ausreichend großem Bildschirm aus.
  • Falls die App nicht gestartet werden kann, obwohl die Testplattform die Voraussetzungen für ActivateApplication erfüllt, können Sie das Problem mithilfe des Aktivierungsereignisprotokolls beheben. So finden Sie die Einträge im Ereignisprotokoll:
    1. Öffnen Sie eventvwr.exe, und navigieren Sie zum Knoten \Windows-Protokolle\Anwendung.
    2. Filtern Sie die Ansicht entsprechend, um folgende Ereigniskennungen anzuzeigen: 5900-6000.
    3. Prüfen Sie die Protokolleinträge, um zu ermitteln, weshalb die App nicht gestartet wurde.
  • Führen Sie für die Datei mit dem Problem eine Problembehandlung durch, um das Problem zu identifizieren und zu beheben. Erstellen Sie die App neu, und wiederholen Sie den Test.
• Zusätzliche Ressourcen
  • Verwenden von Application Verifier innerhalb Ihres Softwareentwicklungslebenszyklus
  • Application Verifier
  • Verwenden der Anwendungsüberprüfung
  • AppInit-DLLs
  • Minimieren der Startzeit (Windows Store-Apps mit C#/VB/C++ und XAML)

Kompatibilitäts- und Resilienztest

• Hintergrund
  • Bei dieser Überprüfung werden zwei Aspekte einer App überprüft: Die App Standard ausführbaren Dateien, z. B. muss der Einstiegspunkt für die Benutzer-App auf Kompatibilität manifestiert werden, und die richtige GUID deklariert werden. Um diesen neuen Test zu unterstützen, verfügt der Bericht über einen Unterknoten unter "Kompatibilitätsresilienz & ". Die App schlägt fehl, wenn eine oder beide dieser Bedingungen fehlen.
• Testdetails
  • Kompatibilität: Apps müssen voll funktionsfähig sein, ohne Windows-Kompatibilitätsmodi, AppHelp-Nachrichten oder andere Kompatibilitätskorrekturen zu verwenden. Ein Kompatibilitätsmanifest ermöglicht Es Windows, Ihrer App das richtige Kompatibilitätsverhalten unter den verschiedenen Versionen des Betriebssystems bereitzustellen.
  • AppInit: Apps dürfen keine DLLs auflisten, die im HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs Registrierungsschlüssel geladen werden sollen.
  • Switchback: Die Anwendung muss das Switchbackmanifest bereitstellen. Wenn das Manifest fehlt, gibt das Windows App Certification Kit eine Warnmeldung aus. Das Windows App Certification Kit überprüft auch, dass das Manifest eine gültige Betriebssystem-GUID enthält.
• Maßnahmen
  • Beheben Sie die App-Komponente, die den Kompatibilitätsfix verwendet.
  • Stellen Sie sicher, dass die App für ihre Funktionalität nicht auf Kompatibilitätsfixes angewiesen ist.
  • Stellen Sie sicher, dass Ihre App manifestiert ist und der Kompatibilitätsabschnitt die entsprechenden Werte enthält.
• Zusätzliche Informationen
  • Weitere Informationen finden Sie unter AppInit-DLLs .

Windows-Sicherheit Bewährte Methoden

• Hintergrund
  • Eine App sollte die Windows-Standardsicherheitseinstellungen nicht ändern.
• Testdetails
  • Testet die Sicherheit der App, indem Sie den Angriffs-Surface Analyzer ausführen. Der Ansatz besteht im Hinzufügen von Fehlerkategorien pro Testbasis. Einige Kategorien für Sicherheitstests können beispielsweise Folgendes umfassen:
    • Initialisierungsfehler
    • Fehler bei der Sicherheitsarchitektur
    • Möglicher Pufferüberlauffehler
    • Absturzfehler
  • Ausführliche Informationen finden Sie hier.
• Maßnahmen
  • Behandeln und Beheben des problems, das durch die Tests identifiziert wurde. Erstellen Sie die App neu, und wiederholen Sie den Test.

Test der Windows-Sicherheitsfeatures

• Hintergrund
  • Anwendungen müssen Windows-Sicherheitsfeatures aktivieren. Durch Ändern der standardmäßigen Windows-Sicherheitsvorkehrungen können Kunden einem erhöhten Risiko ausgesetzt werden.
• Testdetails
  • Testet die Sicherheit der App durch Ausführen des BinScope Binary Analyzers. Ausführliche Informationen finden Sie hier.
• Maßnahmen
  • Behandeln und Beheben des problems, das durch die Tests identifiziert wurde. Erstellen Sie die App neu, und wiederholen Sie den Test.

Hoher DPI-Test

Es wird dringend empfohlen, dass die Win32-Apps dpi-fähig sind. Dies ist der Schlüssel, um die App-Benutzeroberfläche in einer Vielzahl von Anzeigeeinstellungen mit hoher DPI-Auflösung konsistent gut aussehen zu lassen. Eine nicht DPI-fähige App, die auf einer Anzeigeeinstellung mit hohem DPI-Wert ausgeführt wird, kann Probleme haben, z. B. falsche Skalierung von UI-Elementen, abgeschnittenen Text und verschwommene Bilder. Es gibt zwei Möglichkeiten, zu deklarieren, dass eine App DPI-fähig ist. Eine besteht darin, DPI zu deklarieren.

• Hintergrund
  • Bei dieser Überprüfung werden zwei Aspekte einer App überprüft: die Standard ausführbaren Dateien, z. B. müssen App-Einstiegspunkte für benutzerseitige App-Werte für die Wahrnehmung von HIGH-DPI manifestiert werden und dass die richtigen APIs aufgerufen werden, um HIGH-DPI zu unterstützen. Die App schlägt fehl, wenn eine oder beide dieser Bedingungen fehlen. Mit dieser Überprüfung wird ein neuer Abschnitt im Desktopbericht eingeführt, siehe Beispiel unten.
• Testdetails
  • Test generiert eine Warnung, wenn eine der folgenden Punkte erkannt wird:
    • Die Standard EXE deklariert keine DPI-Wahrnehmung im Manifest und ruft die SetProcessDPIAware-API nicht auf. (Warnen Sie den Entwickler, wenn er vergisst, das DPI-Bewusstseinsmanifest hinzuzufügen).
    • Die Standard EXE deklariert keine DPI-Sensibilisierung im Manifest, ruft jedoch die SetProcessDPIAware-API auf (Warnen Sie den Entwickler, dass er das Manifest verwenden soll, um dpi-Bewusstsein zu deklarieren, anstatt die API aufzurufen).
    • Die mainEXE deklariert DPI-Bewusstsein in ihrem Manifest, ruft aber auch die SetProcessDPIAware-API auf (Warnen Sie den Entwickler, dass der Aufruf dieser API nicht erforderlich ist).
    • Geben Sie für die Binärdateien, die nicht Standard EXEs sind, eine Warnung aus, wenn sie die API aufrufen (Das Aufrufen der API wird nicht empfohlen).
• Maßnahmen
  • Von der Verwendung der SetProcessDPIAware()-Funktion wird abgeraten. Wenn eine DLL während der Initialisierung DPI-Einstellungen zwischenspeichert, kann durch aufrufen von SetProcessDPIAware() in der App eine Racebedingung generiert werden. Das Aufrufen der SetProcessDPIAware()-Funktion in einer DLL ist auch keine gute Methode.
• Zusätzliche Informationen
  • Schreiben von Apps mit hoher DPI-Auflösung