App Center のクラッシュ (UWP/WinUI)

App Center のクラッシュでは、アプリがクラッシュするたびにクラッシュ ログが自動的に生成されます。 ログは最初にデバイスのストレージに書き込まれ、ユーザーがアプリを再度起動すると、クラッシュ レポートが App Center に送信されます。 クラッシュの収集は、ベータ アプリと Windows ストアに送信されたアプリの両方で機能します。 クラッシュ ログには、クラッシュの修正に役立つ重要な情報が含まれています。

App Center SDK では、ハンドルされない .NET 例外によって引き起こされるクラッシュのみが収集されます。 C または C++ を使用する場合など、ネイティブ クラッシュは収集されません。 ただし、C++ がクラッシュしたアプリがある場合は、アップロード クラッシュ API を使用して App Center にアップロードできます。

アプリケーションで SDK をまだ設定していない場合は、はじめにセクションに従います。

クラッシュ モジュールの追加

パッケージ マネージャー コンソール

• Visual Studio でコンソールを開きます。 これを行うには、[ツール]> [NuGet パッケージ マネージャー パッケージ マネージャー> コンソール] の順に選択します。
• 次のコマンドを入力します。

Install-Package Microsoft.AppCenter.Crashes

using ステートメントを追加する

API を使用する前に、適切な名前空間を追加します。

using Microsoft.AppCenter.Crashes;

メソッドを変更するStart()

アプリケーションの コンストラクター に対する次の呼び出しを追加または編集して、クラッシュ モジュールを含めます。

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 を表示するか、クラッシュが発生した後に連絡を取る方法を選択します。

前回のクラッシュの詳細

アプリが以前にクラッシュした場合は、最後のクラッシュに関する詳細を取得できます。

ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();

この API には多数のユース ケースがあります。最も一般的なのは、この API を呼び出し、カスタム のクラッシュ デリゲートまたはリスナーを実装するユーザーです。

App Center のクラッシュの使用をカスタマイズする

App Center のクラッシュは、クラッシュ ログを App Center に送信する前と送信する際に、開発者が追加のアクションを実行するためのコールバックを提供します。

クラッシュを処理する必要がありますか?

特定のクラッシュを処理する必要があるかどうかを判断する場合は、このコールバックを設定します。 たとえば、無視するシステム レベルのクラッシュがあり、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 に指示する方法を示しています。

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 つの異なるコールバックが用意されています。

SDK がクラッシュ ログを送信する前に、次のコールバックが呼び出されます

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

エンドポイントでネットワークの問題や停止が発生し、アプリを再起動した場合は、 SendingErrorReport プロセスの再起動後に再度トリガーされます。

SDK がクラッシュ ログを正常に送信した後、次のコールバックが呼び出されます

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

SDK がクラッシュ ログの送信に失敗した場合は、次のコールバックが呼び出されます

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")
    };
};

実行時に App Center のクラッシュを有効または無効にする

実行時に App Center のクラッシュを有効または無効にすることができます。 無効にした場合、SDK はアプリのクラッシュ レポートを実行しません。

Crashes.SetEnabledAsync(false);

App Center のクラッシュを再度有効にするには、同じ API を使用しますが、パラメーターとして を渡します true 。

Crashes.SetEnabledAsync(true);

他の API 呼び出し (など IsEnabledAsync) の整合性を保つには、この呼び出しを待機する必要はありません。

状態は、アプリケーションの起動間でデバイスのストレージに保持されます。

App Center のクラッシュが有効になっているかどうかを確認する

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);
}