How do I retrieve crash dumps from a PlayStation 5 development kit?

When a crash occurs on a PS5 development kit (DECR or DEH model), the system generates a coredump that is stored on the dev kit's internal storage. You retrieve it using the Target Manager in the PlayStation Partners SDK. Connect to the dev kit over your local network, navigate to the crash dump section, and download the file. The coredump contains the full memory state, register values, and thread information at the time of the crash. You then analyze it using the PS5-specific build of the SN Systems debugger or by loading it into the Prospero SDK's crash analysis tools. For retail crash data, Sony collects reports automatically and makes them available through the PlayStation Partners portal under the Quality Assurance section.

What are TRC requirements and how do they relate to crash reporting?

TRC stands for Technical Requirements Checklist, which is Sony's set of mandatory requirements that every PS5 game must pass before it can be published on the PlayStation Store. TRC violations are not optional suggestions; they are hard requirements that will block your game's release if not met. Several TRC items directly relate to stability and crash handling, including requirements around graceful error handling, save data integrity after crashes, proper behavior when network connections drop, and correct handling of system-level events like user switching and rest mode transitions. Your crash reporting workflow should tag any bug that could cause a TRC failure so that these can be prioritized above general bugs during the submission process.

How should I manage crash data across PS4 and PS5 builds of the same game?

If your game ships on both PS4 and PS5, you are maintaining two separate builds with different hardware targets, potentially different rendering pipelines, and different system libraries. Crashes should be tracked separately by platform because the root causes are often different even when the symptoms are similar. Use your bug tracker's platform field to distinguish PS4 and PS5 reports, and maintain separate symbol files for each build. When a crash exists in shared code and affects both platforms, link the bug reports so that a fix can be verified on both. Pay special attention to backward-compatible PS4 builds running on PS5 hardware, as they have their own unique behavior through the compatibility layer.

Crash Reporting for PlayStation 5 Games

Quick answer: When a crash occurs on a PS5 development kit (DECR or DEH model), the system generates a coredump that is stored on the dev kit's internal storage. You retrieve it using the Target Manager in the PlayStation Partners SDK.

This guide covers crash reporting for PlayStation PS5 games in detail. Crash reporting on PlayStation 5 is a different discipline than crash reporting on PC. You cannot install custom crash handlers, you cannot ship debug symbols to players, and the tools you use are provided by Sony under NDA. Despite these constraints, building a reliable crash reporting pipeline is essential for shipping a stable PS5 title. This guide covers how to collect crash data from development kits and retail consoles, how to analyze coredumps with Sony's toolchain, how to manage TRC compliance, and how to track crash data across PS4 and PS5 builds of the same game.

The PS5 Crash Reporting Landscape

Unlike PC platforms where you can integrate Crashpad or Breakpad and receive crash dumps directly from player machines, PlayStation uses a closed crash reporting system. When a game crashes on a retail PS5, Sony's system collects the crash data and makes it available to you through the PlayStation Partners portal. You do not have direct access to the player's console, and you cannot run your own crash collection server for PlayStation builds.

On development kits, you have more control. The PS5 DECR (Development Environment for Creators) and DEH (Development and Evaluation Hardware) kits generate coredumps when a crash occurs. These coredumps are stored locally on the dev kit and can be retrieved through the Target Manager application that is part of the PlayStation Partners SDK.

This means your crash reporting workflow has two distinct paths: one for development (direct coredump analysis from dev kits) and one for retail (aggregated crash data from the PlayStation Partners portal). Both paths should feed into the same bug tracking system so you have a unified view of your game's stability.

Collecting Coredumps from Development Kits

When your game crashes on a PS5 dev kit, the system captures a coredump file that contains the full state of the process at the time of the crash. This includes all thread stacks, register values, loaded module information, and depending on your configuration, portions of the heap memory.

To retrieve the coredump, open Target Manager on your development PC, connect to the dev kit, and navigate to the crash dump section. You can download the dump file to your local machine for analysis. The file is in a Sony-proprietary format that can only be read by Sony's debugging tools.

Automate retrieval when possible. If your QA team is running tests on multiple dev kits, manually checking each one for crash dumps is slow and error-prone. Write a script that polls connected dev kits via the Target Manager CLI, downloads any new crash dumps, symbolicates them, and creates bug reports automatically. This ensures no crash goes unnoticed during a test session.

# Pseudocode for automated crash dump collection
# (Actual commands use Sony's proprietary CLI tools)

