Analyse des rapports d’incident

Applies to Windows only

Toutes les applications doivent être parfaitement fonctionnelles lorsqu’elles passent la procédure de certification. Si votre application se bloque ou ne répond plus pendant la procédure de certification, vous recevrez un rapport de certification contenant des fichiers supplémentaires que vous pouvez utiliser pour trouver la cause du problème.

Selon le type d’erreur, vous recevrez :

  • Un fichier de vidage sur incident. Ce fichier contient les informations les plus importantes sur une application bloquée. Il ne contient pas une image mémoire complète de l’espace de processus de l’application. Au contraire, un fichier de vidage sur incident ne contient que les informations critiques, comme l’arborescence des appels de procédure au moment du blocage. Il contient aussi la liste des threads, leur contexte et la mémoire utilisée pour leurs piles.
  • Un fichier ErrorInfo. Si vous avez écrit votre application en JavaScript, HTML ou CSS, et si elle bloque, il est probable que ce soit dû à une exception JavaScript. Le cas échéant, vous recevez un fichier ErrorInfo à la place d’un fichier de vidage sur incident. Ce fichier contient des informations comme l’origine, l’emplacement ou la cause de l’exception JavaScript.

Pour consulter ces fichiers, nous vous recommandons d’utiliser Microsoft Visual Studio ou les outils du débogueur Windows.

Utilisation des fichiers de vidage sur incident

Pour ouvrir un fichier de vidage sur incident Microsoft Visual Studio, cliquez deux fois sur le fichier ou sélectionnez Ouvrir dans le menu Fichier de Visual Studio. Après que Visual Studio a chargé le fichier, vous verrez un résumé du fichier de vidage sur incident.

Résumé d’un fichier de vidage sur incident dans Visual Studio.

Ce résumé mentionne le nom du processus qui a bloqué avec le code d’exception et une description de l’exception. Il inclut également une liste des modules chargés par le processus.

Pour poursuivre le débogage, vous devez définir le chemin d’accès aux symboles et déboguer le fichier. Les options pour effectuer ces tâches sont disponibles sur le côté droit de Visual Studio.

Menu de débogage dans Visual Studio.

JJ933262.wedge(fr-fr,WIN.10).gifPour définir le chemin d’accès aux symboles

  1. Cliquez sur Définir le chemin d’accès aux symboles.
  2. Activez l’option Serveurs de symboles Microsoft.
  3. Dans la zone Mettre en cache les symboles dans ce répertoire, tapez c:\symbols ou le répertoire de votre choix.
  4. Cliquez sur OK.

Pour plus d’informations sur les symboles, consultez Find Symbol (.pdb),Source, and Binary Files.

Une fois votre chemin d’accès aux symboles défini, cliquez sur Déboguer avec Natif uniquement ou sur Déboguer en mode mixte selon ce qui convient. La définition de l’une de ces options permet de télécharger les symboles appropriés. Ensuite, vous devriez voir une boîte de dialogue contenant plus d’informations sur l’exception :

Informations sur l’exception dans un fichier de vidage sur incident.

Pour afficher l’intégralité de la pile d’appels au moment de l’exception, cliquez sur Arrêter, puis choisissez de charger le code source ou d’afficher le code machine. Si les symboles pour votre application ont été correctement chargés, vous devriez voir le code source de votre application, et disposer alors des informations dont vous avez besoin pour identifier la cause du blocage.

Utilisation des fichiers ErrorInfo

Pour ouvrir un fichier ErrorInfo, cliquez deux fois sur le fichier ou sélectionnez Ouvrir dans le menu Fichier. Voici à quoi ressemble un fichier ErrorInfo :

ErrorDescription='thisFunctionDoesNotExist' is undefined
ErrorType=3
ErrorTypeText=Reference error
ErrorNumber=800A1391
SourceFile=ms-appx://microsoft.wer.tailored.faultoid/default.html
Line=64
Character=9
DocumentURL=/default.html
OSProduct=Windows 8 Pro
OSVersion=6.2.9200.0
OSServicePack=0
UserAgentString=Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; MSAppHost/1.0)
StackTraceAvailability=2
StackTrace=ms-appx://microsoft.wer.tailored.faultoid/default.html:64:9           CallMissingFunction()
           ms-appx://microsoft.wer.tailored.faultoid/default.html:128:1           onclick(object)
StackTraceHash=d5221125b1e4d806414f07cc117c68c9
PackageFullName=microsoft.WER.Tailored.Faultoid_1.11.0.1_x64__8wekyb3d8bbwe
AppUserModelID=microsoft.WER.Tailored.Faultoid_8wekyb3d8bbwe!WER.Tailored.Faultoid
IsTerminal=True
DependentPackageList=(null)

Ce fichier est organisé à l’aide d’intitulés et donne des informations sur l’origine, l’emplacement ou la cause de l’exception JavaScript. Par exemple, les fichiers ci-dessus fournissent les détails suivants sur l’exception :

  • L’exception s’est produite à la ligne 64, au caractère 9, dans le fichier default.html de l’application.
  • L’exception était une erreur de référence avec la description suivante : « 'thisFunctionDoesNotExist' n’est pas défini ». (La valeur ErrorNumber fournit un état numérique pour l’erreur, qui peut aussi être utilisé pour obtenir des informations supplémentaires sur la cause de l’exception.)
  • Arborescence des appels de procédure au moment de l’exception. Ces informations utilisent le modèle suivant :

    [App source file]:[Line Number]:[Character Position] [Function Name]

    Par exemple :

    ms-appx://microsoft.wer.tailored.faultoid/default.html:64:9 CallMissingFunction()

    ms-appx://microsoft.wer.tailored.faultoid/default.html:128:1 onclick(object)

Avec ces informations, vous pouvez rechercher plus avant la cause de l’exception dans votre application.

Remarque  Quand votre application est disponible dans le Windows Store, vous pouvez obtenir des informations sur les incidents et d’autres problèmes de performances qui se produisent pendant que les clients utilisent votre application.

 

 

Afficher:
© 2014 Microsoft