Freigeben über

Tests des Zertifizierungskits für Windows-Apps

  • Artikel

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

Bereinigen der umkehrbaren Installation

Installiert und deinstalliert die App und sucht nach Restdateien und Registrierungseinträgen.

  • Hintergrund
    • Mit einer sauberen, umkehrbaren Installation können Benutzer Apps bereitstellen und 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 einen Systemneustart nach Abschluss des Vorgangs erfordern. Wenn dies erfordert, dass das System neu gestartet wird, sollten Die Benutzer das System bequem neu starten können.
      • Die App ist nicht von 8.3 kurzen Dateinamen (SFN) abhängig. Die Installations- und Deinstallationsprozesse der App müssen lange Dateinamen und Ordnerpfade verwenden können.
      • Die App blockiert keine automatische Installation/Deinstallation
      • Die App nimmt die erforderlichen Einträge in der Systemregistrierung vor. Windows-Inventartools 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
      • Verlag
      • 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 das Design und Verhalten der App anhand der oben beschriebenen Anforderungen.

Installieren auf den richtigen Ordnertest

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

  • Hintergrund
    • Apps müssen Benutzersystem- und Benutzerordner ordnungsgemäß verwenden, damit sie auf die benötigten Daten und Einstellungen zugreifen kann, während sie die Daten und Einstellungen des Benutzers vor unbefugtem Zugriff schützt.
  • Ordner "Programme"
    • Die App muss standardmäßig im Ordner "Programme" installiert werden (%ProgramFiles% für systemeigene 32-Bit- und 64-Bit-Apps und %ProgramFiles(x86)% für 32-Bit-Apps, die auf 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 in diese Ordner. Daher haben Standardbenutzerkonten keinen Zugriff auf diese Ordner. Mit 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 bekannten 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 Installationen pro Computer 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 keinen richtigen Benutzerspeicherort gibt, an dem Daten zum Zeitpunkt der Installation gespeichert werden sollen. Versuche einer App, standardzuordnungsverhalten auf Computerebene zu ändern, nachdem die Installation nicht erfolgreich war. Stattdessen müssen Standardwerte auf benutzerspezifischer Ebene beansprucht werden, wodurch verhindert wird, dass mehrere Benutzer die Standardwerte gegenseitig überschreiben.
    • Alle App-Daten, die für einen bestimmten Benutzer exklusiv sind und nicht für andere Benutzer des Computers freigegeben werden sollen, müssen in "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 die Unterverzeichnisse schreiben. Verwenden Sie die richtigen Methoden zum Installieren von Dateien wie Schriftarten oder Treibern in diesen Verzeichnissen.
    • Apps sollten nicht automatisch beim Start gestartet werden, z. B. durch Hinzufügen eines Eintrags zu 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ü "AllPrograms" > START
  • Testdetails
    • Dieser Test überprüft, ob die App die spezifischen Speicherorte im Dateisystem verwendet, die Windows zum Speichern von Programmen und Softwarekomponenten, freigegebenen App-Daten und App-Daten bereitstellt, die für einen Benutzer spezifisch sind.
  • Korrekturmaß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
    • Eine Verzichtserklärung ist erforderlich, damit Desktop-Apps in den globalen Assemblycache (GAC) (.NET-Apps) schreiben, Assemblyabhängigkeiten privat lassen und sie im Verzeichnis der App speichern, es sei denn, die Freigabe einer Assembly ist explizit erforderlich).
    • Die Installation im Ordner "Programme"-Dateien ist keine Anforderung für Desktop-SW-Pakete, um SW Logo zu erreichen, nur unter der Kategorie "SW-Grundlagen".

Digital signierter Dateitest

