App Center のクラッシュ (UWP/WinUI)
重要
Visual Studio App Center は、2025 年 3 月 31 日に廃止される予定です。 完全に廃止されるまで Visual Studio App Center を引き続き使用できますが、移行を検討できる推奨される代替手段がいくつかあります。
App Center のクラッシュでは、アプリがクラッシュするたびにクラッシュ ログが自動的に生成されます。 ログは最初にデバイスのストレージに書き込まれ、ユーザーがアプリを再度起動すると、クラッシュ レポートが App Center に送信されます。 クラッシュの収集は、ベータ アプリと Windows ストアに送信されたアプリの両方で機能します。 クラッシュ ログには、クラッシュの修正に役立つ重要な情報が含まれています。
App Center SDK では、ハンドルされない .NET 例外によって引き起こされるクラッシュのみが収集されます。 C または C++ を使用する場合など、ネイティブ クラッシュは収集されません。 ただし、C++ がクラッシュしたアプリがある場合は、アップロード クラッシュ API を使用して App Center にアップロードできます。
アプリケーションで SDK をまだ設定していない場合は、はじめにセクションに従います。
注意
現在、UWP/WinUI プラットフォームでのメモリ不足の警告の検出はサポートされていません。
- Visual Studio でコンソールを開きます。 これを行うには、[ツール]> [NuGet パッケージ マネージャー パッケージ マネージャー> コンソール] の順に選択します。
- 次のコマンドを入力します。
Install-Package Microsoft.AppCenter.Crashes
API を使用する前に、適切な名前空間を追加します。
using Microsoft.AppCenter.Crashes;
アプリケーションの コンストラクター に対する次の呼び出しを追加または編集して、クラッシュ モジュールを含めます。
AppCenter.Start("{Your App Secret}", typeof(Crashes));
App Center のクラッシュには、SDK を簡単にテストするためのテスト クラッシュを生成する API が用意されています。 この API は、デバッグ構成とリリース構成をチェックします。 そのため、リリース アプリでは機能しないため、デバッグ時にのみ使用できます。
Crashes.GenerateTestCrash();
App Center のクラッシュには、アプリがクラッシュした場合に備えて詳細情報を提供する 2 つの API があります。
SDK を起動した後は、いつでも、前の起動でアプリがクラッシュした場合にチェックできます。
bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();
これは、クラッシュが発生した後にアプリの動作または UI を調整する場合に便利です。 一部の開発者は、ユーザーに謝るために追加の UI を表示するか、クラッシュが発生した後に連絡を取る方法を選択します。
注意
このメソッドは、開始後 Crashes
にのみ使用する必要があります。常に開始前にが返 false
されます。
アプリが以前にクラッシュした場合は、最後のクラッシュに関する詳細を取得できます。
ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();
注意
このメソッドは、開始後 Crashes
にのみ使用する必要があります。常に開始前にが返 null
されます。
この API には多数のユース ケースがあります。最も一般的なのは、この API を呼び出し、カスタム のクラッシュ デリゲートまたはリスナーを実装するユーザーです。
App Center のクラッシュは、クラッシュ ログを App Center に送信する前と送信する際に、開発者が追加のアクションを実行するためのコールバックを提供します。
注意
App Center が起動直後 に クラッシュする処理を開始するため、 を呼び出す AppCenter.Start()
前にコールバックを設定します。
特定のクラッシュを処理する必要があるかどうかを判断する場合は、このコールバックを設定します。 たとえば、無視するシステム レベルのクラッシュがあり、App Center に送信したくない場合があります。
Crashes.ShouldProcessErrorReport = (ErrorReport report) =>
{
// Check the report in here and return true or false depending on the ErrorReport.
return true;
};
ユーザーのプライバシーが重要な場合は、クラッシュ レポートを App Center に送信する前にユーザーの確認を受け取る必要があります。 SDK は、クラッシュ レポートを送信する前にユーザーの確認を待機するように App Center のクラッシュに指示するコールバックを公開します。
これを行うことを選択した場合は、ユーザーの確認を取得する必要があります。たとえば、ダイアログ プロンプトで次のいずれかのオプションを使用します。 Always Send、 Send、 Don't send。 入力に基づいて、App Center のクラッシュに何をすべきかを伝え、クラッシュはそれに応じて処理されます。
注意
SDK ではこれに対するダイアログが表示されません。アプリは、ユーザーの同意を求めるために独自の UI を提供する必要があります。
注意
ユーザー確認ダイアログが実装されていない場合、アプリは明示的に を呼び出 NotifyUserConfirmation
すべきではありません。クラッシュ モジュールは、ログの送信を暗黙的に処理します。
次のコールバックは、クラッシュを送信する前にユーザーの確認を待機するように SDK に指示する方法を示しています。
Crashes.ShouldAwaitUserConfirmation = () =>
{
// Build your own UI to ask for user consent here. The 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;
};
上記のコールバックで を返した true
場合、アプリは (独自のコードを使用して) ユーザーアクセス許可を取得し、次の API を使用して結果を SDK にメッセージする必要があります。
// 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);
場合によっては、アプリのクラッシュの状態を知りたい場合があります。 一般的なユース ケースは、アプリがクラッシュ レポートを送信していることをユーザーに伝える UI を表示する場合や、起動後にアプリが迅速にクラッシュする場合は、クラッシュ ログを送信できるようにアプリの動作を調整する必要がある場合です。 App Center のクラッシュには、アプリで何が起こっているかを通知するために使用できる 3 つの異なるコールバックが用意されています。
Crashes.SendingErrorReport += (sender, e) =>
{
// Your code, e.g. to present a custom UI.
};
エンドポイントでネットワークの問題や停止が発生し、アプリを再起動した場合は、 SendingErrorReport
プロセスの再起動後に再度トリガーされます。
Crashes.SentErrorReport += (sender, e) =>
{
// Your code, e.g. to hide the custom UI.
};
Crashes.FailedToSendErrorReport += (sender, e) =>
{
// Your code goes here.
};
受信は FailedToSendErrorReport
、 4xx コードなどの回復不可能なエラーが発生した場合を意味します。 たとえば、 401 は が appSecret
間違っていることを意味します。
このコールバックは、ネットワークの問題である場合はトリガーされません。 この場合、SDK は再試行を続けます (また、ネットワーク接続がダウンしている間も再試行を一時停止します)。
クラッシュ レポートにバイナリ添付ファイルとテキスト添付ファイルを追加できます。 SDK によってクラッシュと共に送信され、App Center ポータルで表示されます。 次のコールバックは、以前のアプリケーションの起動から格納されたクラッシュを送信する直前に呼び出されます。 クラッシュが発生しても呼び出されません。 添付ファイルの名前minidump.dmp
がミニダンプ ファイル用に予約されているため、名前が付かないようにしてください。 テキストと画像をクラッシュに添付する方法の例を次に示します。
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")
};
};
注意
サイズ制限は現在 7 MB です。 大きな添付ファイルを送信しようとすると、エラーが発生します。
実行時に App Center のクラッシュを有効または無効にすることができます。 無効にした場合、SDK はアプリのクラッシュ レポートを実行しません。
Crashes.SetEnabledAsync(false);
App Center のクラッシュを再度有効にするには、同じ API を使用しますが、パラメーターとして を渡します true
。
Crashes.SetEnabledAsync(true);
他の API 呼び出し (など IsEnabledAsync
) の整合性を保つには、この呼び出しを待機する必要はありません。
状態は、アプリケーションの起動間でデバイスのストレージに保持されます。
App Center のクラッシュが有効になっているかどうかをチェックすることもできます。
bool isEnabled = await Crashes.IsEnabledAsync();
App Center では、処理された例外を使用してエラーを追跡することもできます。 これを行うには、 メソッドを使用します TrackError
。
try {
// your code goes here.
} catch (Exception exception) {
Crashes.TrackError(exception);
}
アプリは必要に応じて、処理されたエラー レポートにプロパティをアタッチして、さらにコンテキストを提供できます。 次の例に示すように、プロパティをキーと値のペア (文字列のみ) のディクショナリとして渡します。
try {
// your code goes here.
} catch (Exception exception) {
var properties = new Dictionary<string, string>
{
{ "Category", "Music" },
{ "Wifi", "On"}
};
Crashes.TrackError(exception, properties);
}
必要に応じて、処理されたエラー レポートにバイナリ添付ファイルとテキスト添付ファイルを追加することもできます。 次の例に示すように、添付ファイルを オブジェクトの ErrorAttachmentLog
配列として渡します。
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);
}