#No crash data sent from Unreal Enginge shipping build

1 messages · Page 1 of 1 (latest)

modern folioBOT
#

Hi @stiff totem. I'm happy to dig into this for you! I'll check my internal sources for answers to your question! :wave:

#

Based on the docs and issues in the knowledge sources, there are a few Unreal‑specific pitfalls to check.

1. Crash capture mechanism (Sentry SDK vs UE Crash Reporter)

On Windows with UE 5.2+ you must choose either:

  • Sentry’s own crash capturing (sentry-native via the plugin), or
  • UE Crash Reporter Client (CRC) sending to Sentry.

They are mutually exclusive and can’t be used at the same time. [Unreal overview; Crash Reporter docs]

If you’re on UE 5.2+ and using the Sentry plugin:

  • In Project Settings → Plugins → Sentry, ensure “Enable automatic crash capturing (Windows, UE 5.2+)” (or similarly named option) is enabled if you want Sentry to capture crashes directly. [Crash Reporter docs]
  • If you instead want to use the UE Crash Reporter, you must:
    • Enable Include Crash Reporter in Project → Packaging → Show Advanced → Include Crash Reporter. [Include Crash Reporter]
    • Configure the CrashReportClient endpoint (DataRouterUrl) with your Sentry Unreal Engine Endpoint in Engine/Programs/CrashReportClient/Config/DefaultEngine.ini. [Configure endpoint]

If both are partially configured (e.g. CRC enabled but no endpoint, or Sentry crash capture disabled), editor crashes may still show up (because the editor uses a different path), while shipping builds don’t send anything.

2. Crash Reporter not included in shipping builds

#

If you rely on the UE Crash Reporter path (not Sentry’s native crash capture), make sure:

  • Include Crash Reporter is enabled in your project’s packaging settings; otherwise shipping builds won’t show the crash dialog or send reports. [Include Crash Reporter]

There’s also a separate Include Debug Files option that must be enabled for Sentry to symbolicate native crashes; without it, crash reports are effectively useless even if they arrive. [Onboarding note]

3. Engine version differences

  • UE ≤ 5.1 (Windows): Sentry cannot fully replace CRC for crash capture; you must configure the UE Crash Reporter to send to Sentry. [Unreal overview]
  • UE 5.2+ (Windows): Sentry plugin can capture crashes directly; CRC configuration is no longer required and should generally be disabled if you use Sentry’s crash capture. [Unreal overview; Issue 977 comment]

If you followed an older guide that still mentions always configuring CrashReportClient, that can be misleading for UE 5.2+ when using the SDK. [Onboarding wizard issue; Issue 977 comment]

4. Platform coverage

CRC only exists on desktop (Windows, macOS, Linux). For mobile and consoles, you must use the Sentry SDK; CRC will never send anything there. [Crash Reporter docs]

5. Things to verify in your project

Given the above, for a shipping build that sends no crashes:

#
  1. Confirm engine version and platform (e.g. Windows UE 5.2+ vs older).
  2. Decide on one crash path:
    • Sentry plugin crash capture enabled, CRC not configured, or
    • CRC included and configured with Sentry Unreal Endpoint, Sentry plugin used only for enrichment.
  3. If using CRC:
    • Include Crash Reporter is checked in Project → Packaging. [Include Crash Reporter]
    • DataRouterUrl in CrashReportClient section of DefaultEngine.ini points to your Sentry Unreal Engine Endpoint. [Configure endpoint]
  4. If using Sentry’s crash capture (UE 5.2+ on Windows):
  5. Ensure debug files are included in packaging so Sentry can symbolicate crashes. [Onboarding note]

If you share your UE version, target platform, and whether you configured CrashReportClient or rely solely on the plugin, I can help narrow down which of these is most likely affecting your shipping build.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@stiff totem Our robots are still learning and improving, please let us know if this response was correct by reacting below.

#

Let me check the knowledge base for you again. One moment! :books:

#

Yes — if you’re using “Enable automatic crash capturing (Windows, UE 5.2+)” (that is, Sentry’s own crash capturing via sentry-native), you generally do not need to configure Engine/Programs/CrashReportClient/Config/DefaultEngine.ini.

Key points from the docs and issues:

  • Starting with UE 5.2, Sentry can capture crashes directly on Windows without going through the UE Crash Reporter Client (CRC). The CRC configuration step “isn't required” in that case. [Unreal overview]
  • The Crash Reporter endpoint in DefaultEngine.ini is specifically for integrating UE Crash Reporter with Sentry. [Configure endpoint]
  • For UE 5.2+ it’s recommended to pick one mechanism: either CRC or Sentry’s native crash capture. They are mutually exclusive on Windows. [Crash Reporter docs; Issue 404]
  • A maintainer explicitly notes that for UE 5.5 there’s “no need to use CRC at all since Sentry SDK can now fully handle crash capturing on its own,” and suggests resetting CRC configuration and leaving the endpoint empty. [Issue 977]

So, if you enable automatic crash capturing in the Sentry plugin on UE 5.2+ and intend to rely on Sentry’s native integration, you should not need to set the Crash Reporter endpoint in DefaultEngine.ini, and you can leave it empty or reset it.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@stiff totem Our robots are still learning and improving, please let us know if this response was correct by reacting below.

modern folioBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

There is some relevant information, but the knowledge sources don’t fully cover all troubleshooting steps for sentry-native in Unreal, so I’ll focus on what is documented and where to look.

1. Confirm that native crash capturing is actually enabled

On UE 5.2+ (Windows), the Sentry plugin can use sentry-native instead of the UE Crash Reporter. This is controlled by the “Enable automatic crash capturing (Windows, UE 5.2+)” toggle in:

Project Settings → Plugins → Sentry

