#107 - Windows: abrupt exit with no dump or log error (fail-fast?) — tracking - backspace119/Slipstream

backspace119 commented

2026-09-27 16:02:13 +00:00

Owner

Tracking ticket for Windows crashes where the viewer exits abruptly with no crash dump and no error in the log. Dumps, Event Viewer entries and logs for this class of crash go here.

What it looks like

Alchemy.log just stops mid-frame. There is no ERROR, no warning burst, and no "Crash minidump written" line.
No logs/Alchemy.dmp. The viewer's own unhandled-exception filter (LLWinDebug) never ran. That points to a Windows fail-fast termination, which bypasses in-process handlers: heap corruption 0xc0000374, or /GS / security check 0xc0000409. A hard kill is also possible.
Memory looked normal at the time in both cases (VRAM well under budget).

Reports so far (build `91c24ec1bb`, release vk-2026.09.27.8)

Tester	GPU	Log ends (UTC)	Context
summer	RTX 4070 12 GB	15:46:40	53 s after opening a cytube media prim. Video playback has since been confirmed working, so media is probably a coincidence.
Lithus	RTX 3070 Ti 8 GB	15:47:55	No media activity at all.

Both were in the same sim and crashed about 75 s apart.
Avatar 08a3532f-cee5-4876-be59-244db05ff0e6 appears in the last seconds of both logs. Summer's log ends on that avatar leaving; Lithus's ends while that avatar's appearance was being processed and other avatars were arriving. This is a pattern, not proof. It suggests avatar load/unload, see #105.

Previous crash of this class (fixed)

The login crash 0xc0000374 at STATE_SEED_GRANTED_WAIT was clang-cl PCH dropping exception copy constructors, which caused a double free in std::make_exception_ptr. It was fixed in 91c24ec1bb (PCH off for the Windows cross build), so it is not the cause here. The same investigation method applies: symbolize against the release's alchemy-bin.pdb.

Getting a dump

Fail-fast crashes need WER LocalDumps:

Run AlchemyCrashDumps.reg (admin). It sets HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\AlchemyViewer.exe with DumpFolder=%LOCALAPPDATA%\CrashDumps, DumpType=1, DumpCount=5.
After a crash, attach the newest .dmp from %LOCALAPPDATA%\CrashDumps together with Alchemy.log.
Quick alternative: from Event Viewer → Windows Logs → Application, post the "Application Error" entry (exception code + faulting module + offset).

#105: avatars stuck half-loaded after unload/reload (avatar lifecycle, matching the avatar pattern above).
#106: intermittent crash when changing a Graphics > Mesh setting (could be the same class of crash; needs a dump to tell).
#99: hard crash while alt-camming (Linux, GPU DEVICE_LOST). This is a different mechanism, but an alt-cam sweep also loads and unloads a lot of content.
#102: in-viewer crash reporter. It would make collecting these much easier.

Tracking ticket for Windows crashes where the viewer **exits abruptly with no crash dump and no error in the log**. Dumps, Event Viewer entries and logs for this class of crash go here. ### What it looks like - `Alchemy.log` just stops mid-frame. There is no `ERROR`, no warning burst, and no "Crash minidump written" line. - No `logs/Alchemy.dmp`. The viewer's own unhandled-exception filter (`LLWinDebug`) never ran. That points to a Windows *fail-fast* termination, which bypasses in-process handlers: heap corruption `0xc0000374`, or `/GS` / security check `0xc0000409`. A hard kill is also possible. - Memory looked normal at the time in both cases (VRAM well under budget). ### Reports so far (build `91c24ec1bb`, release vk-2026.09.27.8) | Tester | GPU | Log ends (UTC) | Context | |---|---|---|---| | summer | RTX 4070 12 GB | 15:46:40 | 53 s after opening a cytube media prim. Video playback has **since been confirmed working**, so media is probably a coincidence. | | Lithus | RTX 3070 Ti 8 GB | 15:47:55 | No media activity at all. | - Both were in the **same sim** and crashed about 75 s apart. - Avatar `08a3532f-cee5-4876-be59-244db05ff0e6` appears in the last seconds of **both** logs. Summer's log ends on that avatar *leaving*; Lithus's ends while that avatar's appearance was being processed and other avatars were arriving. This is a pattern, not proof. It suggests avatar load/unload, see #105. ### Previous crash of this class (fixed) The login crash `0xc0000374` at `STATE_SEED_GRANTED_WAIT` was clang-cl PCH dropping exception copy constructors, which caused a double free in `std::make_exception_ptr`. It was fixed in `91c24ec1bb` (PCH off for the Windows cross build), so it is **not** the cause here. The same investigation method applies: symbolize against the release's `alchemy-bin.pdb`. ### Getting a dump Fail-fast crashes need WER LocalDumps: 1. Run `AlchemyCrashDumps.reg` (admin). It sets `HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\AlchemyViewer.exe` with `DumpFolder=%LOCALAPPDATA%\CrashDumps`, `DumpType=1`, `DumpCount=5`. 2. After a crash, attach the newest `.dmp` from `%LOCALAPPDATA%\CrashDumps` together with `Alchemy.log`. 3. Quick alternative: from Event Viewer → Windows Logs → Application, post the "Application Error" entry (exception code + faulting module + offset). ### Possibly related - #105: avatars stuck half-loaded after unload/reload (avatar lifecycle, matching the avatar pattern above). - #106: intermittent crash when changing a Graphics > Mesh setting (could be the same class of crash; needs a dump to tell). - #99: hard crash while alt-camming (Linux, GPU `DEVICE_LOST`). This is a different mechanism, but an alt-cam sweep also loads and unloads a lot of content. - #102: in-viewer crash reporter. It would make collecting these much easier.

backspace119 referenced this issue

2026-09-27 16:02:19 +00:00

Avatars sometimes stuck half-loaded after unload/reload (textures or full mesh); survives their relog #105

backspace119 referenced this issue

2026-09-27 16:02:19 +00:00

Intermittent crash when changing a Graphics > Mesh setting #106

backspace119 referenced this issue from a commit

2026-09-27 16:34:50 +00:00

Windows: avatar teardown heap corruption -- no polymorphic new[]/delete[] for collision volumes

backspace119 referenced this issue

2026-09-28 02:29:23 +00:00

Vulkan: handle VK_ERROR_DEVICE_LOST gracefully (log, notify, recover) #135

backspace119 referenced this issue

2026-09-28 02:29:23 +00:00

Vulkan: GPU breadcrumbs for device-lost diagnosis (NV checkpoints / AMD buffer markers) #136

backspace119 commented

2026-09-28 02:29:24 +00:00

Author

Owner

Crash dump from a 1070 Ti tester (0.11.0-beta.1) characterized as VK_ERROR_DEVICE_LOST at the next frame's fence wait (VK_CHECK -> abort, 0xC0000409/7) after a ~12 s GPU stall; second viewer + Overwolf Vulkan overlay were running. Follow-ups: #135 (handle device loss: log/notify/recover) and #136 (GPU breadcrumbs to identify the hanging pass).

Rows
Columns

Windows: abrupt exit with no dump or log error (fail-fast?) — tracking #107

What it looks like

Reports so far (build 91c24ec1bb, release vk-2026.09.27.8)

Previous crash of this class (fixed)

Getting a dump

Possibly related

Reports so far (build `91c24ec1bb`, release vk-2026.09.27.8)