Mobile: Group crashes tab

Frequent mobile app crashes degrade the user experience and cause delays in the development lifecycle. The Group crashes page is designed to help your development team deliver a more stable and reliable mobile app experience to your users.

With the Group crashes page you can:

• Assess overall crash trends: Review the Crash rate percentage and Crash-free users percentage charts to quickly identify any anomalies or patterns in crash occurrences.
• Filter for deeper analysis: Utilize groups and filters to focus on specific crash attributes, such as device type, location, or custom data points.
• Identify patterns: Examine the Crash location table for trends related to location, exception type, date, frequency, app version, and the number of affected users.
• Investigate individual crashes: Select a crash report to view its interaction trail, event trail, thread details, attributes, and other relevant information. You can also resymbolicate or export the details to Xcode for debugging.
• Update crash status: Mark the crash as Resolved or choose from other status options, such as Resolved in specific version.

Suggested workflow

These steps outline our recommended approach to crash investigation, enabling you to gain a complete understanding of the incident, identify contributing factors, and implement effective debugging strategies.

Crash percentages charts: See patterns immediately

Start with the Crash rate percentage and Crash-free users percentage charts to see at a glance whether there are any unexpected spikes, dips, or patterns with crashes in general. For example:

• Are there any spikes near a recent version release?
• Is there a period when the percentage of users has been affected significantly by the crash? (If the Crash-free users percentage chart is empty, there were no user sessions during the selected period.)

Groups and filters: Slice and dice the crash data

You can select a group and then filter to specific data, including:

• Group the crash list by type of crash, device, location, or other custom attributes.

• Show open crashes, resolved crashes, or all crashes.

• Use the time picker to adjust the currently selected period.

• Filter by a specific Version or by one or more attribute Filter, such as Last Interaction, App Build, or any of the longer list of standard and custom attributes.)

  The selected filters appear at the top of the UI page.

Queries and image links: Query crash data and share charts with others

Mobile monitoring's Crash analysis charts use default attributes for mobile events, along with any custom attributes you have added to this event type. To view or share the data, click the ellipsis icon.

• Add to dashboard link: View the chart, and copy it to a new or existing dashboard.
• View query link: View the NRQL query used to calculate the chart data.
• Get as image link: Select this option to get a public URL of the chart, then share it using any media.

Crash profiles: Quickly see key differences between crashed and crash-free accounts

Crash profiles provide quick, clear insight into your mobile crash data by surfacing anomalies in your mobile application's performance. Unexpected differences between attributes and behaviors are highlighted, illuminating key differences between crashed and crash-free accounts. You can quickly pinpoint key issues through drill-downs and filters for a fast, streamlined troubleshooting experience.

Crash event trail: See all the events leading up to a crash

The mobile monitoring crash event trail shows you the events leading up to a crash of a mobile app. These can be events monitored by default or by custom events you've created. For more information, see Crash event trail.

Examine crash report details: Export to Xcode or resymbolicate your source code

From the Crash types table, you can drill down into a specific crash type. From here, you can:

• Explore the related thread breakdown.

• Select Export crash details so you can examine source code using Xcode.

• Click the View crash libraries button to see what Android map files or iOS .dSYM files we have for your application.

• If you don't see the files you're expecting, upload a new Android map file or iOS .dSYM files by clicking on the Upload link. Note that uploading a new file automatically de-obfuscates or symbolicate your crash occurrence.

• File a ticket and resolve the crash.

  

Crashes details view

The Crash summary panel includes:

• Occurrences chart: Visualizes the frequency of this specific crash over the selected period since its initial detection. If multiple occurrences are recorded, you can navigate through each instance.
• Crash type breakdown : Displays the distribution of this crash across different operating system versions or affected devices.

Resolved crashes are indicated by a banner that shows the user who resolved the crash and the resolution timestamp. Note that mobile monitoring's data retention policies apply, allowing you to filter by resolved crashes for historical analysis when needed.

Triage your crashes

The triage section associates the specific error occurrence you're viewing with its system-created error group. These system-created error groups are identified by a unique fingerprint. It is this unique fingerprint that allows you to triage error groups by status updates or assignments.

For more info on how error groups are created, see How error groups work, and to learn more about status and assignments, see Error tracking.

Crash attributes

Each crash sample provides detailed information about the device environment where the crash occurred, including:

• App version: The specific version of the application in which the crash occurred.
• Device type: The model of the device on which the crash occurred.
• OS version: The operating system version running on the device.
• RAM used: The amount of memory the application was utilizing at the time of the crash.
• Disk free: The amount of available storage space on the device when the crash happened.
• Attributes: Detailed attributes associated with the crash report, offering deeper insights into the context of the crash.

You can export crash details to Xcode or resymbolicate your source code, if applicable, to streamline the troubleshooting process.

Event trail

The event trail provides a chronological log of all mobile events leading up to a crash, aiding root cause analysis. These can be events New Relic monitors by default, or custom events. The event trail is sorted chronologically, beginning with the oldest event, which is typically the app launch, but you can modify the following:

• Sort: Toggle between ascending and descending order.
• Event filtering: Filter by event type, like interaction, request, or request error.
• Event details: Expand individual events to inspect their attributes, like responseTime,or requestUrl for request events.

After you've sorted and filtered your events, you can dig a little deeper into the events that lead up to the crash by examining:

• Custom breadcrumbs: Utilize the Record breadcrumb SDK to create custom MobileBreadcrumb events. This allows you to log specific application interactions that may be relevant to crash analysis.
• Handled exceptions: Use the recordHandledException SDK methods for iOS and Android to annotate where exceptions are handled in your application. These annotations will automatically populate the crash event trail.

For detailed guidance on enhancing crash event trails with custom data, see Record breadcrumbs.

To fully leverage our crash analysis tools, make sure to:

• Use the mobile SDK to create custom MobileBreadcrumb or MobileHandledException events.
• Enable MobileRequest events for capturing network request data.

Mobile stack trace

The stack trace for each crash is displayed beneath the crash details. Each frame within the stack shows the associated library or package name, and method. For each crash, the mobile agent attempts to detect the specific stack frame containing the programming error responsible for the crash. If successfully detected, that stack frame appears red.

• iOS apps: Source code method names and line numbers are visible if you have uploaded the corresponding dSYM files for each build.
• Android apps using ProGuard: Package and method names will be de-obfuscated if ProGuard map uploading is enabled.
• Android native crash reports: These reports will only display source filenames and relative code offsets.

You can use email alerts to promptly respond to new crashes.

Android-native crash reporting

New Relic Android agent version 6.7.0, introduced enhancements to help track and diagnose native crashes, reporting, and analysis. These enhancements include signal violations and other faults that occur at the native code level during runtime.

These enhancements include:

• Native crash reports: Signal violations and other crashes reported by the app during runtime, including:

  • Signal 4: Illegal instruction
  • Signal 6: Abnormal termination
  • Signal 7: Bus error/bad memory access
  • Signal 8: Floating-point exception
  • Signal 1: Segmentation violation/invalid memory reference

• Native runtime exceptions: The native agent will report any unhandled C++ exceptions thrown by the app during runtime, and report them as handled exceptions. Unhandled exceptions are usually fatal and will crash the application.

You can view detailed information about native crashes in New Relic Mobile's Crash analysis UI, or receive crash notifications by email. You can also explore the crash data deeper with New Relic Insights, or integrate with ticketing systems for further investigation.

Troubleshooting

Keep in mind that profiles are disabled when there are no statistically significant differences between attributes values of crashed and crash-free sessions or there are no profiles available that match the applied filters.