Accidents du Centre d'Applications (Windows)

App Center Crashes génèrera automatiquement un journal des crashs chaque fois que votre application se bloque. Le journal est d’abord écrit dans le stockage de l’appareil et lorsque l’utilisateur redémarre l’application, le rapport d’incident est envoyé à App Center.

Le Kit de développement logiciel (SDK) App Center collecte uniquement les incidents provoqués par des exceptions .NET non gérées. Il ne collecte pas les blocages natifs, par exemple lors de l’utilisation de C ou C++. Toutefois, si vous avez une application avec des crashs C++, vous pouvez les télécharger dans App Center via l'API de téléchargement des crashs.

Suivez la prise en main WPF/WinForms si vous n’avez pas encore configuré le Kit de développement logiciel (SDK) dans votre application.

Exceptions non gérées sur les applications WinForms

Par défaut, une exception non gérée dans une application WinForms ne déclenche pas d’incident (l’application ne se ferme pas) si le débogueur n’est pas attaché.

Au lieu de cela, Windows affiche une boîte de dialogue à l’utilisateur pour continuer ou quitter l’exécution de l’application. Par conséquent, le Kit de développement logiciel (SDK) App Center ne peut pas capturer automatiquement ces exceptions (même si l’utilisateur clique sur le bouton Quitter ).

Les crashs sont collectés sur App Center uniquement s'ils provoquent la fermeture automatique de l'application. App Center ne prend en charge qu’un incident par session.

Il existe deux façons de signaler des exceptions non gérées dans WinForms. L’application peut être configurée pour se bloquer sur des exceptions non gérées ou continuer à s’exécuter, mais signaler des exceptions non gérées en tant qu’erreurs d’exécution.

Configurer l’application pour qu’elle se termine en cas d’incident

Il s'agit de la seule façon de signaler une exception non gérée comme un incident sur App Center : faire en sorte que l'application se ferme en cas d'exceptions non gérées.

Pour ce faire, appelez une méthode Windows avant d’initialiser le Kit de développement logiciel (SDK) :

Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
AppCenter.Start(...);

Si cette option n’est pas acceptable dans votre application, vous pouvez signaler l’exception non gérée en tant qu’erreur d’exécution (décrite ci-dessous).

Signaler l’exception non gérée en tant qu’erreur d’exécution

Si votre application doit continuer à s’exécuter après une exception non gérée, vous ne pouvez pas signaler l’exception en tant qu’incident dans App Center, mais vous pouvez le signaler en tant qu’erreur.

Pour ce faire, vous pouvez utiliser l’exemple de code suivant :

Application.ThreadException += (sender, args) =>
{
    Crashes.TrackError(args.Exception);
};
AppCenter.Start(...);

Générer un plantage de test

App Center Crash vous fournit une API pour générer un plantage de test pour faciliter le test du Kit de développement logiciel (SDK). Cette API vérifie les configurations de débogage par rapport aux configurations de production. Vous pouvez donc l’utiliser uniquement lors du débogage, car il ne fonctionnera pas pour les applications de mise en production.

Crashes.GenerateTestCrash();

Obtenir plus d’informations sur un incident précédent

App Center Crash a deux API qui vous donnent plus d’informations au cas où votre application s’est écrasée.

L’application s’est-elle bloquée dans la session précédente ?

À tout moment après avoir démarré le Kit de développement logiciel (SDK), vous pouvez vérifier si l’application s’est bloquée lors du lancement précédent :

bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();

Cela est pratique si vous souhaitez ajuster le comportement ou l’interface utilisateur de votre application une fois qu’un incident s’est produit. Certains développeurs choisissent d’afficher une interface utilisateur supplémentaire pour s’excuser auprès de leurs utilisateurs, ou veulent un moyen d’entrer en contact après un incident.

Détails sur le dernier incident

Si votre application s’est écrasée précédemment, vous pouvez obtenir des détails sur le dernier incident.

ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();