for devkit in connected_devkits:
    dumps = target_manager.list_crash_dumps(devkit)
    for dump in dumps:
        if dump.id not in processed_dumps:
            # Download the coredump
            local_path = target_manager.download(devkit, dump.id)

            # Symbolicate with debug ELF for this build
            symbols = symbol_store.get(dump.build_id)
            report = symbolicate(local_path, symbols)

            # Create bug report in tracker
            create_bug_report(
                title=f"PS5 Crash: {report.exception_type} in {report.top_frame}",
                stack_trace=report.symbolicated_stack,
                build=dump.build_id,
                devkit=devkit.name,
                scene=report.metadata.get("scene", "unknown")
            )
            processed_dumps.add(dump.id)

Analyzing Coredumps with Sony's Tools

Sony provides debugging tools as part of the Prospero SDK (the PS5 development SDK). The primary tool for crash analysis is the Prospero debugger, which can load coredump files and present them in a manner similar to loading a core dump in GDB or WinDbg. You can inspect the call stack of every thread, examine register values, view local and global variables (if debug symbols are available), and navigate through the memory state at the time of the crash.

The quality of your crash analysis depends entirely on the quality of your debug symbols. Your CI pipeline should produce and archive symbol files for every build. When a crash dump comes in, you need to match it to the exact symbols for that build. A mismatch will produce garbage function names and incorrect line numbers, making the dump useless.

Common PS5 crash types you will encounter include:

Page faults. The most common crash type. A null pointer dereference, an access to freed memory, or a buffer overrun that touches unmapped memory. The coredump will show the faulting address and the instruction that caused the fault. If the faulting address is near zero, it is likely a null pointer. If it is a plausible but freed address, suspect use-after-free.

Stack overflows. Deep recursion or large stack allocations can exhaust the thread stack. The crash manifests as a page fault at the stack guard page. Check the call stack for recursive patterns or unusually deep call chains.

GPU hangs. If the GPU does not respond within a timeout period, the system terminates the process. GPU hang dumps include GPU-specific diagnostic information. These are often caused by infinite loops in shaders, excessively complex draw calls, or driver-level issues that require a workaround.

Out of memory. The PS5 has 16 GB of GDDR6 memory shared between CPU and GPU, but the game does not get all of it. The system reserves a portion, and your game has a memory budget that varies depending on whether you are using the full PS5 mode or the PS4 compatibility mode. When your game exceeds its budget, the allocation fails. If your code does not handle allocation failure gracefully, it crashes.

Retail Crash Data from PlayStation Partners

Once your game is live on the PlayStation Store, Sony collects crash data from retail consoles. This data appears in the PlayStation Partners portal under the Quality Assurance section, typically with a delay of 24 to 48 hours.

The portal provides an aggregated view of crashes grouped by crash signature (a hash of the crash location and call stack). For each group, you can see the number of occurrences, the firmware versions affected, the game versions affected, and basic system information. You can also download individual crash dumps for detailed analysis.

The retail crash data is invaluable because it represents the real-world experience of your players. A crash that happens on one dev kit during testing might affect thousands of players in the wild. The portal shows you the actual scale of each crash, which helps you prioritize fixes.

Upload your symbols to the portal. Sony supports uploading your game's debug symbols so that retail crash reports are automatically symbolicated. Without uploaded symbols, you see raw addresses that need to be manually symbolicated for every crash you investigate. Configure your CI pipeline to upload symbols for every build that goes through Sony's submission process.

TRC Compliance and Crash Handling

Sony's Technical Requirements Checklist (TRC) is a set of mandatory requirements that every PS5 game must pass before it can be published. Failing TRC means your game is rejected and must be resubmitted after fixing the violations. Some TRC failures can delay your launch by weeks.

Several TRC requirements directly relate to stability and error handling:

No crashes. The most fundamental TRC requirement is that your game must not crash. This sounds obvious, but TRC testing is thorough. Testers will try unusual input patterns, disconnect network cables mid-session, eject discs during loading, switch user accounts mid-game, put the console in rest mode and resume, and generally try to break your game in ways your QA team may not have considered.

Save data integrity. If a crash does occur (or if the player loses power), your save data must not become corrupted. The TRC requires that save operations are atomic. You must write to a temporary file and rename it to the final path, or use the system's save data utility which provides this guarantee. A crash during a save operation must not leave the save file in a partial or unreadable state.

