Unsere Berichte zur Annahme hatten wir bereits in einem vorherigen Beitrag erläutert. Diese Berichte liefern Ihnen Informationen über Downloads, Annahmerate, Benutzerbewertungen sowie Verwendungshäufigkeit. Dadurch können Sie die Popularität Ihrer App ermitteln. Berichte zur Annahme sind hilfreich, jedoch nur ein Teil der Berichterstattungstools, die im Windows Store zur Verfügung stehen. Dort finden Sie auch Berichte zur App-Qualität. Anhand dieser Berichte können Sie die Qualität Ihrer Apps messen und verbessern. In diesem Beitrag beschreibt Programmmanager Kalyan Venkatasubramanian die Qualitätsberichte des Stores und wie Sie diese zur Verbesserung Ihrer Apps verwenden können.

– Antoine Leblond


Zunächst sollten wir definieren, was wir unter „Qualität“ verstehen. Qualität vereint viele Aspekte, darunter Benutzerfreundlichkeit, Zuverlässigkeit, Sicherheit usw. Wir haben uns entschieden, Ihnen Qualitätsberichte für Apps im Windows Store bereitzustellen, die auf Analysedaten zur Zuverlässigkeit der App aufgrund von Kundenerfahrungen beruhen.

Sie können über die Seite mit den App-Trends auf die Qualitätsberichte Ihrer App zugreifen. Klicken Sie auf dieser Seite auf den Link „Quality“ (Qualität), um zu den Qualitätsberichten zu gelangen.

Qualitätsberichte

Beispiel für die Ansicht der Qualitätsberichte im Dashboard.

Diese Berichte messen die Qualität Ihrer App durch die Nachverfolgung der Fehlerrate, d. h. die Anzahl der bei den Benutzern auftretenden Fehler. Ein Fehler ist definiert als unerwartetes Schließen einer App aufgrund einer der folgenden Ursachen:

  1. Absturz
  2. Nicht reagierende App (App hängt)
  3. JavaScript-Ausnahmefehler

(Hinweis: JavaScript-Ausnahmefehler bzw. JavaScript-Ausnahmen können natürlich nur bei Apps auftreten, die JavaScript verwenden. )

Ziel dieser Berichte:

  1. Sie können die Qualität Ihrer App über die unterschiedlichen, im Store veröffentlichten Versionen nachvollziehen. Dadurch wissen Sie, ob nachfolgende Versionen bei Benutzern Ihrer App besser ausgeführt werden.
  2. Sie können die Qualität Ihrer App verbessern. Sie können die Qualität Ihrer App mit dem Wissen über die und dem Verständnis der am häufigsten auftretenden Fehler (aus Sicht Ihrer Kunden) in der aktuellen im Store veröffentlichten Version verbessern. Wenn Sie die am häufigsten auftretenden Fehler verstehen, können Sie diese beheben und Updates Ihrer App im Store veröffentlichen.

Verständnis der Qualität Ihrer App

Wie im letzten Abschnitt beschrieben, können Sie die App-Qualität über die Fehlerrate ermitteln. Fehlerraten werden für jeden einzelnen Fehlertyp berechnet: Abgestürzte bzw. hängende Apps oder JavaScript-Ausnahmefehler (im Falle von JavaScript-Apps). Die Daten zur Berechnung der Fehlerrate werden von zufällig ausgewählten Computern erfasst, auf denen Ihre App ausgeführt wird (als Qualitätspanel bezeichnet). Wir halten einen Stichprobenumfang des Qualitätspanels von mindestens 500 Computern für die Berechnung der Fehlerraten für ausreichend. Wenn das Qualitätspanel Ihrer App weniger als 500 Computer umfasst, enthält der Bericht den Hinweis: „The data displayed is from a sample set that is not statistically significant.“ (Die angezeigten Daten stammen aus einer Stichprobe, die statistisch nicht signifikant ist.). Wir werden bis zu diesem Schwellenwert weiterhin Daten sammeln, um sicherzustellen, dass Ihnen präzise Informationen möglichst schnell zur Verfügung stehen.

