Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Von Bedeutung
Visual Studio App Center wurde am 31. März 2025 eingestellt, mit Ausnahme der Analyse- und Diagnosefeatures, die bis zum 30. Juni 2026 weiterhin unterstützt werden. Weitere Informationen
App Center-Abstürze generieren automatisch ein Absturzprotokoll jedes Mal, wenn Ihre App abstürzt. Das Protokoll wird zuerst in den Speicher des Geräts geschrieben und wenn der Benutzer die App erneut startet, wird der Absturzbericht an das App Center gesendet. Das Sammeln von Abstürze funktioniert sowohl für Beta- als auch für Live-Apps, d. h. für an den App Store übermittelte Apps. Absturzprotokolle enthalten wertvolle Informationen für Sie, um den Absturz zu beheben.
Folgen Sie dem Abschnitt " Erste Schritte ", wenn Sie das SDK noch nicht in Ihrer Anwendung eingerichtet haben.
Außerdem benötigen Absturzprotokolle unter iOS eine Symbolisierung. Sehen Sie sich die App Center-Diagnosedokumentation an, in der erläutert wird, wie Symbole für Ihre App bereitgestellt werden.
Hinweis
Unter iOS und Mac speichert das SDK keine Absturzprotokolle, wenn Sie einen Debugger angefügt haben. Stellen Sie sicher, dass der Debugger nicht angeschlossen ist, wenn die iOS- und macOS-App abstürzt. Unter Android kann es zu einem Absturz kommen, wenn der Debugger angefügt ist, aber Sie müssen die Ausführung nach dem Auftreten einer unbehandelten Ausnahme fortsetzen.
Generieren eines Testabsturzes
App Center Crashes bietet Ihnen eine API zum Generieren eines Testabsturzes für einfache Tests des SDK. Diese API sucht nach Debug- und Releasekonfigurationen. Sie können es also nur verwenden, wenn Sie debuggen, da es nicht für release-Apps funktioniert.
Crashes.GenerateTestCrash();
Abrufen weiterer Informationen zu einem vorherigen Absturz
App Center Crashes bietet zwei APIs, mit denen Sie weitere Informationen erhalten, falls Ihre App abgestürzt ist.
Hat die App in der vorherigen Sitzung eine Warnung mit geringem Arbeitsspeicher erhalten?
Nach dem Starten des SDK können Sie jederzeit überprüfen, ob die App in der vorherigen Sitzung eine Speicherwarnung erhalten hat:
bool hadMemoryWarning = await Crashes.HasReceivedMemoryWarningInLastSessionAsync();
Hinweis
Diese Methode darf nur verwendet werden, nachdem Crashes
gestartet wurde; vor dem Start wird aber immer false
zurückgegeben.
Hinweis
In einigen Fällen kann ein Gerät mit geringem Arbeitsspeicher keine Ereignisse senden.
Stürzte die App in der vorherigen Sitzung ab?
Nach dem Starten des SDK können Sie jederzeit überprüfen, ob die App beim vorherigen Start abgestürzt ist:
bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();
Dies ist praktisch, wenn Sie das Verhalten oder die Benutzeroberfläche Ihrer App nach dem Absturz anpassen möchten. Einige Entwickler entscheiden sich, zusätzliche Benutzeroberflächen anzuzeigen, um sich bei ihren Benutzern zu entschuldigen oder um nach einem Absturz Kontakt aufnehmen zu können.
Hinweis
Diese Methode darf nur verwendet werden, nachdem Crashes
gestartet wurde; vor dem Start wird aber immer false
zurückgegeben.
Details zum letzten Absturz
Wenn Ihre App zuvor abgestürzt ist, können Sie Details zum letzten Absturz abrufen.
ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();
Hinweis
Diese Methode darf nur verwendet werden, nachdem Crashes
gestartet wurde; vor dem Start wird aber immer null
zurückgegeben.
Für diese API gibt es zahlreiche Anwendungsfälle, der am häufigsten ist der Aufruf dieser API durch Personen, die ihren benutzerdefinierten Crashes Delegate oder Listener implementieren.
Passen Sie die Nutzung von App Center Crashes an.
App Center-Abstürze bieten Entwicklern Rückrufe, um zusätzliche Aktionen vor und beim Senden von Absturzprotokollen an App Center auszuführen.
Hinweis
Legen Sie den Rückruf vor dem Aufruf von AppCenter.Start()
fest, da App Center unmittelbar nach dem Start mit der Verarbeitung von Abstürzen beginnt.
Sollte der Absturz verarbeitet werden?
Legen Sie diesen Rückruf fest, wenn Sie entscheiden möchten, ob ein bestimmter Absturz verarbeitet werden muss oder nicht. Es könnte zum Beispiel einen Absturz auf Systemebene geben, den Sie ignorieren möchten und nicht an das App Center senden wollen.
Crashes.ShouldProcessErrorReport = (ErrorReport report) =>
{
// Check the report in here and return true or false depending on the ErrorReport.
return true;
};
Anfordern der Zustimmung des Benutzers zum Senden eines Absturzprotokolls
Wenn Ihnen der Datenschutz des Benutzers wichtig ist, sollten Sie die Benutzerbestätigung erhalten, bevor Sie einen Absturzbericht an das App Center senden. Das SDK stellt eine Callback-Funktion bereit, die App Center Crashes angewiesen ist, auf die Bestätigung des Benutzers zu warten, bevor Absturzberichte gesendet werden.
Wenn Sie dies tun, sind Sie dafür verantwortlich, die Bestätigung des Benutzers zu erhalten, z. B. über eine Dialogfeldaufforderung mit einer der folgenden Optionen: Immer senden, senden und nicht senden. Basierend auf der Eingabe geben Sie App Center Crashes Anweisungen, und der Absturz wird dann entsprechend behandelt.
Hinweis
Das SDK zeigt hierfür kein Dialogfeld an, die App muss eine eigene Benutzeroberfläche bereitstellen, um die Zustimmung des Benutzers zu verlangen.
Hinweis
Die App sollte nicht explizit aufgerufen werden NotifyUserConfirmation
, wenn es kein Benutzerbestätigungsdialogfeld implementiert. Das Absturzmodul behandelt implizit das Senden von Protokollen für Sie.
Der folgende Rückruf zeigt, wie Sie dem SDK mitteilen, dass vor dem Senden von Abstürze auf die Benutzerbestätigung gewartet wird:
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;
};
Falls Sie im obigen Rückruf zurückkehren true
, muss Ihre App die Benutzerberechtigung (mit Ihrem eigenen Code) abrufen und das SDK mit dem Ergebnis mithilfe der folgenden API benachrichtigen.
// 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);
Als Beispiel können Sie auf unser benutzerdefiniertes Dialogfeldbeispiel verweisen.
Abrufen von Informationen zum Sendestatus für ein Absturzprotokoll
Manchmal möchten Sie den Status ihres App-Absturzes kennen. Ein gängiger Anwendungsfall besteht darin, dass Sie die Benutzeroberfläche anzeigen möchten, die den Benutzern sagt, dass Ihre App einen Absturzbericht übermittelt, oder falls ihre App nach dem Start schnell abstürzt, möchten Sie das Verhalten der App anpassen, um sicherzustellen, dass die Absturzprotokolle übermittelt werden können. App Center Crashes bietet drei verschiedene Callbacks, die Sie in Ihrer App verwenden können, um über die Vorgänge benachrichtigt zu werden:
Der folgende Rückruf wird aufgerufen, bevor das SDK ein Absturzprotokoll sendet.
Crashes.SendingErrorReport += (sender, e) =>
{
// Your code, e.g. to present a custom UI.
};
Falls Netzwerkprobleme oder ein Ausfall auf dem Endpunkt auftreten und Sie die App neu starten, SendingErrorReport
wird nach dem Neustart des Prozesses erneut ausgelöst.
Der folgende Rückruf wird aufgerufen, nachdem das SDK erfolgreich ein Absturzprotokoll gesendet hat.
Crashes.SentErrorReport += (sender, e) =>
{
// Your code, e.g. to hide the custom UI.
};
Der folgende Rückruf wird aufgerufen, wenn das SDK ein Absturzprotokoll nicht senden konnte.
Crashes.FailedToSendErrorReport += (sender, e) =>
{
// Your code goes here.
};
FailedToSendErrorReport
Der Empfang bedeutet, dass ein nicht wiederherstellbarer Fehler wie z. B. ein 4xx-Code aufgetreten ist.
Beispielsweise bedeutet 401, dass das appSecret
falsch ist.
Dieser Rückruf wird nicht ausgelöst, wenn es sich um ein Netzwerkproblem handelt. In diesem Fall führt das SDK fortlaufend Wiederholungen durch (und unterbricht diese, während die Netzwerkverbindung unterbrochen ist).
Hinzufügen von Anlagen zu einem Absturzbericht
Sie können einem Absturzbericht Binärdateien und Textdateien hinzufügen. Das SDK sendet sie zusammen mit dem kritischen Fehler, damit Sie sie im App Center Portal sehen können. Der folgende Rückruf wird direkt vor dem Senden des gespeicherten Absturzes von vorherigen Anwendungsstarts aufgerufen. Er wird nicht aufgerufen, wenn der Absturz auftritt. Stellen Sie sicher, dass die Anlagendatei nichtminidump.dmp
genannt wird, da dieser Name für Minidumpdateien reserviert ist. Hier ist ein Beispiel für das Anfügen von Text und einem Bild an einen Absturz:
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")
};
};
Hinweis
Die Größenbeschränkung beträgt derzeit 7 MB. Beim Versuch, eine größere Anlage zu senden, wird ein Fehler ausgelöst.
Aktivieren oder Deaktivieren von App Center-Abstürzen zur Laufzeit
Sie können App Center-Abstürze zur Laufzeit aktivieren und deaktivieren. Wenn Sie sie deaktivieren, wird im SDK keine Absturzberichterstattung für die App ausgeführt.
Crashes.SetEnabledAsync(false);
Um App Center-Abstürze erneut zu aktivieren, verwenden Sie dieselbe API, indem Sie true
als Parameter übergeben.
Crashes.SetEnabledAsync(true);
Sie müssen diesen Aufruf nicht warten, um andere API-Aufrufe (z IsEnabledAsync
. B. ) konsistent zu machen.
Der Zustand wird im Speicher des Geräts über Anwendungsstarts hinweg beibehalten.
Hinweis
Diese Methode darf nur verwendet werden, nachdem Crashes
gestartet wurde.
Überprüfen, ob App Center Crashes aktiviert ist
Sie können auch überprüfen, ob App Center Crashes aktiviert ist oder nicht:
bool isEnabled = await Crashes.IsEnabledAsync();
Hinweis
Diese Methode darf nur verwendet werden, nachdem Crashes
gestartet wurde; vor dem Start wird aber immer false
zurückgegeben.
Behandelte Fehler
App Center ermöglicht ihnen auch das Nachverfolgen von Fehlern mithilfe von behandelten Ausnahmen. Verwenden Sie dazu die TrackError
Methode:
try {
// your code goes here.
} catch (Exception exception) {
Crashes.TrackError(exception);
}
Eine App kann optional Eigenschaften an einen behandelten Fehlerbericht anfügen, um weiteren Kontext bereitzustellen. Übergeben Sie die Eigenschaften als Wörterbuch mit Schlüssel-Wert-Paaren (nur Zeichenfolgen), wie im folgenden Beispiel gezeigt.
try {
// your code goes here.
} catch (Exception exception) {
var properties = new Dictionary<string, string>
{
{ "Category", "Music" },
{ "Wifi", "On"}
};
Crashes.TrackError(exception, properties);
}
Sie können einem behandelten Fehlerbericht optional auch Binäre und Textanlagen hinzufügen. Übergeben Sie die Anhänge als Array von ErrorAttachmentLog
Objekten, wie im folgenden Beispiel gezeigt.
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);
}