How to Catch Crashes During QA Before They Reach Players

When a crash slips through QA and hits players at launch, the cost is immediate: one-star reviews, refund requests, and a patch window that compresses everything else on the roadmap. The crash was there during development. It just wasn't caught.

Most teams know this is a risk. The ones that handle it well treat crash detection as a QA infrastructure problem, not a luck problem. They build a workflow that finds crashes before players find them.

This article covers how that pipeline works, what tools support it, and what consistently gets missed in the QA-to-launch handoff.

What Unreal Engine and Unity Give You Out of the Box

Both Unreal Engine and Unity have built-in crash handling. Knowing what each captures, and what it doesn't, tells you what a QA crash workflow needs to add.

Unreal Engine ships with CrashReportClient (CRC), which captures a call stack, engine logs, and system metadata when the game crashes. You can point the uploader URL to your own backend or use Epic's default service. The stack trace tells you where the crash happened in code. That's the floor.

What it doesn't give you is the sequence of actions the player took before the crash occurred. Without that sequence, reproducing the crash depends either on luck or a detailed bug report from the tester, and testers rarely recall or document every step.

Unity captures exceptions in the Editor Console during development. In builds, Unity's crash handler generates a crash dump and a player log. C# managed exceptions are readable. Native crashes are harder to read without symbolication configured manually. Unity Gaming Services includes crash analytics for live builds, but that's production monitoring after the fact, not a QA workflow.

Both engines give you a starting point but don't give you:

• Video or replay of what the player did before the crash
• Automatic deduplication when multiple testers hit the same crash
• A centralized dashboard for triaging crashes by build version and platform
• Cross-platform coverage in a single view

For solo playtests and very early builds, CRC is often enough. Once you have multiple testers across multiple builds and platforms, the volume of raw crash dumps without context becomes a bottleneck.

Options for crash detection during QA

There are four realistic approaches. They sit at different points on the build-vs-buy and narrow-vs-integrated spectrum.

Build your own logging and crash handler:

Add logging around risky systems, set up a custom crash handler that writes a local dump file, and ask testers to send logs after crashes. Works fine for solo development and early builds. Cost: engineering time plus ongoing ops to maintain it.

• Falls apart during playtests with many testers because each report is formatted differently, context is missing, and there's no way to see patterns across sessions without someone manually correlating them.

Sentry:

A general application monitoring platform with first-class support for Unity, Unreal, and Godot. Sentry captures crash events with breadcrumbs (device state, OS events, logs, and custom tags like player health or active weapon at time of crash), tracks release health across player sessions, and recently added console support for Xbox, PS5, and Nintendo Switch. It handles performance monitoring too. Pricing is usage-based with a free tier.

• The tradeoff: Sentry is a general-purpose tool. There's no pre-crash video, no build distribution, and no playtest coordination, so your crash data lives separately from your QA workflow.

BugSplat:

Game-focused crash reporting that groups crashes by root cause rather than the top frame of the stack. This reduces duplicate noise significantly, which matters when many testers hit the same crash from different entry points. Integrates with Unreal, Unity, and custom engines. BugSplat focuses specifically on crash reporting and analysis without the broader build distribution or playtest management workflow. Pricing: free trial, paid plans by volume.

• The limitation is the same as Sentry: it's crash reporting only. Build distribution, QA coordination, and automated test results live in separate tools, so you're still stitching together your own pipeline.

Both tools do crash reporting well. What they don't do: pre-crash video, build distribution, in-game issue reporting, automated Sniff and Smoke tests, or AI-assisted crash analysis. If your QA pipeline needs more than just a crash dashboard or if you want crash data, build delivery, and test results all tied to the same build version ID, you're back to stitching tools together.

That's the gap AccelByte Development Toolkit (ADT) was built to close.

ADT is a game development toolkit that brings build distribution, crash reporting, and playtesting into a single platform. It runs as a desktop app (ADT Hub) for managing and distributing builds, paired with a browser dashboard (ADT Web) for crash triage and build health. It supports Unreal Engine, Unity, and custom C/C++ engines, across Windows, Linux, PS4, PS5, Xbox One, Xbox Series X, and Android.

Crash reporter is where it goes meaningfully further than general-purpose tools with:

• Pre-crash Video Capture: Records 5–30 seconds of gameplay leading up to a crash, providing visual context for reproduction.
• Symbolicated Call Stacks: Automatically maps raw data to human-readable function names and line numbers using symbol files (PDB, dSYM, .psym) via BlackBoxCLI.
• Intelligent Deduplication: Groups identical crashes into a single event with an increasing count to prevent dashboard flooding.
• Comprehensive Contextual Data: Captures hardware specifications (CPU/GPU), OS versions, memory usage, and custom session logs at the time of failure.
• Performance Profiling: Provides frame-by-frame metrics, including GPU and draw times, tied directly to the specific build version.
• Integrated Issue Reporting: Allows testers to submit bug tickets in-game with auto-attached screenshots and logs.
• Jira Connectivity: Enables direct ticket creation to eliminate manual data transfers.
• Automated Testing: Supports Sniff tests (launch verification) and Smoke tests (game state reaching) linked to build version IDs.
• Server-Side Support: Extends crash reporting to Windows and Linux server builds using CLI.