Die Fehlerraten werden über die durchschnittliche Anzahl an aufgetretenen Fehlern auf einem Computer während der ersten 15 Minuten der tatsächlichen Verwendung berechnet. Wenn alle App-Daten des PC-Ökosystems einbezogen werden, ist zu erkennen, dass die gemessene Zuverlässigkeit einer App sich im Lauf der Zeit stabilisiert. Nach einer gewissen Verwendungshäufigkeit ist die Variation der Fehlerrate minimal. Bei Apps im Metro-Stil in der Consumer Preview tritt diese Stabilisierung nach etwa 15 Minuten ein. Dieser Zeitrahmen stellt sicher, dass die Ihnen zur Verfügung gestellten Daten sowohl genau als auch zeitnah sind. (Das Festlegen eines längeren Zeitraums für das Panel würde die Berichterstattung verzögern.) Wir werden im Zuge der höheren Verbreitung von Apps im Metro-Stil den Schwellenwert für die Größe des Qualitätspanels weiterhin beobachten. Ausreißer werden bei der Berechnung der Fehlerraten nicht berücksichtigt, um eine Verzerrung der Ergebnisse zu vermeiden.

Hier sehen Sie ein Beispiel für eine Fehlerrate.

Beispieldiagramm einer Fehlerrate

Verbessern der App-Qualität

Im vorherigen Abschnitt wurde erläutert, wie Sie die Änderung bezüglich der App-Qualität in unterschiedlichen Versionen nachvollziehen können. Es ist uns auch bewusst, dass Sie über die am häufigsten auftretenden Fehler informiert werden möchten, mit denen Ihre Kunden in der aktuellen Version Ihrer App konfrontiert sind. Daher stellen wir Ihnen für die letzte Version Ihrer App eine nach Häufigkeit sortierte Liste mit allgemeinen Fehlern bereit. Die Fehlerhäufigkeit wird über die Gesamtzahl der beim Kunden aufgetretenen Vorkommnisse ermittelt.

Denken Sie daran, dass die Fehlerraten des Qualitätspanels nach strengen Kriterien berechnet werden und von der tatsächlichen Verwendung Ihrer App abhängig sind. Die Daten für die Liste mit den am häufigsten auftretenden Fehlern stammen von allen Benutzern Ihrer App. Aber was geschieht, wenn die Mehrzahl der Benutzer Ihrer App aufgrund der aufgetretenen Fehler die Nutzungsanforderungen gar nicht erst erfüllen konnte? In solchen Fällen liegt die Fehlerrate bei Null (0). Sie können jedoch die am häufigsten aufgetretenen Fehler dieser App einsehen, wie hier gezeigt:

Beispiel eines Berichts mit den am häufigsten aufgetretenen Fehlern.

Mithilfe der Liste der am häufigsten aufgetretenen Fehler bei der Verwendung Ihrer App, deren Berechnung unabhängig von der Fehlerrate erfolgt (siehe die obigen Abbildung zu Abstürzen) und auf einer größeren Datenmenge basiert, können Sie Fehler erkennen und beheben, die bei allen Benutzern auftreten. Dadurch wissen Sie bereits kurz nach der Veröffentlichung von Fehlern in Ihrer App und können auf diese reagieren.

Abstürze und hängende Apps

Wir zeigen Ihnen die fünf am häufigsten auftretenden Fehler der aktuellen Version Ihrer App, die Abstürze und hängende Apps zu Folge haben. Das Ergebnis berechnet sich aus der Gesamtzahl des bei allen Kunden Ihrer App aufgetretenen Fehlers. Über den Link Download können Sie eine CAB-Datei mit der Prozesssicherung für diesen Fehler herunterladen.

Beispiel für die am häufigsten auftretenden Abstürze einer App.

Ein Fehler wird über einen Fehlernamen eindeutig identifiziert. Ein Beispiel für einen Fehlernamen bei Abstürzen und hängenden Apps ist:

NULL_CLASS_PTR_READ_c0000005_mydll.dll!myfunc::DoOp

Der Fehlername lässt sich in folgende Elemente aufschlüsseln:

  • Problem-Klasse (NULL_CLASS_PTR_READ)
  • Fehlercode (c0000005)
  • Symbol (mydll.dll!myfunc::DoOp)