Testet ausführbare Dateien und Gerätetreiber, um sicherzustellen, dass 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 um zu erkennen, ob die Datei manipuliert wurde.
    • Die Erzwingung von Kernelmodus-Codesignaturen 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ösartiger Code eine System-Binärdatei geändert hat, und generiert ein Diagnose- und Systemüberwachungsprotokollereignis, wenn die Signatur eines Kernelmoduls nicht ordnungsgemäß überprüft werden kann.
    • Wenn für die App erhöhte Berechtigungen erforderlich sind, zeigt die Eingabeaufforderung für die Rechteerweiterung kontextbezogene Informationen zur ausführbaren Datei an, die erhöhten Zugriff 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. .NET Framework überprüft die digitale Signatur entweder, wenn sie die Assembly lädt, oder installiert sie im GAC. 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 Dateierweiterungen von .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) zu erhalten, z. B. VeriSign, Thawte oder eine Microsoft-Zertifizierungsstelle.
  • Ausnahmen und Verzichtserklärungen
    • Verzichtserklärungen gelten nur für nicht signierte Weiterverteiler von Drittanbietern. Ein Nachweis der Kommunikation, die eine signierte Version der verteilbaren(n) Version anfordert, ist erforderlich, damit diese Verzichtserklärung erteilt wird.
    • Geräte-Softwarepakete mit Mehrwert sind von der Kernelmodustreiberzertifizierung ausgenommen, da Treiber durch die Windows-Hardwarezertifizierung zertifiziert werden müssen.

Unterstützen von x64 Windows-Test

Testen Sie die App, um sicherzustellen, dass der .exe für die Plattformarchitektur erstellt wird, 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, dies ist jedoch nicht zuverlässig.
    • Architekturkompatibilität ist wichtig, da 32-Bit-Prozesse 64-Bit-DLLs und 64-Bit-Prozesse keine 32-Bit-DLLs laden können. Ebenso unterstützt 64-Bit-Versionen von Windows die Ausführung von 16-Bit-Windows-basierten Anwendungen nicht, da Handles 32 signifikante Bits unter 64-Bit-Windows aufweisen, sodass sie nicht an 16-Bit-Anwendungen übergeben werden können. Daher schlägt der Versuch, eine 16-Bit-Anwendung zu starten, bei 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 zur 64-Bit-Architektur portiert werden.
    • Für Benutzermodusanwendungen umfasst 64-Bit-Windows WOW64, wodurch 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 entsprechende Übersetzungsebene vorhanden.
    • Um die Kompatibilität mit 64-Bit-Versionen von Windows aufrechtzuerhalten, müssen Apps 64-Bit oder mindestens 32-Bit-Windows-basierte Apps nahtlos auf 64-Bit-Systemen ausführen:
      • 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 in 64-Bit-Versionen von Windows erkennen und installieren.
      • Alle 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 dies tun, indem sie IsWow64Processaufrufen.
  • Testdetails
    • Die App sollte keine 16-Bit-Binärdateien installieren. Die App sollte keinen 32-Bit-Kernelmodustreiber installieren, wenn er 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 Windows-Version sucht, auf der sie ausgeführt wird.

  • Hintergrund
    • Apps überprüfen die Betriebssystemversion, indem Sie 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 in verschiedenen Versionen von Windows, um zu sehen, wie sie reagiert.
  • Korrekturmaß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 Treiber benötigt.
    • Treiberinstallationsprogramme und Deinstallationsmodule dürfen niemals die Betriebssystemversion überprüfen.
  • Ausnahmen und Verzichtserklärungen
    • Verzichtserklärungen gelten für Apps, die die folgenden Kriterien erfüllen: (gilt nur für die Desktop-App-Zertifizierung)
      • Apps, die als ein Paket bereitgestellt werden, das unter Windows XP, Windows Vista und Windows 7 ausgeführt wird, und müssen die Betriebssystemversion überprüfen, um zu ermitteln, welche Komponenten auf einem bestimmten Betriebssystem installiert werden sollen.
      • Apps, die nur die Mindestversion des Betriebssystems überprüfen (nur während der Installation, nicht zur Laufzeit), indem sie nur die genehmigten API-Aufrufe verwenden und die Mindestversionsanforderung im App-Manifest nach Bedarf auflisten.
      • Sicherheits-Apps wie Antiviren- und Firewall-Apps, Systemhilfsprogramme wie Defragmentierung und Sicherungs-Apps sowie Diagnosetools, die die Betriebssystemversion überprüfen, indem nur die genehmigten API-Aufrufe verwendet werden.

