> For the complete documentation index, see [llms.txt](https://stoneforgeteam.gitbook.io/stoneforgeteam-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stoneforgeteam.gitbook.io/stoneforgeteam-docs/development/crash-reports.md).

# Crash windows and reports

When something goes wrong, StoneForge shows what was running, so a crash can be traced to the game, to StoneForge or to a mod.

## The game crashes

A window shows:

* the GML that was running, innermost first: each code entry, with the instance running it;
* the game's own GML call stack: each script and line;
* the native stack: each module and offset.

The full report goes to `<Stoneshard>\dotnet\crash-report.txt`, with the last 512 code entries the game ran. The bridge traces code entries as they start and end for this; it's always on, and cheap.

## C# crashes the game

An exception nothing caught shows a window with its stack trace, and is written to the same report.

## A mod's handler throws

StoneForge catches an exception from a mod's handler (an event, a hook, `Tick`, UI) and the game goes on. A window shows its stack trace the first time for each mod and place, without stopping the game. A mod that keeps failing is paused. The mod is told through `context.Failed`.

The first time any mod's handler throws in a game, StoneForge also keeps a backup of the save being played and asks whether to leave without saving: see [Save backups](/stoneforgeteam-docs/getting-started/save-backups.md#after-a-mods-error).

## A GML error

A GML error shows the game's own error window: the script and what went wrong. `YYToolkit.log` in the game's folder gets the details.

## Settings

|                                                                  |                                                                                                                              |
| ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| `"errorWindows": false` in `<Stoneshard>\dotnet\stoneforge.json` | Turns StoneForge's C# windows off. The game's own crash window always shows.                                                 |
| A file named `yytoolkit-console.on` in `<Stoneshard>\dotnet`     | Opens YYToolkit's console window ("YYToolkit Log") with the game. It's off otherwise; `YYToolkit.log` is written either way. |

```json
{
  "errorWindows": false
}
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://stoneforgeteam.gitbook.io/stoneforgeteam-docs/development/crash-reports.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.