Native crash capture on Windows, and startup steps in crash reports (#1215)

A crash inside a graphics driver left only "an unclean exit between
commands": no backtrace, no module, no hint that it was at startup.

- The crash journal now keeps the startup step the app is in (window,
  graphics instance, surface, adapter request, adapter chosen, device
  creation, renderer and viewport shader compiles, surface configure,
  first frame and its present, running) and the renderer as soon as the
  adapter is picked. egui-wgpu tells the app about its steps through a
  small hook. An unclean exit before the first frame names the step.
- Windows: an unhandled-exception filter (src/native_crash.rs, the one
  Windows-only module allowed unsafe) writes the exception code, the
  faulting module and offset, and a minidump next to the journal; the
  next start puts them into the report.
- The Windows CI job runs a child that faults on purpose and checks the
  report.

Co-authored-by: Claude Opus 5.5 <[email protected]>
This commit is contained in:
bherbruckandClaude Opus 5.5 authored and GitHub committed 2026-10-14 17:53:52 -04:00
1 parent 0ddd660089
commit d20b0fab65
15 files changed
+703 -30

No files matched your search

+17 -1
View File
@@ -58,7 +58,7 @@ A folder `crashes/<YYYYMMDD-HHMMSS>-<signature>/`:
- `command_panic`: a command hit an internal error; it was caught and the design was left unchanged
- `kernel_panic_recovered`: the third-party geometry kernel panicked and was caught. This is harmless on the desktop, but it would crash the web build.
- `panic`: an internal error outside any command
- `unclean_exit`: the app ended without a hook seeing it (an abort, a stack overflow, a segfault, or the process being killed). It is found at the next start.
- `unclean_exit`: the app ended without a hook seeing it (an abort, a stack overflow, a segfault, a crash inside a graphics driver, or the process being killed). It is found at the next start. When the app died while starting up, the message and `location` name the startup step (see below). On Windows, a crash in native code also says the exception, the module it happened in and the offset into it.
- `message`, `location` (file:line), `thread`
- `backtrace`: frames `symbol (file:line)`, without the panic machinery, std internals or the user's home folder
- `app` (version, commit, build date), `system` (OS, architecture, renderer and GPU), `session.uptime_s`
@@ -67,8 +67,24 @@ A folder `crashes/<YYYYMMDD-HHMMSS>-<signature>/`:
- `base`: what the replay starts from (the design before the command, an autosave, a saved file or a new design)
- `count`, `first_seen`, `last_seen`: the same crash repeats only increase `count`
- `notes`: what is missing and why, for example a design too large to copy
- `startup_phase`: `{step, ms}` when the app died before it drew its first frame: the step it
was in (`window`, `graphics instance`, `window surface`, `adapter request`, `adapter chosen`,
`device creation`, `egui renderer (shader compile)`, `surface configure`, `app setup`,
`viewport pipelines (shader compile)`, `first frame`, `first frame (present)`) and how many
milliseconds after launch it began. `system.environment` names the renderer (backend, GPU,
driver) as soon as the adapter is picked, so it is there even when the device never started.
- `native` (Windows): what the exception filter caught: `code`, `name`, `address`, `module`,
`offset` (into the module), `detail` (for an access violation, the address read or written)
and `thread`. The `backtrace` then shows the same in two lines.
- `design.solidcraft`: the design the replay starts from
- `replay.json`: `{"commands": [{command, params}, …]}`
- `minidump.dmp` (Windows, native crashes): the threads' stacks and the loaded modules at the
crash, for WinDbg or Visual Studio. It holds stack memory only, not the design, but it stays
on this computer like the rest of the report; share it only on request.
A crash that ends the process without any exception (a fail-fast, which is how an abort ends on
Windows) still gets the startup step. Windows can also keep its own dumps of every crash: set
`DumpFolder` under `HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps`.
## How it stays cheap and small