Benutzerkontensteuerung (User Account Control, UAC)-Test

Testet die App, um sicherzustellen, dass sie nicht unnötig erhöhte Berechtigungen zum Ausführen benötigt.

  • Hintergrund
    • Eine App, die nur 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 den Computer des Benutzers eingeben kann.
    • Wenn Benutzer immer gezwungen sind, Apps mit Token mit erhöhten Rechten auszuführen, kann die App als Einstiegspunkt für betrügerischen oder schädlichen Code servern. Diese Schadsoftware kann das Betriebssystem leicht ändern oder schlimmer noch schlimmer, andere Benutzer beeinflussen. Es ist fast unmöglich, einen Benutzer zu steuern, der voll administratorzugriff hat, 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, bei denen sich Benutzer als Standardbenutzer anmelden. Standarddesktops reduzieren die Kosten des Helpdesks erheblich und verringern den IT-Aufwand.
    • Für die meisten Anwendungen sind zur Laufzeit keine Administratorrechte erforderlich. Ein Standardbenutzerkonto sollte sie ausführen können. Windows-Apps müssen über ein Manifest (eingebettet oder extern) verfügen, um die Ausführungsebene zu definieren, die das Betriebssystem über die zum Ausführen der App erforderlichen Berechtigungen informiert. 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 externe Manifeste ignoriert werden, wenn die App über ein internes Manifest verfügt.
      • Beispiel: <requestedExecutionLevel level="asInvoker | highestAvailable | requireAdministrator"" uiAccess="true|false""/>
      • Der Hauptprozess der App muss als Standardbenutzer ausgeführt werden (asInvoker). Alle administrativen Features müssen in einen separaten Prozess verschoben werden, der mit Administratorrechten ausgeführt wird.
      • Für Benutzer zugängliche Apps, die erhöhte Berechtigungen erfordern, müssen Authenticode signiert sein.
  • Testdetails
    • Alle benutzergerichteten Exes sollten mit dem Attribut "AsInvoker" gekennzeichnet werden. Wenn sie als "highestAvailable" gekennzeichnet sind oder "requireAdministrator" erforderlich sind, sollten sie richtig authenticode signiert sein. Jede App-Exe sollte das uiAccess-Attribut nicht auf "true" festgelegt haben. Jede Exe, die als Dienst ausgeführt wird, wird von dieser speziellen Prüfung ausgeschlossen.
  • Korrekturmaßnahmen
    • Überprüfen Sie die Manifestdatei der App auf die richtigen Einträge und Berechtigungsstufen.
  • Ausnahmen und Verzichtserklärungen
    • Eine Verzichtserklärung ist für Apps erforderlich, die ihren Hauptprozess mit erhöhten Berechtigungen ausführen (requireAdministrator oder highestAvailable). Der Hauptprozess ist der Prozess, der den Einstiegspunkt des Benutzers zur App bereitstellt.
    • Verzichtserklärungen werden für die folgenden Szenarien berücksichtigt:
      • Verwaltungs- oder Systemtools mit Ausführungsebene, die auf höchsten Verfügbarenfestgelegt sind, erfordernAdministrator-oder beides.
      • Nur Barrierefreiheits- oder Benutzeroberflächenautomatisierungs-Framework-App legt die UIAccess-Kennzeichnung 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".

Einhalten von Nachrichten des Systemneustart-Managers