Il existe de nombreux cas d’usage pour cette API, le plus courant est que des personnes appellent cette API et implémentent leur délégué ou écouteur Crashes personnalisé.

Personnalisez votre utilisation des pannes d’App Center

App Center Crash fournit des rappels aux développeurs pour effectuer des actions supplémentaires avant et lors de l’envoi de journaux d’incident à App Center.

La panne doit-elle être traitée ?

Définissez ce rappel si vous souhaitez décider si un incident particulier doit être traité ou non. Par exemple, il peut y avoir un blocage au niveau du système que vous souhaitez ignorer et que vous ne souhaitez pas envoyer à App Center.

Crashes.ShouldProcessErrorReport = (ErrorReport report) =>
{
    // Check the report in here and return true or false depending on the ErrorReport.
    return true;
};

Demander le consentement de l’utilisateur pour envoyer un journal d’incident

Si la confidentialité de l’utilisateur est importante pour vous, vous pouvez obtenir la confirmation de l’utilisateur avant d’envoyer un rapport d’incident à App Center. Le Kit de développement logiciel (SDK) expose une fonction de rappel qui indique à App Center Crashes d'attendre la confirmation de l’utilisateur avant d’envoyer tout rapport d’incident.

Si vous avez choisi de le faire, vous êtes responsable de l’obtention de la confirmation de l’utilisateur, par exemple via une invite de dialogue avec l’une des options suivantes : Toujours envoyer, envoyer et ne pas envoyer. En fonction des données fournies, vous allez indiquer à App Center Crashes ce qu’il doit faire et le plantage sera ensuite géré en conséquence.

Le callback suivant montre comment indiquer à l'SDK d'attendre la confirmation de l'utilisateur avant d'envoyer des pannes :

Crashes.ShouldAwaitUserConfirmation = () =>
{
    // Build your own UI to ask for user consent here. SDK doesn't provide one by default.

    // Return true if you built a UI for user consent and are waiting for user input on that custom UI, otherwise false.
    return true;
};

Si vous retournez true dans le rappel ci-dessus, votre application doit obtenir, en utilisant votre propre code, l'autorisation de l'utilisateur et communiquer le résultat au Kit de développement logiciel (SDK) via l'API suivante.

// Depending on the user's choice, call Crashes.NotifyUserConfirmation() with the right value.
Crashes.NotifyUserConfirmation(UserConfirmation.DontSend);
Crashes.NotifyUserConfirmation(UserConfirmation.Send);
Crashes.NotifyUserConfirmation(UserConfirmation.AlwaysSend);

Obtenir des informations sur l’état d’envoi d’un journal d’incident

Il arrive que vous souhaitiez connaître l'état du crash de votre application. Un cas d’usage courant est que vous souhaiterez peut-être afficher l’interface utilisateur qui indique aux utilisateurs que votre application envoie un rapport d’incident ou, si votre application se bloque rapidement après le lancement, vous souhaitez ajuster le comportement de l’application pour vous assurer que les journaux d’incident peuvent être soumis. App Center Crash fournit trois rappels différents que vous pouvez utiliser dans votre application pour être averti de ce qui se passe :

Le rappel suivant est appelé avant que le SDK envoie un journal d’incident

Crashes.SendingErrorReport += (sender, e) =>
{
    // Your code, e.g. to present a custom UI.
};

Si nous avons des problèmes réseau ou une panne sur le point de terminaison, et que vous redémarrez l’application, SendingErrorReport elle est déclenchée à nouveau après le redémarrage du processus.

Le rappel suivant sera appelé une fois que le Kit de développement logiciel (SDK) a envoyé un journal d’incident avec succès

Crashes.SentErrorReport += (sender, e) =>
{
    // Your code, e.g. to hide the custom UI.
};

Le rappel suivant est appelé si le Kit de développement logiciel (SDK) n’a pas pu envoyer un journal d’incident

