Crash Reporting for Stride Engine Games

Stride is an open-source, C#-based game engine for 2D and 3D games, and games built with it fail in the patterns of a .NET application with a modern graphics backend. Crashes are C# exceptions with readable stack traces, which is convenient, and the graphics layer, which can target DirectX, Vulkan, or OpenGL depending on the platform and configuration, introduces graphics-specific crashes that cluster by API and GPU. Setting up crash reporting for a Stride game means capturing the .NET exceptions and the graphics and platform context that explain hardware-specific failures.

Stride is a C# engine with modern graphics

Stride games run on C# and the .NET runtime, so crashes surface as C# exceptions with readable stack traces, the familiar and convenient .NET model that points directly at the line that threw. This makes the bulk of Stride crashes, the logic errors in your C# code, straightforward to capture and read, much like any .NET game engine.

Stride also has a modern graphics backend that can target different graphics APIs, DirectX, Vulkan, or OpenGL, depending on the platform and configuration, and the graphics layer is a distinct crash source. Graphics crashes depend on the API in use and the GPU, and the same Stride game can crash on one graphics configuration and not another. Understanding that Stride combines readable .NET exceptions with a multi-API graphics backend frames the crash reporting: capture the exceptions for the logic crashes, and the graphics and hardware context for the graphics crashes.

Capture .NET exceptions

The foundation of Stride crash reporting is capturing unhandled C# exceptions. Hook the .NET unhandled exception handling so any exception that would crash the game is captured with its type, message, and full stack trace including inner exceptions, where the root cause is often wrapped. The stack traces are readable, pointing at the C# line that threw, which makes most Stride crashes straightforward to act on.

This .NET exception capture works as it does in any .NET application, giving you clean, readable reports for the logic errors in your code, which are the majority of crashes. Capture the full exception chain so the inner exception reveals the original error beneath a more general wrapper. Because Stride is a C# engine, this exception capture is the well-understood .NET model, providing the readable crash reports that make the logic crashes of a Stride game easy to diagnose, leaving the graphics-specific crashes to be handled with additional context.

Capture the graphics API and GPU

Graphics crashes are a distinct Stride crash source, and they cluster by graphics API and GPU, so capture which graphics API is in use, DirectX, Vulkan, or OpenGL, and the GPU and driver, with every crash. A graphics crash on one API or one GPU family points at an API-specific or hardware-specific issue, which the graphics context reveals.

Because Stride can use different graphics APIs depending on the platform and configuration, a crash specific to one API is a graphics-backend issue for that API, perhaps a shader or rendering feature that behaves differently across DirectX, Vulkan, and OpenGL. Capturing the graphics API alongside the GPU and driver lets you see when a crash is graphics-related and which API and hardware it affects, distinguishing a graphics-backend crash from a logic exception. This graphics context is what makes the graphics crashes of a Stride game, which the readable C# exceptions alone do not fully explain, diagnosable.

Capture the platform context

Stride games run across platforms, and crashes can be platform-specific, so capture the platform and OS with every crash. A crash that appears only on one platform points at a platform-specific issue, perhaps in how the .NET runtime, the engine, or the graphics backend behaves there, and the platform context is what lets you see it.

Capture the build configuration too, debug versus release, since .NET release builds optimize and behave differently from debug builds, and a release-only crash points at an optimization-related issue. The platform and build context, layered on the graphics context, gives you the full environment for a Stride crash: the platform it ran on, the graphics API and GPU, and the build configuration. Together with the readable C# exception, this context lets you interpret a Stride crash fully, distinguishing a logic bug from a graphics, platform, or configuration-specific issue.

Setting it up with Bugnet

Bugnet captures Stride crashes by hooking the .NET exception handling, recording the full exception chain and stack trace, and you attach the graphics API, GPU, platform, and build configuration as custom fields. Reports flow into one dashboard where you can see your Stride game crashes with the context that distinguishes logic, graphics, and platform issues.

Add custom fields for your game state and group identical exceptions into occurrence counts. Because Stride combines readable .NET exceptions with a multi-API graphics backend, the captured graphics-and-platform context is especially valuable: it lets you see whether a crash is an ordinary C# logic bug, a graphics-backend issue specific to an API or GPU, or a platform-specific problem, which determines how you fix it. The readable stack traces plus the graphics and platform context make Stride crashes highly diagnosable from the dashboard.

Test across graphics configurations

Because Stride graphics crashes cluster by API and GPU, test across the graphics configurations your players will use, the different APIs Stride may select and a range of GPUs, since a shader or rendering feature that works on one API or GPU can fail on another. Testing across graphics configurations catches the API-specific and hardware-specific graphics crashes that a single test setup would miss.

Pair that testing with your captured crash data, which surfaces the graphics and platform crashes across the full range of APIs, GPUs, and platforms your players run, which you cannot all test. Your testing exercises the main graphics configurations, and the captured data reveals the hardware-specific issues across the diversity of player setups. Together they let you ship a Stride game that holds up across the graphics backends and hardware it runs on, with the graphics-specific crashes, where the modern multi-API backend most often introduces failures, kept under control.

Stride is C# with a modern multi-API graphics backend. Capture the readable exceptions and the graphics API and GPU.