Testet, wie die App auf das Herunterfahren des Systems reagiert und Nachrichten neu startet.

  • Hintergrund
    • Apps müssen so schnell wie möglich beendet werden, wenn sie benachrichtigt werden, dass das System heruntergefahren wird, um ein reaktionsfähiges Herunterfahren oder Einschalten für den Benutzer zu ermöglichen.
    • In einem kritischen Herunterfahren werden Apps, die FALSE an WM_QUERYENDSESSION zurückgeben, WM_ENDSESSION und geschlossen, während diese Zeitüberschreitung als Reaktion auf WM_QUERYENDSESSION vorzeitig beendet werden.
  • Testdetails
    • Untersucht, wie die App auf Herunterfahren und Beenden von Nachrichten reagiert.
  • Korrekturmaßnahmen
    • Wenn ihre App diesen Test nicht erfüllt, überprüfen Sie, wie sie diese Windows-Nachrichten behandelt:
      • WM_QUERYENDSESSION mit LPARAM- = ENDSESSION_CLOSEAPP(0x1): Desktop-Apps müssen sofort auf einen Neustart reagieren (TRUE). Konsolen-Apps können SetConsoleCtrlHandler- aufrufen, um Benachrichtigungen 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 herunterfahren. Apps sollten sich mindestens darauf vorbereiten, indem alle Benutzerdaten gespeichert und die Informationen angegeben werden, die nach einem Neustart benötigt werden.
    • Konsolen-Apps, die die CTRL_C_EVENT-Benachrichtigung erhalten, sollten sofort beendet werden. Treiber dürfen kein System herunterfahren-Ereignis veto.
    • 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 den Grund für den Benutzer erläutert. Nach Abschluss des Vorgangs sollte die App ShutdownBlockReasonDestroy- aufrufen, um anzugeben, dass das System heruntergefahren werden kann.

Test des abgesicherten Modus

Testet, ob der Treiber oder Dienst so konfiguriert ist, dass er im abgesicherten Modus gestartet wird.

  • 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 macht es schwieriger, Probleme mit dem Betriebssystem zu beheben.
    • Standardmäßig starten nur die Treiber und Dienste, die mit Windows vorinstalliert sind, im abgesicherten Modus. Alle anderen Treiber und Dienste sollten deaktiviert werden, es sei denn, das System erfordert sie für grundlegende Vorgänge oder für Diagnose- und Wiederherstellungszwecke.
  • Testdetails
    • Von der App installierte Treiber sollten nicht für das Laden im abgesicherten Modus gekennzeichnet werden.
  • Korrekturmaß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
    • Für Treiber und Dienste, die im abgesicherten Modus gestartet werden müssen, muss eine Verzichtserklärung zertifiziert werden. Die Verzichtserklärungsanforderung muss jeden Treiber und Dienst enthalten, um den SafeBoot-Registrierungsschlüsseln hinzuzufügen und die technischen Gründe zu beschreiben, warum der Treiber oder Dienst im abgesicherten Modus ausgeführt werden muss. Das App-Installationsprogramm muss alle diese Treiber und Dienste in diesen 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 im abgesicherten Modus ohne Fehler funktionieren.

Multiuser-Sitzungstest

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 lokal oder remote ausgeführt werden. 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 werden.
  • Testdetails
    • Führt mehrere gleichzeitige Instanzen der App aus, um Folgendes zu testen:
      • Mehrere Instanzen einer Gleichzeitig ausgeführten App sind voneinander isoliert.
    • Dies bedeutet, dass Benutzerdaten aus einer Instanz für eine andere Instanz 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 gemeinsam genutzte Ressourcen verwenden, muss die App sicherstellen, dass kein Konflikt vorliegt.
      • Wenn die App für mehrere Benutzer installiert wurde, speichert sie Daten in den richtigen Ordnern und Registrierungsspeicherorten.
      • Die App kann in mehreren Benutzersitzungen (schnelles Benutzerwechseln) sowohl für den lokalen 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 nicht mehrere Benutzersitzungen oder Remotezugriff unterstützt, muss sie dem Benutzer klar sagen, wenn sie aus 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 anderen Benutzern nicht zur Verfügung.
    • Ihre App muss systemweite Konfigurations- und Datendateien während der Installation 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 entweder lokal oder remote blockiert. Die App darf nicht von globalen Mutexes oder anderen benannten Objekten abhängen, um nach mehreren gleichzeitigen Sitzungen zu suchen 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 für Abstürze und Blockaden

