Error details

The IMQA Crash error details page enables you to analyze how many errors have occurred in a specific app version and the user environment the error mainly occurred in. You can check call stacks and error occurrence paths, and the administrator can attach a tag on the error in question, and record and check the handling process.

1. Overview

You can open this page if you click on a specific error on the “Dashboard” or “Error search”, and the IMQA Crash error details page is composed of the following information.

❶ Error information ❷ Error frequency ❸ User information ❹ Performance information ❺ Tags ❻ Call stack/Instance/Bread crumbs

2. Error information

You can view error information and cumulative count, and the administrator can record and check the handling process.

Crash

❶ Error information Displays the error name, class name, and code line number that the error occurred.

If an error occurs in the latest app version, the ProGuard setting is required for the corresponding version to view the decrypted crash information. For details of ProGuard settings, please refer to “Using Crash > Project management > ProGuard settings”.

❷ Status You can change the error handling status after checking the person in charge. If you click this button, options will be displayed that allow you to change the status. The criteria of changing the status is not determined separately, and the administrator can set it as follows at the discretion of the administrator.

• New: If the error has newly occurred.

• Open: If the person in charge has identified the cause and is handling the error.

• Fixed: If the person in charge has completed handling.

• Close: If the administrator finishes the handling of the error in question after checking.

If the status was changed for an error, the status will not be changed separately even if the same error occurs in the same version or lower version. However, if the same error occurs in the higher version, a new error record is created to distinguish it from the error in question.

❸ Latest version/Count Displays the latest app version among occurred errors and the cumulative count of the error in question.

Web Crash

❶ Caught Error Instance Type Displays the name of the caught error instance of the error if it is generated on a web page.

❷ Custom Error Message Displays a user-specified message when a specific error-type error is generated.

throw new Error("Custom error messages");

You can collect the default error message collected by WebView by changing it to the desired error message. We recommend specifying an error message for detailed web error analysis. For more information about specifying an error message, refer to ‘Setting Crash SDK > Custom Web Crash > Custom Error Messages’

❸ Error Type / Error Line Number You can check the type of webview error and the line number of the error.

Error-type	Description
Error	This is the error type set by the user.
EvalError	This error occurs in eval().
RangeError	This error is generated when a variable is outside its valid range.
ReferenceError	This error occurs when an incorrect reference is made.
SyntaxError	It is an error if incorrect syntax exists.
TypeError	If it is not a valid data type, it is a type error.
URIError	This error is generated when inappropriate parameters are passed to the encodeURI() or decodeURI() functions.
AggregateError	This is a type of error that wraps multiple errors into one error.

3. Error frequency

Displays how many times the error has occurred in a specific app version for the last week. You can check the error occurrence trend and the ratio by app version.

• Error occurrence ratio by app version: Allocates the daily error count for the last week to each app version.

The Y-axis refers to the error count. It is easy to understand whether the error in question has also occurred in the latest version after handling it.

In addition, if the error count increased dramatically on a specific date, check which app version has caused the error. If errors continue to occur in a specific app version, you may recommend updates to the user of the app version in question.

4. User information

Displays how many times the error has occurred in a specific user environment for the last week.

• Wi-Fi/ Carrier: Displays the network environment of the user where the error occurred. Errors can be checked by the Wi-Fi environment and carrier.

• GPS: Displays the GPS status of the user where the error occurred. The GPS status is classified into “On” and “Off”.

• App version: Displays the app version of the user where the error occurred.

• OS version: Displays the OS version of the user where the error occurred.

• Device: Displays the device of the user where the error occurred.

“Unknown Device” means the device information was not collected. An example of this is a case where a device, such as Mac, was tested with a simulator.

• Country: Displays the country of the user where the error occurred.

The individual user environment can be checked using the “Error Details > Instance > Details” menu.

5. Performance information

Displays average resource usage when the error occurred.

• CPU usage: Displays the average CPU usage in percentage when the error occurred.

• Memory usage: Displays the average memory usage in “MB” when the error occurred.

The individual user resource usage can be checked using the “Error Details > Instance > Details” menu.

6. Tags

You can manage additional information about the error freely using a tag. You can also set a tag when you set the type and rank of errors using the SDK. Refer to “Android > Setting Crash SDK > Custom crash occurrence”.

1. Input a desired tag name for the tag and click the [+] icon.

2. The entered tag will be displayed in the empty area below. Click the [X] icon to delete the tag.

The entered tag can be used as a search word in the “Error search” page. You can manage tags with the target user environment of the app and use the tag to record the occurrence situation, high resource usage, etc. However, you cannot enter a tag with the same name for one error.

7. Call stack/Instance/Bread crumbs

You can check crash occurrence stack information and the stack of all threads. You can also analyze detailed user information and bread crumbs.

Call stack

You can check the cause and location of occurrence by checking crash occurrence stack information and the stack of all threads. The information related to the stack can be downloaded as a file and shared with other members.

❶ Stack filter The stack filter shows basic crash information at the top and enables you to select another stack information so that the error occurred in other thread call stacks can be checked.

❷ Crash occurrence stack Displays the upper stack line in crash stack information.

❸ All stacks Displays the stack information of all threads. You can refer to this information when analyzing the cause of errors more accurately.

❹ Download Raw File The information related to the stack can be downloaded as a *.txt, file and shared with other members. If you click [Download Raw File], the “stacktrace.txt” file is saved in the “Download” folder.

Instance

You can view the information on the user who experienced the crash. You can view the LogCat (detailed log information) and screen breadcrumbs of individual users, and detailed information on the user environment.

❶ User information Displays the IP address, app version, device, and country information of individual users, and LogCat, bread crumbs, and detailed information can be checked on a pop-up window.

❷ LogCat *For Android app only For Android apps, you can check LogCat information. If you click LogCat [view] on the individual user item, the LogCat information pop-up window will be displayed.

LogCat refers to the detailed log information of Android and shows the log information recorded before crash occurrence, which can be used to analyze the problem that cannot be analyzed using error stack information.

❸ Bread crumbs If you click Bread Crumbs [view] on the individual user item, the Bread Crumbs information pop-up window will be displayed.

❹ Details You can check the user's environment information in details, such as the device, app information, and OS. If you click Details [view] on the individual user item, the Details information pop-up window will be displayed.

• User information: Displays the name, unique ID, IP address, e-mail address of the user in question.

User information displays the name, unique ID, IP address, e-mail address only when data is provided using the API provided by the SDK separately.

• Device: Displays information about the device of the user in question.

• App information: Displays information on the user in question, such as app launch start time, version, etc.

• Operating system: Displays the platform, OS version, rooted status, etc.

• SDK: Displays the version of the IMQA SDK installed in the app of the user in question.

• Custom logs: Displays log information provided when sending log information using the API, which is separately provided by the SDK.

• Custom keys: Displays the key/value information provided when sending key/value information using the API, which is separately provided by the SDK.

Bread crumbs

You can check the event path that the user has taken, who experienced the crash.

A Sankey diagram is useful to find the most major and important flow in the overall flow. You can visually check the major event of the user until the error occurred. If you place the mouse pointer over the area between screens, a tooltip is displayed as “Activity: Event → Activity: Event: Count”.

• Count: Counts the number of users who moved from a specific screen to a specific screen.

If a specific path to the point of error occurrence is strongly emphasized, it can be understood that many users moving to that path are experiencing problems. If that path is the target path of the app, it means that the problem should be solved quickly.