How do I tell an Epic Online Services overlay crash from a crash in my own renderer?

Capture whether the overlay reported itself active and read the top stack frames. If the overlay was active and the trace ends inside a present, swap-chain, or input-hook call rather than your own draw code, the hook is the likely trigger. Reproduce with the overlay disabled to confirm; if the crash disappears, it is the overlay path, not your loop.

Why do crashes spike right after an Epic Games Store patch and then fade?

The launcher patches in the background and can briefly leave a player on a stale executable loading newer data files. That version skew causes a burst of crashes that taper as everyone finishes updating. Recording the build ID on each report lets you see the spike correlate to a release and recognize it as a patching window rather than a code defect.

What build identifier should I attach to EGS crash reports?

Embed your own build hash or version string at compile time and read it back at runtime, rather than relying only on the launcher's number. Attach it to every crash so you can match a report to an exact build. This is what lets you confirm whether a player ran the version you think they did and whether a fix actually reached them.

Crash Reporting for Games on the Epic Games Store

Quick answer: The Epic Games Store distributes your build through its own launcher, which means crashes can come from your game code, the Epic Online Services overlay, or the launcher patching process itself. Capture a stack trace plus the EGS build ID, EOS state, and overlay status on every crash, group duplicates by signature, and you can tell which layer actually failed.

Shipping on the Epic Games Store puts your game behind a launcher you do not fully control. The launcher patches your build, injects an Epic Online Services overlay, and manages entitlements before your executable ever runs. When a player reports a crash, you are not just debugging your game, you are debugging the seam between your code and Epic's runtime. This post walks through what actually breaks on EGS, what context you need to capture to tell those layers apart, and how a crash report becomes something you can fix instead of a vague complaint in your Discord.

Why Epic Games Store crashes are different

On Steam most crashes are squarely your code, but on EGS the launcher and the Epic Online Services overlay sit in your process. The overlay hooks rendering and input, so a crash inside its DirectX present path looks like your renderer died when it did not. Players also run mismatched builds because the launcher patches in the background and a stale executable can load against newer data files. Without knowing which build actually ran, you will chase ghosts that vanish the moment the player restarts the launcher.

Entitlement and authentication failures add another category. If EOS cannot reach Epic's backend, your initialization code may dereference a null session or assume a logged-in user that never arrived. These are not random, they cluster around offline play, account switching, and first launch after purchase. Separating them from gameplay crashes requires recording the EOS login state and whether the overlay was active at the moment things fell over, not just the line of code that threw.

What context to capture on every crash

Start with a real stack trace and the exact build identifier the launcher delivered. Read the EGS build version or your own embedded build hash so you can match a crash to a specific patch. Record whether Epic Online Services initialized successfully, whether a user session exists, and whether the overlay reported itself active. Add the usual device context: GPU vendor and driver version, OS build, available memory, and the game's resolution and graphics preset. Each of these turns a one-line panic into a story you can read.

Game state matters as much as system state. Capture the current scene or level, elapsed session time, and the last few significant player actions before the crash. If your game has a deterministic seed or a save slot, include its identifier. For EGS specifically, note whether the launch came through the launcher or a direct executable run during development, because those paths differ in how EOS is initialized and a bug that only appears under the launcher will hide from your own desk testing entirely.

Reproducing launcher and overlay issues

The hardest EGS bugs only appear under the real launcher, so build a test loop that mirrors it. Install your game through the Epic Games Launcher in a clean account, then reproduce with the overlay enabled and disabled to isolate hook-related crashes. Keep an account with no entitlement and one mid-purchase to exercise the authentication edges. When a crash report says the overlay was active and the stack ends in a present or input call, you have a strong signal that Epic's hook, not your loop, is the trigger.

Version skew deserves a dedicated check. After every store patch, verify your save and config formats still load against the new build, because the launcher can leave a player on an executable that expects an older data layout for a few minutes. Reports that cluster tightly right after a release, then taper off, almost always mean a patching window problem rather than a code defect. Reading the build ID off each report is what lets you see that shape instead of guessing.

Triaging EGS crash volume

A popular EGS launch can produce thousands of near-identical reports in an hour, and reading them one at a time is hopeless. Fold duplicates into a single issue keyed on the crash signature, the stack frames stripped of addresses, so one bug shows one entry with a count. The count itself is your priority signal: a crash hitting two hundred players outranks a cosmetic glitch hitting three, even if the glitch is louder in your feedback channels. This is the difference between triage and drowning.

Slice the grouped issues by the context you captured. Filter to a single GPU vendor and a launcher crash that looked universal often turns out to be one driver family. Filter by EOS state and an init crash separates cleanly from a gameplay one. The grouped view plus a few filters lets you walk into a release-day fire with a ranked list of what is actually hurting the most players, instead of a wall of unread tickets you will never get through.

Setting it up with Bugnet

Bugnet gives you an in-game report button and an automatic crash handler that fire without the player leaving your game. When your build crashes, the SDK captures the stack trace and attaches the context you care about on EGS: the build identifier, Epic Online Services login state, whether the overlay was active, GPU and driver, OS build, and the current scene. You can add custom fields for anything Epic-specific, such as a launcher version string or entitlement status, so the report arrives already answering the questions you would otherwise email the player to ask.

On the dashboard, Bugnet folds duplicate reports into one issue with an occurrence count, so a release-day storm becomes a short ranked list. You filter by GPU, by EOS state, or by build to confirm whether a spike is your code or a patching window, and player attributes let you see whether crashes concentrate among new buyers or returning players. Instead of reconstructing each crash from a forum post, you open one issue and read exactly what the game was doing the moment it died.

Building an EGS-ready crash culture

Treat the launcher as a first-class part of your test matrix rather than a deployment detail. Before every EGS submission, run the build through the real launcher with the overlay on, on a clean account, and confirm crashes report cleanly with build IDs attached. Keep a short runbook for release day: watch the occurrence counts for the first few hours, expect a patching-window spike, and only escalate when a signature keeps climbing after the rollout settles. A calm, instrumented launch beats a frantic one every time.

Over a few releases the captured context compounds into real institutional knowledge. You learn which GPU families are fragile, which EOS edges your init path mishandles, and how long your typical patching window lasts. New crashes get compared against that history instead of investigated from scratch. The goal is not zero crashes, which no shipped game achieves, but a fast and honest loop where a player's bad moment turns into a specific, prioritized fix that ships in your next EGS patch.

On EGS you are debugging the seam between your game, the overlay, and the launcher. Capture the build ID and EOS state and the layer that failed stops being a guess.