A C++ app crashes in the field. You get a vague bug report - "it closed itself" - and a customer who's annoyed. No repro steps. No stack. Just a black box where a useful error should be.

This is the native developer's tax. Web folks get a clean exception and a line number handed to them. You get memory corruption, a pointer that wandered off three frames ago, and a release build with the symbols stripped out. The crash that's killing your users is almost never the crash you can reproduce on your machine.

The thing that turns that black box back into a line of code is the stack trace - the exact sequence of function calls that led up to the crash. Here's how to capture one automatically, every time, from every user, without asking them to do anything.

What BugSplat actually does here

BugSplat is a crash and error reporting service. When your C++ app crashes in the wild, it captures the minidump, ships it to your dashboard, and - this is the part that matters - symbolicates it against the PDBs you uploaded at build time. So instead of a hex address, you get function names, file names, and line numbers. The crash from a user three time zones away reads like a stack trace from your own debugger.

C++ was the first platform BugSplat ever supported. The native stack is the home turf, not a temporary port.

Getting it into your project

Four steps. None of them take long.

1. Grab the SDK. Download and unzip the BugSplat SDK for Microsoft Visual C++, or pull it from GitHub. It ships with a MyConsoleCrasher sample - build it, crash it, watch the report land in your dashboard. Do this first. It's the fastest way to see the whole loop before you touch your own code. (Shipping WinUI 3? There's a MyWinUI3Crasher sample too, since WinUI needs BugSplat registered as a WER RuntimeExceptionModule.)

2. Wire it into your code. Include BugSplat.h and create a BugSplat instance. The constructor takes three things: your database, your application name, and your version. Match the app name and version to your actual release - you'll reuse those exact values when you upload symbols.

#include "BugSplat.h"

// database, application, version
MiniDmpSender *sender = new MiniDmpSender(
    L"YourDatabase", L"YourApp", L"1.0.0");

3. Configure the build. Link against BugSplat.lib (Linker > Input > Additional Dependencies), and add BugSplatMonitor.exe, BugSplatWer.dll, and BugSplatRc.dll to your installer. Then the step everyone forgets: set C/C++ > General > Debug Information Format to Program Database (/Zi) so release builds actually generate PDBs. No PDBs, no symbolication, no readable stack.

4. Upload symbols, then crash it. Push your symbol files up with the symbol-upload tool so BugSplat can resolve addresses to real names. Then force a crash and confirm the report shows up. Once that loop works once, it works forever - every user crash from here on lands the same way.

Reading the trace once it lands

Open your dashboard and the workflow is short:

Start at the Summary page, not the firehose. Crashes are grouped by their common defect, so you're looking at problems, not individual reports. The crash that hit 400 users sits at the top. Fix that one first.

Open a group, open a sample crash. Scroll to the Active Thread section. That's your stack trace - the call chain in reverse order, function names and line numbers attached. The top frame is usually where it died; walk down to find where it went wrong.

Triage by impact. Grouping turns "we have 10,000 crashes" into "we have nine bugs." That reframe is the whole point. You stop drowning in reports and start working a fix list.

Why this is worth twenty minutes of setup

You stop debugging blind. The trace points you straight at the failing code instead of forcing you to reconstruct it from a one-line user complaint.

You see patterns over time. Every crash is kept, so a regression that creeps back in three releases later is obvious instead of a mystery.

Your whole team sees the same reports. No more "can you forward me that crash" - the lead, the engineer who owns that subsystem, and QA are all looking at the identical stack.

And your users feel none of it. They get an app that crashes less and gets fixed faster, which is the only metric they actually care about.

That's the job. Capture the stack automatically, symbolicate it so it's readable, group it so you know what to fix first. Your three-person team gets the crash visibility of a studio with a dedicated tools group, minus the dedicated tools group.

BugSplat is free to start. Sign up here.