App Center のクラッシュ (Windows)

重要

Visual Studio App Center は、2025 年 3 月 31 日に廃止される予定です。 完全に廃止されるまで Visual Studio App Center を引き続き使用できますが、移行を検討できる推奨される代替手段がいくつかあります。

詳細については、サポートタイムラインと代替手段に関するページを参照してください。

• Android
• iOS
• MAUI/Xamarin
• UWP
• WPF/WinForms
• React Native
• macOS
• tvOS
• Unity
• Cordova

App Center のクラッシュでは、アプリがクラッシュするたびにクラッシュ ログが自動的に生成されます。 ログは最初にデバイスのストレージに書き込まれ、ユーザーがアプリを再度起動すると、クラッシュ レポートが App Center に送信されます。

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

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

WinForms アプリケーションでのハンドルされない例外

注意

このセクションと以下のサブセクションは、WinForms にのみ適用されます。 SDK を WPF に統合する場合は、このセクションをスキップできます。

既定では、デバッガーがアタッチされていない場合、WinForms アプリケーションのハンドルされない例外によってクラッシュがトリガーされることはありません (アプリケーションは終了しません)。

代わりに、Windows には、アプリの実行を続行または終了するオプションがユーザーに表示されます。 そのため、App Center SDK では、(ユーザーが [終了 ] ボタンをクリックした場合でも) これらの例外を自動的にキャプチャすることはできません。

クラッシュは、アプリケーションが自動的に終了する場合にのみ、App Center で収集されます。 App Center では、セッションごとに 1 つのクラッシュのみがサポートされます。

WinForms でハンドルされない例外を報告するには、2 つの方法があります。 アプリケーションは、未処理の例外でクラッシュするように構成することも、実行を続行するが、未処理の例外を実行時エラーとして報告するように構成することもできます。

クラッシュ時に終了するようにアプリケーションを構成する

これは、App Center でハンドルされない例外を クラッシュ として報告し、未処理の例外でアプリケーションを終了させる唯一の方法です。

これを行うには、SDK を初期化する前に Windows メソッドを呼び出します。

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

このオプションがアプリケーションで受け入れられない場合は、未処理の例外をランタイム エラーとして報告できます (後述)。

未処理の例外をランタイム エラーとして報告する

未処理の例外の後もアプリケーションを実行し続ける必要がある場合は、App Center で例外を クラッシュ として報告することはできませんが、代わりに エラーとして報告できます。

これを行うには、次のコード サンプルを使用できます。

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

注意

デバッガーがアタッチされている場合、ハンドラーが にアタッチApplication.ThreadExceptionされていない限り、ハンドルされない例外によってアプリケーションが終了 (クラッシュ) します。

テスト クラッシュを生成する

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 に送信する前と送信する際に、開発者が追加のアクションを実行するためのコールバックを提供します。

注意

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 すべきではありません。Crashes モジュールは、ログの送信を暗黙的に処理します。

次のコールバックは、クラッシュを送信する前にユーザーの確認を待機するように SDK に指示する方法を示しています。

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

上記のコールバックで を返す 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")
    };
};

注意

現在、サイズ制限は 7 MB です。 より大きな添付ファイルを送信しようとすると、エラーが発生します。

実行時に 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);
}