Hinweis: Informationen über die Bestimmung der Fehlerursache finden Sie hier. Auch wenn dieser Blogbeitrag nicht speziell auf Apps im Metro-Stil Bezug nimmt, ist es ein lesenswerter Beitrag, um Sammlung und Verarbeitung von Fehlern besser zu verstehen.

Sie können den Grund für den Absturz oder das Hängen Ihrer App ermitteln, indem Sie die zugehörige CAB-Datei herunterladen. Die CAB-Datei enthält eine Prozesssicherung mit dem Fehler in Ihrer App. Sie erhalten Stapelüberwachungen und weitere Details über den Fehler aus der Prozesssicherung.

Die Voraussetzungen zum Ausführen der CAB-Datei und zum Extrahieren der Stapelüberwachungen sind:

  1. Installation von WinDbg.exe auf Ihrem Computer.
    WinDbg.exe ist das empfohlene Debuggingtool, um Stapelüberwachungen aus der Prozesssicherung zu erhalten. Wenn WinDbg.exe nicht auf Ihrem Computer installiert ist, erhalten Sie es hier.
  2. Symbole für die Anwendung.
    Um die Stapelüberwachungen aus der Prozesssicherung zu erhalten, sollten Sie über die Symbole verfügen, die der aktuellen Version Ihrer App im Store entsprechen.

Stapelüberwachungen für Abstürze und hängende Apps

Diese Schritte sind nicht als grundlegende Debugger-Anleitung zu verstehen. Sie können jedoch die Stapelüberwachungen für die Fehler in Ihren Apps erhalten.

  1. Klicken Sie neben dem Fehlernamen auf den Link Download (Herunterladen), um alle Ihrer App zugeordneten Fehler (Abstürze oder Hängen) anzuzeigen. Gehen wir davon aus, der Fehlername ist:
    STATUS_INTEGER_DIVIDE_BY_ZERO_c0000094_FaultoidEx.Engine.dll!?__abi_FaultoidEx_Engine___IEngineServerPublicNonVirtuals____abi_DivideByZero
  2. Speichern Sie die CAB-Datei auf Ihrem Computer.
  3. Starten Sie WinDbg.exe.
  4. Klicken Sie auf File (Datei) und anschließend auf Open Crash Dump (Absturzabbild öffnen).

    WinDbg-Bildschirm.
  5. Zeigen Sie im Dialogfeld „Open Crash Dump“ (Absturzbild öffnen) auf die gespeicherte Datei (Schritt 2), und klicken Sie auf „Öffnen“ (Open).

    So wird eine Datei in WinDbg geöffnet.
  6. Klicken Sie auf File > Symbol File Path (Datei > Symboldateipfad), und geben Sie den Pfad der Symbole ein, die mit der im Store verfügbaren Version übereinstimmen. Aktivieren Sie das Kontrollkästchen Reload (Erneut laden), und klicken Sie auf „OK“.

    Beispiel für die Angabe des Symbolpfads in WinDbg.

    Wenn Sie die öffentlich zugänglichen Symbole von Microsoft anzeigen möchten (für Binärdateien, die sich von Ihrer App unterscheiden), verwenden Sie für den Symbolpfad das folgende Format:
    Srv*;<<Ihr Symbolpfad>>
    Wenn Ihr Symbolpfad „c:\symbols“ ist, sieht der entsprechende Pfad nach den oben genannten Anleitung wie folgt aus:
    Srv*;c:\symbols
  7. Geben Sie nach der Eingabeaufforderung in das Befehlsfenster !analyze –v ein, und drücken Sie die EINGABETASTE.

    Beispiel einer Stapelüberwachung in WinDbg.

    Die Fehler im vorherigen Screenshot weisen darauf hin, dass die Symbole für einige DLL-Dateien nicht übereinstimmen. Während die in Schritt 7 beschriebene Festlegung der Symbole die Anzahl der angezeigten Fehler reduziert, sollten Sie überprüfen, ob sich die Fehler in den DLL-Dateien und EXE-Dateien Ihrer App befinden. Wenn Fehler und Hinweise die Binärdateien in Ihrer App betreffen, konnte der Debugger die richtigen Symbole für Ihre App nicht finden. Sie sollten den richtigen Pfad der gespeicherten Symbole identifizieren und wie in Schritt 7 beschrieben hinzufügen.
  8. Die Stapelüberwachung wird im Befehlsfenster wie folgt dargestellt:

    Beispiel einer Stapelüberwachung in WinDbg.