The ADT AI Assistant: No other crash reporting tool offers what ADT's AI Assistant does: When a crash lands, the assistant analyzes the symbolicated stack, session logs, and pre-crash video, then compares it against historical crash data across your builds using callstack frame signatures. It can tell you whether the crash is new or a regression, surface which code changes likely introduced it, and in some cases propose a source-level fix, all without leaving ADT Hub.

How to Set Up Crash Reporting with ADT

Crash reporting works by integrating the ADT SDK into your game, uploading debug symbols via CLI, and distributing builds through ADT Hub so crash events land in a centralized view.

1. Create a namespace. Sign up at accelbyte.io/development-toolkit. A namespace is the workspace that holds your builds, channels, crash data, and access controls. QA partners and external studios get access through their own accounts scoped to the channels you assign them.
2. Integrate the BlackBox SDK. For Unreal Engine, the SDK ships as a plugin — copy the BlackBoxSDK directory into your project's Plugins folder and enable it in project settings. For Unity, add the package through the Unity Package Manager. After initialization, the SDK handles crash capture, the pre-crash video buffer, and symbol resolution.
3. Upload your symbols. Symbolication converts raw memory addresses into function names and line numbers. Use the ADT CLI to upload PDB files (Windows), dSYM bundles (macOS/iOS), or .psym files for Linux. This step belongs in your build pipeline, not in a manual process.
4. Register the build and assign it to a channel. The CLI handles build registration. You assign the build to a version and channel, which controls who sees what. QA testers download builds through ADT Hub. The build that crashed and the crash report in your dashboard reference the same version ID.
5. Set up Sniff and Smoke tests. A Sniff test checks that the build launches and runs without immediately crashing. A Smoke test runs through a defined sequence and posts results as JSON back to ADT against the same build version. Both run automatically in your build pipeline and surface alongside the crash data for that build.
6. Enable crash video capture. In ADT Web, go to Game Settings → Global Crash Configs and toggle on Store Crash Video. Set FPS, keystrokes per second, and video length between 5 and 30 seconds. Higher settings increase processing time — typically up to five minutes for longer videos.
7. Triage from the dashboard. When a crash comes in, ADT surfaces the symbolicated call stack, session log, and pre-crash video together. Jira integration lets you create a ticket directly from the crash report. The AI Assistant analyzes the crash, compares it against historical data across builds, and can propose a source-level fix without leaving ADT Hub.

The full path from crash to actionable Jira ticket takes under five minutes when the pipeline is set up. Without it, the same process involves tracking down which build the tester was on, reconstructing what they were doing, manually correlating logs, and opening a ticket with partial information.

How UNSEEN uses ADT during KEMURI development

UNSEEN is a distributed game studio building KEMURI, a third-person action game. Before ADT, their build delivery ran through Perforce, which was slow for a remote team. External partners had no consistent way to access test builds. Crash reporting was fragmented. After integrating ADT:

• Build download times improved by up to 10x, with Smart Build reducing build sizes by 5–15%
• Crash reports, stack traces, and logs land automatically in one place during playtests
• New builds deploy daily, with testers accessing them through ADT Hub from anywhere
• External partners access builds through scoped channels without Perforce or shared drives

Read the full story here.

Things to Check Before You Launch

Regardless of which tool you use, these issues come up consistently before launch:

• Verify symbolication against your shipping build, not your dev build. Test it explicitly: deploy a shipping binary, trigger a known crash, and confirm the report comes back with function names and line numbers. Raw addresses in production are close to useless for triage.
• Instrument your server builds, not just your client. Studios commonly add crash reporting to the game client and skip the dedicated server. Server crashes matter during QA and after launch. The setup is the same; the CLI flag changes to --platform-name windows-server.
• Scope your QA channels correctly. Crash data from internal QA, external QA partners, and content creators should sit in separate channels. Mixing them makes it hard to attribute a crash to a specific build version or test environment.
• Set a crash-free session rate target before launch, not after. Zero crashes is not a realistic threshold. Decide what percentage of sessions ending without a crash is acceptable, measure it against your QA data in the final sprint, and treat it as a ship gate.
• Run your Smoke test against the release candidate, not your penultimate build. Late-stage changes introduce regressions. The RC needs to pass the same automated test suite as every other build, not just a manual pass by the lead QA engineer.
• Confirm that QA partners are receiving builds through a controlled channel. Builds distributed through Slack, email, or shared drives bypass versioning. If a crash comes in from an informally distributed build, you cannot reliably tie it back to the right changelist.
• Check crash report uploads on console devkits separately. Console crash reporting has platform-specific steps: PDB upload for Xbox, symbol handling for PlayStation. These differ from PC setup and need to be tested independently.

Get Started for Free

If you're heading into QA or active playtesting, crash detection is the one piece of infrastructure that pays off immediately. ADT gives you pre-crash video, symbolicated call stacks, automatic deduplication, and build distribution in the same tool. The free trial gives you 30 days to run real playtests and catch real crashes before billing starts.

Get Started for Free → or Talk to Us →