Überwacht die App während des Zertifizierungstests, um aufzuzeichnen, wann sie abstürzt oder hängt.

  • Hintergrund
    • App-Fehler wie Abstürze und Blockaden sind eine große Unterbrechung der Benutzer und führen zu 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 dazu führen, dass der Benutzer Daten verliert und eine schlechte Erfahrung hat.
  • Testdetails
    • Wir testen die Resilienz und Stabilität der App während der gesamten Zertifizierungstests.
    • Das Zertifizierungskit für Windows-Apps ruft IApplicationActivationManager::ActivateApplication auf, um Windows Store-Apps zu starten. Für ActivateApplication- zum Starten einer App muss die Benutzerkontensteuerung (User Account Control, UAC) aktiviert sein, und die Bildschirmauflösung muss mindestens 1024 x 768 oder 768 x 1024 sein. Wenn eine der Bedingungen nicht erfüllt ist, schlägt Ihre App diesen Test fehl.
  • Korrekturmaßnahmen
    • Stellen Sie sicher, dass die Benutzerkontensteuerung auf dem Testcomputer aktiviert ist.
    • Stellen Sie sicher, dass Sie den Test auf einem Computer mit ausreichend großem Bildschirm ausführen.
    • Wenn Ihre App nicht gestartet werden kann und Ihre Testplattform die Voraussetzungen für ActivateApplicationerfüllt, können Sie das Problem beheben, indem Sie das Aktivierungsereignisprotokoll überprüfen. So suchen Sie diese Einträge im Ereignisprotokoll:
      1. Öffnen Sie eventvwr.exe, und navigieren Sie zum Knoten \Windows Logs\Application.
      2. Filtern Sie die Ansicht, um Ereignis-IDs anzuzeigen: 5900-6000.
      3. Überprüfen Sie die Protokolleinträge auf Informationen, die möglicherweise erläutern, warum die App nicht gestartet wurde.
    • Beheben Sie die Datei mit dem Problem, identifizieren und beheben Sie das Problem. Erstellen Sie die App neu, und testen Sie sie erneut.
  • Weitere Ressourcen

Kompatibilitäts- und Resilienztest

  • Hintergrund
    • Mit dieser Überprüfung werden zwei Aspekte einer App überprüft, die hauptdatei(n) der App, z. B. der Einstiegspunkt für benutzerorientierte Apps, muss aus Kompatibilitätsgründen manifestiert werden und die richtige GUID deklarieren. Zur Unterstützung dieses neuen Tests verfügt der Bericht über einen Unterknoten unter "Kompatibilität & Resilienz". Die App schlägt fehl, wenn eine oder beide dieser Bedingungen fehlen.
  • Testdetails
    • Kompatibilität: Apps müssen vollständig funktionsfähig sein, ohne Windows-Kompatibilitätsmodi, AppHelp-Nachrichten oder andere Kompatibilitätsfixes zu verwenden. Mit einem Kompatibilitätsmanifest kann Windows Ihrer App das richtige Kompatibilitätsverhalten unter den verschiedenen Versionen des Betriebssystems bereitstellen.
    • AppInit: Apps dürfen keine DLLs auflisten, die im HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs Registrierungsschlüssel geladen werden.
    • Switchback: Die Anwendung muss das Switchbackmanifest bereitstellen. Wenn das Manifest fehlt, gibt das Zertifizierungskit für Windows-Apps eine Warnmeldung an. Das Zertifizierungskit für Windows-Apps überprüft außerdem, dass das Manifest gültige Betriebssystem-GUID enthält.
  • Korrekturmaßnahmen
    • Beheben Sie die App-Komponente, die die Kompatibilitätskorrektur verwendet.
    • Stellen Sie sicher, dass die App nicht auf Kompatibilitätsfixes für ihre Funktionalität angewiesen ist.
    • Stellen Sie sicher, dass Ihre App manifestiert ist, und der Kompatibilitätsabschnitt enthält die entsprechenden Werte.
  • Zusatzinformation