Die Aufrufliste zeigt an, dass der Fehler eine „divide by zero“-Ausnahme der Funktion DivideByZero in FaultoidEx.Engine.dll ist. Dies stimmt mit dem Fehlernamen aus Schritt 1 überein und hilft Ihnen beim Verständnis des Fehlers und bei der Fehlerbehebung.

JavaScript-Ausnahmen

Die Fehlerrate und die häufigsten JavaScript-Ausnahmen sind nur bei JavaScript-Apps relevant. Wir zeigen Ihnen die 15 am häufigsten auftretenden Fehler für JavaScript-Ausnahmen der aktuellen Version Ihrer App. In dieser Liste werden mehr JavaScript-Fehler angezeigt, da wir aufgrund von Telemetriedaten wissen, dass JavaScript-Ausnahmen verglichen mit anderen Abstürzen häufiger auftreten. Mithilfe der höheren Fehleranzahl, die für JavaScript-Ausnahmen angezeigt werden, können Sie die Qualität Ihrer App verbessern und Abstürze sowie das Hängen von Apps reduzieren.

Beispiel für einen Bericht mit häufigen JavaScript-Ausnahmen

Standardmäßig werden die fünf am häufigsten auftretenden Fehler bei JavaScript-Ausnahmen aufgeführt. Wenn Sie auf die Schaltfläche Show All (Alle anzeigen) klicken, werden bis zu 15 Fehler angezeigt.

Ein Beispiel für einen Fehlernamen bei JavaScript-Ausnahmen lautet wie folgt:

WinRT error_8007007E_msappx://Contoso.ContosoApp8wekyb3d8bbwe/ContosoApp/program.js!scenario1Run

Bei JavaScript-Ausnahmen wird ein Fehlername wie folgt definiert:

  • ErrorTypeText (WinRT-Fehler)
  • ErrorNumber (8007007E)
  • Filename_FunctionName (program.js!scenario1Run)

Stapelüberwachungen für JavaScript-Ausnahmen

Die Ursache einer JavaScript-Ausnahme können Sie mithilfe der folgenden Schritte ermitteln:

  1. Klicken Sie neben dem Fehlernamen auf den Link Download (Herunterladen), um alle Ihrer App zugeordneten Fehler (JavaScript-Ausnahmen) anzuzeigen.
  2. Speichern Sie die CAB-Datei auf Ihrem Computer.
  3. In der Datei befindet sich eine Datei, deren Name mit ErrorInfo beginnt (ErrorInfo-Datei). Extrahieren Sie die Datei, und speichern Sie diese auf Ihrem Computer.
  4. Öffnen Sie die ErrorInfo-Datei (siehe Schritt 3) mit Notepad.
  5. Die ErrorInfo-Textdatei enthält die Stapelüberwachungen mit dem Fehler in Ihrer App. Hier ein Beispiel:
    Beispiel für eine ErrorInfo-Datei.

In diesem Beispiel liegt der Fehler bei einer nicht definierten Funktion. Die Aufrufliste, die bis zum Fehler führt, befindet sich ebenfalls in der ErrorInfo-Datei.

Fazit

Wir glauben, dass es beim Erstellen erfolgreicher Apps wichtig ist, sowohl Fehler zu verstehen als auch die Qualität zu verbessern. Wir haben den Qualitätsbericht entwickelt, damit Ihnen hilfreiche und praxisbezogene Daten zur Verbesserung Ihrer App zur Verfügung stehen. Wir sind uns sicher, dass diese Berichte Ihnen dabei helfen, wichtige Verbesserungen vorzunehmen, damit Sie rasch Updates für Ihre Apps im Store bereitstellen können.

Wir freuen uns darauf, über Ihren Erfahrungen mit dem Qualitätsbericht sowie anderen Berichten unseres Analyseportals zu lesen.

– Venkat