Crashes.FailedToSendErrorReport += (sender, e) =>
{
    // Your code goes here.
};

Recevoir FailedToSendErrorReport signifie qu'une erreur non récupérable, telle qu'un code 4xx, s'est produite. Par exemple, 401 signifie que le appSecret est incorrect.

Ce rappel n’est pas déclenché s’il s’agit d’un problème réseau. Dans ce cas, le Kit de développement logiciel (SDK) continue de réessayer (et suspend également les nouvelles tentatives pendant que la connexion réseau est en panne).

Ajouter des pièces jointes à un rapport d’incident

Vous pouvez ajouter des pièces jointes binaires et textuelles à un rapport de plantage. Le SDK les enverra avec le rapport de plantage afin que vous puissiez les voir dans le portail App Center. Le callback suivant sera invoqué juste avant d’envoyer le crash stocké suite aux lancements précédents de l’application. Il ne sera pas appelé lorsque la panne se produit. Vérifiez que le fichier de pièce jointe n’est pas nommé minidump.dmp car ce nom est réservé aux fichiers minidump. Voici un exemple d’attachement de texte et d’image à un incident :

Crashes.GetErrorAttachments = (ErrorReport report) =>
{
    // Your code goes here.
    return new ErrorAttachmentLog[]
    {
        ErrorAttachmentLog.AttachmentWithText("Hello world!", "hello.txt"),
        ErrorAttachmentLog.AttachmentWithBinary(Encoding.UTF8.GetBytes("Fake image"), "fake_image.jpeg", "image/jpeg")
    };
};

Activer ou désactiver les crashs d’App Center au moment de l'exécution

Vous pouvez activer et désactiver les plantages d'App Center lors de l’exécution. Si vous le désactivez, le Kit de développement logiciel (SDK) ne produit aucun rapport d’incident pour l’application.

Crashes.SetEnabledAsync(false);

Pour réactiver App Center Plantages, utilisez la même API, mais passez true en tant que paramètre.

Crashes.SetEnabledAsync(true);

Vous n’avez pas besoin d’attendre cet appel pour effectuer d’autres appels d’API (par IsEnabledAsyncexemple) cohérents.

L’état est conservé dans le stockage de l’appareil dans les lancements d’application.

Vérifier si les blocages d’App Center sont activés

Vous pouvez également vérifier si les crashs d'App Center sont activé ou non.

bool isEnabled = await Crashes.IsEnabledAsync();

Erreurs gérées

App Center vous permet également de suivre les erreurs à l’aide d’exceptions gérées. Pour ce faire, utilisez la TrackError méthode :

try {
    // your code goes here.
} catch (Exception exception) {
    Crashes.TrackError(exception);
}

Une application peut éventuellement attacher des propriétés à un rapport d’erreurs géré pour fournir un contexte supplémentaire. Transmettez les propriétés en tant que dictionnaire de paires clé/valeur (chaînes uniquement) comme indiqué dans l’exemple ci-dessous.

try {
    // your code goes here.
} catch (Exception exception) {
    var properties = new Dictionary<string, string>
    {
        { "Category", "Music" },
        { "Wifi", "On"}
    };
    Crashes.TrackError(exception, properties); 
}

Vous pouvez également ajouter éventuellement des pièces jointes binaires et textuelles à un rapport d’erreur géré. Transmettez les pièces jointes en tant que tableau d’objets ErrorAttachmentLog , comme illustré dans l’exemple ci-dessous.

try {
    // your code goes here.
} catch (Exception exception) {
    var attachments = new ErrorAttachmentLog[]
    {
        ErrorAttachmentLog.AttachmentWithText("Hello world!", "hello.txt"),
        ErrorAttachmentLog.AttachmentWithBinary(Encoding.UTF8.GetBytes("Fake image"), "fake_image.jpeg", "image/jpeg")
    };
    Crashes.TrackError(exception, attachments: attachments);
}