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:
1 parent
0ddd660089
commit
d20b0fab65
15 files changed
+703
-30
No files matched your search
+17
-1
@@ -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
|
||||
|
||||
|
||||
Reference in new issue
Block a user