Quick answer: GOG ships your game DRM-free, so players run it through Galaxy or straight from a standalone installer with no launcher attached. That freedom means you cannot assume any client is present, and you cannot rely on store auto-updates to keep versions in sync. Capture your own build version and run mode on every crash, group duplicates by signature, and DRM-free distribution stops being a blind spot.
GOG's promise is no DRM, no mandatory launcher, just your game. That is great for players and slightly terrifying for crash reporting, because you lose the guarantees a store client provides. A player might run through Galaxy, or double-click the executable from a standalone installer they downloaded a year ago, or copy the whole folder to a second machine. The optional Galaxy SDK adds achievements and presence but is not required, so you cannot assume it is even initialized. This post covers how to capture crashes on GOG when there is no platform layer to lean on, and how to keep version chaos from hiding your real bugs.
DRM-free changes your assumptions
On most stores a client is always running, so you can read entitlement, version, and overlay state from the platform. GOG explicitly does not require that. A meaningful share of your players will launch the standalone executable with Galaxy never opened, which means any code that calls the Galaxy SDK must degrade gracefully or it becomes your first crash. The most common GOG-specific bug is an initialization path that assumes Galaxy is present and dereferences a null client when a player ran the game directly from the install folder.
Because there is no forced auto-update, the version a player runs can be arbitrarily old. Someone might reinstall from a downloaded backup that predates a critical fix, then report a crash you patched months ago. Standard store advice, just look at the latest build, does not apply here. You have to record which version actually ran on each crash, because the population of live versions on GOG is genuinely wider than on any locked-down platform, and that long tail is where a surprising number of reports come from.
Making the Galaxy SDK optional, safely
If you integrate the Galaxy SDK, treat every call as something that can be absent. Wrap initialization so a failure to connect leaves the game fully playable in offline DRM-free mode rather than crashing or hanging. Record a simple flag on startup: did Galaxy initialize, yes or no. That single bit of context separates two completely different crash populations, the Galaxy-connected players and the standalone runners, and a crash that only ever appears with the flag false points straight at your SDK guard code rather than your gameplay.
Be careful with features that quietly assume Galaxy: cloud saves, friends presence, achievement unlocks. These are exactly the call sites that throw when the client is missing. Build a small offline test that launches the executable directly with Galaxy closed and exercises each of those features, confirming they no-op cleanly. Reproducing GOG's most distinctive crashes is mostly about disciplined testing of the no-client path, which is easy to forget when your own machine always has Galaxy running in the background during development.
Tracking versions without a store to help
Since GOG will not enforce updates, you must do your own version bookkeeping. Bake a build version and commit hash into the executable and attach both to every crash report. When reports come in, the first question is always which version ran, and on GOG the answer is frequently old. A crash signature that only appears on versions below a certain number is a fixed bug resurfacing on stale installs, and the right response is a gentle in-game nudge to update rather than a code change you already shipped.
Consider showing players a lightweight, non-intrusive update notice when you detect an outdated standalone build, while never blocking play, since the whole appeal of GOG is that nothing is mandatory. The data you collect makes this practical: if you can see that thirty percent of a crash's reports come from a single ancient version, you have a clear, evidence-backed case for prompting an update, and you avoid spending engineering time re-fixing something that was solved long ago for everyone who actually patched.
Triaging a wide version spread
The breadth of live versions on GOG makes raw report lists noisy, so grouping is essential. Fold duplicate crashes by signature into a single issue, then look at the version distribution within each. A signature concentrated on the latest build is a real new bug and gets your attention immediately. A signature smeared across many old versions is usually a stale-install problem. Without this split you will keep reopening issues you already closed, because GOG's long version tail keeps feeding you reports from the past.
Layer in the Galaxy-initialized flag and device context as filters. A crash that only happens with Galaxy off and only on a particular version isolates a regression in your offline path during that release. The standalone nature of GOG means you get less automatic context than other stores, so the context you do choose to capture carries more weight. Spend it on the few facts that actually partition your crashes: version, run mode, GPU, and OS, and your triage stays sane even with a sprawling install base.
Setting it up with Bugnet
Bugnet does not depend on any store client, which fits GOG's DRM-free model exactly. The in-game report button and crash handler run inside your game regardless of whether Galaxy is open, so you collect reports from standalone runners and Galaxy users alike. On a crash the SDK captures the stack trace and attaches your build version, a Galaxy-initialized flag you set as a custom field, the run mode, GPU, driver, and OS, plus the current scene and session time. The report arrives already telling you which of GOG's two worlds the player was in.
On the dashboard, occurrence grouping folds the noise of a wide version spread into ranked issues, and you can read the version distribution per issue at a glance. Filtering by your Galaxy flag separates offline-path bugs from connected ones, and player attributes let you see whether stale installs cluster in a particular region or store locale. For a DRM-free title where you cannot lean on the platform for context, having one dashboard that captures and groups everything yourself is what makes GOG crashes tractable instead of mysterious.
A reporting routine that respects DRM-free
Bake your reporting around the freedom GOG gives players rather than fighting it. Always ship a build that runs and reports without Galaxy, always embed a version you can read back, and never block play to force an update. Make the no-client launch a standing item in your pre-submission checklist, because it is the single path most likely to regress and the one your daily development never exercises. A few minutes testing the standalone executable with Galaxy closed prevents the most embarrassing GOG-specific crash there is.
Over time the version distribution on your crashes becomes a useful map of your player base. You will see how slowly the long tail updates, which tells you how long a fix takes to reach most players and whether an update prompt is worth adding. The DRM-free ethos means you are trusting players with that freedom, and good crash reporting is how you keep that trust without flying blind. The aim is a quiet, reliable loop where even your most independent players quietly send you the data you need to keep their game stable.
GOG hands players freedom from launchers and forced updates. Capture your own version and run mode and that freedom stops being a crash-reporting blind spot.