Test der bewährten Methoden für Windows-Sicherheit

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

Test der Windows-Sicherheitsfeatures

  • Hintergrund
    • Anwendungen müssen windows-Sicherheitsfeatures aktivieren. Das Ändern der standardmäßigen Windows-Sicherheitsschutzmechanismen kann Kunden zu einem erhöhten Risiko führen.
  • Testdetails
    • Testet die Sicherheit der App durch Ausführen des BinScope Binary Analyzer. Weitere Informationen finden Sie hier.
  • Korrekturmaßnahmen
    • Behandeln und Beheben des problems, das von den Tests identifiziert wurde. Erstellen Sie die App neu, und testen Sie sie erneut.

Hoher DPI-Test

Es wird dringend empfohlen, dass die Win32-Apps dpi-fähig sind. Es ist der Schlüssel, die App-UI in einer Vielzahl von Dpi-Anzeigeeinstellungen konsistent gut aussehen zu lassen. Eine nicht DPI-fähige App, die auf einer Bildschirmeinstellung mit hohem DPI-Wert ausgeführt wird, kann Probleme haben, z. B. eine falsche Skalierung von UI-Elementen, beschnittenem Text und verschwommenen Bildern. Es gibt zwei Möglichkeiten, eine App zu deklarieren, die DPI-Wert aufweist. Eine besteht darin, DPI-Werte zu deklarieren.

  • Hintergrund
    • Diese Überprüfung überprüft zwei Aspekte einer App, die wichtigsten ausführbaren Dateien, z. B. die Einstiegspunkte für Benutzer, müssen für HIGH-DPI Bewusstsein 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. Diese Überprüfung führt einen neuen Abschnitt im Desktopbericht ein, siehe Beispiel unten.
  • Testdetails
    • Der Test generiert eine Warnung, wenn eine der folgenden Aktionen erkannt wird:
      • Die Haupt-EXE deklariert den DPI-Grad nicht im Manifest und ruft keine SetProcessDPIAware-API auf. (Warnen Sie den Entwickler, wenn er vergessen hat, das DPI-Sensibilisierungsmanifest hinzuzufügen).
      • Die Haupt-EXE deklariert den DPI-Grad nicht im Manifest, ruft jedoch setProcessDPIAware-API auf (warnt den Entwickler, dass er das Manifest zum Deklarieren des DPI-Bewusstseins verwenden sollte, anstatt die API aufzurufen).
      • Der mainEXE deklariert den DPI-Grad in seinem Manifest, ruft jedoch auch die SetProcessDPIAware-API auf (warnt den Entwickler, dass das Aufrufen dieser API nicht erforderlich ist).
      • Geben Sie für die Binärdateien, die keine haupt-EXEs sind, eine Warnung an , wenn sie die API aufrufen (Das Aufrufen der API wird nicht empfohlen).
  • Korrekturmaßnahmen
    • Die Verwendung der SetProcessDPIAware()-Funktion wird abgeraten. Wenn eine DLL dpi-Einstellungen während der Initialisierung zwischenspeichert, kann das Aufrufen von SetProcessDPIAware() in der App eine Racebedingung generieren. Das Aufrufen der SetProcessDPIAware()-Funktion in einer DLL ist ebenfalls keine gute Methode.
  • Zusatzinformation