How do console platforms handle crash reporting differently?

Console platforms (Xbox, PlayStation, Nintendo Switch) each have proprietary crash reporting systems accessible through their developer portals. They collect crash dumps automatically from players and provide pre-symbolicated reports when you upload debug symbols. You cannot install custom crash reporters on consoles, so you must integrate with each platform's native system and pull the data into your unified dashboard via their APIs or manual exports.

What metadata should I collect alongside crash logs for cross-platform games?

Essential metadata includes the platform and OS version, device model and hardware specs (CPU, GPU, RAM), game version and build number, the scene or level the player was in, graphics API in use (DirectX, Vulkan, Metal, OpenGL), driver versions for GPU crashes, and the player's language and region. This metadata helps you identify platform-specific patterns and reproduce crashes on the right hardware.

Cross-Platform Crash Log Collection for Games

Quick answer: Each platform has its own crash format: Windows uses minidumps, macOS uses .crash files, Linux uses core dumps, Android uses tombstones, and iOS uses .ips files. Without a unified pipeline, you have to check multiple dashboards and use different tools for each platform.

This guide covers cross platform crash log collection for games in detail. Shipping a game on multiple platforms means collecting crash data from multiple platforms, each with its own format, its own tools, and its own quirks. Without a unified collection pipeline, you end up checking five different dashboards and using five different debuggers. This guide covers how crash data works on each major platform and how to bring it all together into a single view.

The Platform Landscape

Every platform your game runs on produces crash data in a different format. Understanding these differences is the first step to building a unified pipeline:

Windows produces minidump files (.dmp) through the Windows Error Reporting system or a custom crash handler like Crashpad. Minidumps contain thread stacks, register states, loaded modules, and exception information. They are symbolicated using PDB files and analyzed with WinDbg or Visual Studio.

macOS generates .crash or .ips files through the system crash reporter. These contain partially symbolicated stack traces and system metadata. Full symbolication requires dSYM bundles and the atos or symbolicatecrash tools.

Linux produces core dumps by default, but these are too large for network transfer. Games on Linux should use Crashpad or Breakpad to generate Minidump-format files instead. Symbolication uses the unstripped ELF binary or separated DWARF debug info.

Android captures both Java exceptions (via the standard exception handler) and native crashes (tombstones). Native crashes require the unstripped .so files for symbolication using ndk-stack or addr2line. The Google Play Console collects both types automatically.

iOS crash reports are collected by Apple's crash reporter and made available through Xcode Organizer or App Store Connect. dSYM bundles are required for symbolication. Apple also provides MetricKit for collecting diagnostic data programmatically.

Console Platforms

Consoles present a unique challenge because you cannot install custom crash reporters. Each platform provides its own crash collection infrastructure:

Xbox uses the Watson crash reporting system through Partner Center. Upload your PDB files to the Partner Center dashboard, and crashes are symbolicated server-side. You can download crash dumps for local analysis with WinDbg.

PlayStation provides crash dumps through the PlayStation Partners portal. The format is proprietary, and analysis tools are provided under NDA. Symbol files are uploaded through the developer portal for automatic symbolication.

Nintendo Switch crash data is available through the Nintendo Developer Portal. Like other console platforms, it uses a proprietary format with platform-specific debugging tools.

For all console platforms, you must pull crash data from their respective portals into your unified dashboard, either through APIs where available or through periodic manual exports.

Building a Unified Pipeline

The goal is to normalize crash data from every platform into a common schema that includes the symbolicated stack trace, the exception type, thread states, and device metadata. Your pipeline has three stages:

# Stage 1: Collection (platform-specific)
Windows   -> Crashpad -> minidump upload -> your server
macOS     -> Crashpad -> minidump upload -> your server
Linux     -> Crashpad -> minidump upload -> your server
Android   -> NDK handler + Java handler  -> your server
iOS       -> MetricKit / crash reporter  -> your server
Consoles  -> Platform portal API         -> your server

# Stage 2: Normalization (server-side)
minidump    -> symbolicate with PDB/dSYM/ELF -> common schema
tombstone   -> symbolicate with .so files     -> common schema
.crash/.ips -> symbolicate with dSYM          -> common schema

# Stage 3: Aggregation
common schema -> fingerprint -> group -> dashboard

The common schema should include: platform, OS version, device model, GPU and driver, game version, build ID, exception type, symbolicated stack trace (as an array of frames), and any custom metadata your game attaches (scene name, player state, etc.).

Metadata That Matters

The crash stack trace tells you what went wrong. The metadata tells you where and for whom. Essential metadata for cross-platform games includes:

Hardware information. CPU model, GPU model and driver version, total and available RAM. This helps identify hardware-specific crashes, especially GPU driver bugs that only appear on certain vendor and driver combinations.

Graphics API. Whether the game was using DirectX 11, DirectX 12, Vulkan, Metal, or OpenGL. Rendering crashes often appear only on one API, and knowing which one immediately narrows the investigation.

Game state. The scene or level, the time since launch, the player's progression state. A crash that only occurs in one specific level is much easier to reproduce than a crash with no context.

Cross-Platform Crash Grouping

When the same bug exists in shared code, it should produce the same crash group regardless of platform. A null pointer dereference in your inventory system is the same bug whether the crash report came from a Windows PC or an Android phone. However, the raw stack traces will look different because the symbolication sources and calling conventions differ.

Effective cross-platform grouping normalizes frames to use the same function name format regardless of the platform-specific mangling. After normalization, the fingerprinting algorithm produces the same hash for the same bug across platforms. This lets you see that a particular crash affects 300 Windows players and 50 Android players, giving you the true impact across your entire player base.

"One dashboard for all platforms. One bug list for all crashes. Anything else means some platforms' players get worse support than others."

Bugnet's Cross-Platform Approach

Bugnet provides SDKs for Unity, Unreal Engine, Godot, and native C/C++ games that handle the platform-specific collection layer automatically. On each platform, the SDK uses the appropriate crash capture mechanism and uploads the data to your Bugnet project. The server normalizes, symbolicates, and groups crashes across all platforms into a single dashboard. You see one unified list of crash groups with per-platform breakdowns, affected player counts, and version-specific trends.

Related Issues

For guidance on testing across platforms, see how to test your game on multiple platforms. To track performance issues alongside crashes, read how to track game performance issues across devices. For the fundamentals of crash reporting setup, see how to set up crash reporting for indie games.

Your players do not care which platform had the worst crash rate. They care that their platform's crashes get fixed.