Rest mode handling. Your game must handle the console entering and exiting rest mode correctly. Network connections must be re-established, audio must resume, controller connections must be redetected, and the game must not crash, hang, or display corruption. This is similar to the Switch sleep/wake requirement but tested rigorously against Sony's specific criteria.

Error dialogs. When a recoverable error occurs (network disconnection, storage full, controller disconnected), your game must display an appropriate error message using Sony's system dialog format. Silently failing or displaying a generic crash message is a TRC violation.

In your bug tracker, tag any bug that could cause a TRC failure with the specific TRC requirement ID. This lets you filter for TRC-blocking bugs and prioritize them as your submission date approaches. A custom label like TRC-R4070 (hypothetical example) is more useful than a generic "TRC violation" tag because it tells the developer exactly which requirement to review.

Managing Crashes Across PS4 and PS5 Builds

Many games ship on both PS4 and PS5, either as a cross-generation title or through PS4 backward compatibility on PS5. This creates complexity in crash reporting because you are effectively managing two separate products with different hardware profiles, different system libraries, and potentially different rendering pipelines.

PS5 native builds run on the full PS5 hardware with access to the Prospero SDK features, 16 GB of GDDR6, the custom SSD with hardware decompression, and the Tempest audio engine. Crashes in native PS5 builds are analyzed using the Prospero debugger and PS5-specific symbols.

PS4 builds running on PS5 execute through the backward compatibility layer. They see the hardware as a more powerful PS4, with access to more memory and faster loading times, but they use the PS4 SDK and PS4 system libraries. Crashes in backward-compatible mode are analyzed using PS4 tools, but the behavior may differ from a crash on actual PS4 hardware because the compatibility layer is not a perfect replica of PS4 hardware.

Native PS4 builds on PS4 hardware are a third configuration. These run on the original PS4 or PS4 Pro, with 8 GB of GDDR5 and the Orbis SDK. Crashes here are analyzed with PS4 tools and PS4 symbols.

Your bug tracker should distinguish between these three configurations using platform labels: PS5, PS4-on-PS5, and PS4. A crash that occurs only in the PS4-on-PS5 configuration is likely a compatibility layer issue and has a different fix path than the same crash on native PS4 hardware.

# Recommended platform labels for PlayStation bugs
PS5              # Native PS5 build on PS5 hardware
PS4-on-PS5       # PS4 build running via backward compat on PS5
PS4              # PS4 build on PS4 or PS4 Pro hardware
PS4-Pro          # PS4 build specifically on PS4 Pro (if Pro-specific bugs exist)

# Additional fields
System Software: 24.05-09.40.00  # PS5 firmware version
Game Version:    1.03
Build ID:        abc123def
GPU Mode:        Performance | Quality | Custom

Building Your Pipeline

The ideal PS5 crash reporting pipeline connects your development workflow to your bug tracker with minimal manual steps:

Step 1: Symbol archival. Every build that leaves your CI pipeline gets its symbols archived and indexed by build ID. This includes PS5 Prospero symbols, PS4 Orbis symbols, and any middleware symbols (Wwise, Havok, etc.).

Step 2: Dev kit crash collection. An automated system polls connected dev kits for new crash dumps, downloads them, symbolicates them against the correct symbols, and creates or updates bug reports in your tracker.

Step 3: Retail crash import. A scheduled job checks the PlayStation Partners portal for new retail crash data, downloads the aggregated reports and individual dumps, symbolicates them, and creates or updates bug reports. Each unique crash signature becomes a single bug report with a count of occurrences.

Step 4: TRC integration. When TRC testing produces failures, those are entered as high-priority bugs with TRC requirement IDs. The bug tracker provides a filtered view showing only TRC-blocking issues for submission readiness assessment.

"Sony does not care why your game crashed. They care that it crashed. TRC is pass/fail, and crashes are always a fail."

Integrating with Bugnet

Bugnet's API lets you push crash report data from your automated collection pipeline directly into your project. Each crash becomes a bug with structured fields for platform, build version, exception type, and the symbolicated stack trace. Bugnet's duplicate detection groups crashes by stack trace similarity, so multiple occurrences of the same crash roll up into a single bug with an occurrence count.

For TRC tracking, create a custom label group for TRC requirement IDs and apply them to relevant bugs. Bugnet's label filtering lets you pull up all open TRC issues with one click, giving you a clear submission readiness dashboard.