# Crash reports

> What the station keeps when it closes unexpectedly, what it sends and when it asks, and the two debug commands a development build carries.

Crash reports is the one row of the DIAGNOSTICS group on the Settings page. A crash is never sent while the app is going down: it is captured to a file, and the next start either sends it or shows it to you and asks. This section holds the one switch that decides which. The page takes the **Change settings** permission.

## Send crash reports automatically {#send-crash-reports-automatically}

| Field | What it is | Values / default | Effect |
| --- | --- | --- | --- |
| Send crash reports automatically | "When the app crashes, send the report on the next start without asking. Off: you're shown the report and asked first." | On or off. Off by default. | On: the next start sends the captured report silently and clears it once the server accepted it. Off: the next visible start opens the consent dialog. |

While the runtime is stopped this page is not drawn at all (see [Settings](settings)). The same opt-in is offered inside the consent dialog itself, as the checkbox "Always send crash reports automatically", and ticking it there turns this switch on. Under the switch the card says: "To report a bug, suggest an improvement or request a driver, use the Account page." That form is [Feedback](account-feedback), because it sends with the Ganter account.

## What a report contains {#what-a-report-contains}

When an unhandled error takes the app down, the global handlers write one file, `crash\pending-crash.json` under the station's data root, and keep only the most recent crash. It holds:

- the app version and the Windows version;
- where the error was caught (Dispatcher, AppDomain, TaskScheduler, or Startup for a boot that did not finish);
- the exception type, its message and the full stack text, inner exceptions included;
- the last 60 lines of the newest log file, as context leading to the fault;
- the moment it happened.

Before it is written, the Windows user name and the profile path are replaced with `<user>` and `<userprofile>` wherever they appear. That scrubbing is a safety net, not a guarantee: free-form log lines can carry other names, which is why the dialog shows the whole payload before anything leaves.

## The consent dialog at the next start {#the-consent-dialog-at-the-next-start}

With the switch off, the first visible start after a crash opens **Send crash report?** over the shell: "Ganter Lab closed unexpectedly last time. Sending this report helps us fix it. It contains the error and a short slice of the recent log. Review it below before sending." The **Crash detail** box shows exactly what would be sent, with a **Copy** button that puts the same text on the clipboard ("Copied" for a moment) so you can search it or hand it to support. If the clipboard refuses, the button says "Copy did not work" instead, so a copy that never happened is not taken for one that did; the text stays on screen to select by hand.

| Command | What it does | Greyed when (situation) | Not drawn when (role) |
| --- | --- | --- | --- |
| Always send crash reports automatically (checkbox) | Turns the switch above on when the dialog closes, whether you send this report or not. | While the runtime is stopped (tooltip "Runtime stopped"). The dialog belongs to the shell, so it is still drawn when this page is not. | Never. |
| Don't send | Discards this report and clears the file; you are not asked again for it. | Never. | Never. |
| Send report | Sends it. "Crash report sent" as a notification on success; "Crash report not sent" with the reason when the server could not be reached, in which case the file stays and you can send it now or are asked again at the next start. | Never. | Never. |

A start hidden in the notification area (Start with Windows, or a `--tray` launch) shows no dialog; the report waits for the next visible start. With the switch on, the send happens in the background with no dialog, and a station that was offline keeps the file and tries again at the next start.

The report goes to the Ganter server's feedback endpoint. It is attributed to the Ganter account signed in on the [Account](account) page when there is one, and accepted without an account otherwise. Nothing else leaves the station: there is no usage telemetry.

## The debug commands {#the-debug-commands}

A development build of the app carries two buttons under the switch; an installed release has neither.

| Command | What it does | Greyed when (situation) | Not drawn when (role) |
| --- | --- | --- | --- |
| Simulate a crash (debug) | Throws an unhandled error on the UI thread so the capture path writes a real crash file and the next start exercises the consent flow. | Never. | Not in a release build. |
| Capture screenshot (debug) | Runs the same screenshot capture the agent's UI tools use, in-process, and prints the result under the button: "Saved: `<path>`" or "Capture failed: `<reason>`". On a host without a window the result says the capture is unavailable. | Never. | Not in a release build. |

## What this section does not do {#what-this-section-does-not-do}

There is no log viewer here: the journal lives on [Events](events), on its Console tab, together with the diagnostic capture and the support package. Reports of bugs and requests are on [Feedback](account-feedback). The crash file is not editable from the app, and the app never sends anything without either the switch or the dialog's Send.