A maintainer explains that when this is checked, Sentry uses sentry-native and disables the UE Crash Reporter; when it’s unchecked, UE’s Crash Reporter is used instead. They are mutually exclusive. [Issue 404 comment; Crash Reporter docs]

So verify:

  • Automatic crash capturing is enabled in the plugin.
  • You’re not relying on Crash Reporter configuration in DefaultEngine.ini for this mode.

2. Check that Sentry is enabled for the right build targets

The plugin has a “Enable for Build Target Types” setting that controls for which targets sentry-native is initialized. If your current target (e.g. Editor, Game, Server) is disabled there, Sentry won’t initialize and no crashes will be captured. A maintainer describes using this to have Sentry-native on servers while leaving Crash Reporter active on clients. [Unreal crash reporter discussion]

Action: In Project Settings → Plugins → Sentry → Misc, make sure the target type you’re running (Editor / Game / Server) is checked.

3. Look for local crash dump files from sentry-native

#

When sentry-native captures a crash, it writes a dump file locally. A collaborator notes that these are stored under:

<BuildDir>/<ProjectName>/.sentry-native/reports [Issue 329 comment]

If you trigger a crash and no file appears there, it strongly suggests that:

  • sentry-native is not actually enabled/initialized for that target, or
  • Another crash handler is taking over first.

If dumps are present locally but nothing shows up in Sentry, the problem is likely network/configuration (DSN, auth, etc.), but the knowledge sources don’t give more detail on that path.

4. Don’t mix Crash Reporter and native integration

For UE 5.2+ on Windows:

  • Using sentry-native (automatic crash capturing) means you should not rely on UE Crash Reporter or its endpoint configuration. [Unreal overview; Crash Reporter docs; Issue 404 comment]
  • If Crash Reporter is still enabled or misconfigured, it can interfere (for example, you might expect the Crash Reporter UI but it won’t appear when native capturing is active). [Issue 404 comment]

Action: For a pure sentry-native setup, you can:

  • Leave the Crash Reporter endpoint empty / reset.
  • Optionally disable “Include Crash Reporter” in packaging if you don’t want CRC at all. [Issue 271 comment]

5. Logs / diagnostics

#

The knowledge sources don’t explicitly document a dedicated Sentry log file for the Unreal plugin. The only concrete diagnostic artifact mentioned for native integration is the local dump directory above. [Issue 329 comment]

So, from the available docs/issues, the most actionable checks are:

  1. Automatic crash capturing is enabled in the Sentry plugin (Windows, UE 5.2+). [Crash Reporter docs]
  2. Your current build target type is enabled under “Enable for Build Target Types”. [Unreal crash reporter discussion]
  3. After a test crash, verify whether a dump appears in
    <BuildDir>/<ProjectName>/.sentry-native/reports. [Issue 329 comment]
  4. Ensure you’re not unintentionally mixing CRC and native integration (CRC endpoint config is not required for native mode). [Unreal overview; Issue 404 comment]

If you can share your UE version, platform, and whether you see anything in .sentry-native/reports, that would help narrow down whether the issue is initialization vs. upload.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@stiff totem Our robots are still learning and improving, please let us know if this response was correct by reacting below.

#

Let me check the knowledge base for you again. One moment! :books:

#

That log line means the Sentry SDK sent a request to Sentry’s servers and Sentry responded with HTTP status 403 Forbidden. In other words, the request reached Sentry but was rejected.

From the available knowledge, common 403 causes include:

  • IP/network being blocked – for example, some Hetzner IP ranges are blocked by Google Cloud Platform, which Sentry uses. In that case you must request a different IP from your provider. [403 Hetzner IPs]
  • Permission / auth problems – Sentry can respond with 403 when the token or project/organization permissions don’t allow the requested action (for example, “You do not have permission to perform this action.”). [Self-hosted 403]
  • Project/DSN issues – for event submission, a 403 with a message like event submission rejected with_reason: ProjectId indicates a DSN or project backend setup problem. [ProjectId 403]

The log you posted is just the Unreal plugin surfacing that 403; to know which of the above applies, you’d need to inspect the full HTTP response body (if any) or Sentry server logs. The knowledge sources don’t include Unreal‑specific 403 troubleshooting beyond these general causes, so I can’t be more precise than that.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@stiff totem Our robots are still learning and improving, please let us know if this response was correct by reacting below.

#

Let me check the knowledge base for you again. One moment! :books:

#

This log shows that your Unreal client successfully reached Sentry’s SaaS endpoint, but Sentry rejected the envelope with HTTP 403.

From the headers:

  • Via: 1.1 google and Server: nginx indicate the request hit Sentry’s infrastructure on Google Cloud.
  • A 403 in this context typically means either:
    1. Network/IP is blocked by Google Cloud, or
    2. Sentry rejected the request for permission / project reasons.

The only concrete 403 cause explicitly documented for event sending is blocked Hetzner IP ranges: Google Cloud is known to deny some Hetzner IPs, and Sentry (hosted on GCP) will return 403 for all requests from those IPs. The recommended fix is to request a different IP from Hetzner. [403 Hetzner IPs]

Separately, Sentry can also return 403 for permission/auth issues (for example, when an API token doesn’t have rights for the requested action), but the knowledge sources don’t show the exact JSON body for your case, so I can’t say which applies here. [Self-hosted 403]

Given the available information:

  • If you’re running from a Hetzner-hosted machine, the most likely cause is the GCP/Hetzner IP block; you’d need to get a new IP from Hetzner. [403 Hetzner IPs]
  • Otherwise, the knowledge sources don’t provide enough detail to pinpoint the exact reason; you’d need to inspect the response body (the 61‑byte JSON) or Sentry’s server logs to see the specific error message.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: