Use LogMate in Trainz to capture runtime errors, isolate faulty assets, read warnings correctly and choose the safest fix.
To use LogMate in Trainz, open it from the Trainz Launcher’s Developer menu before starting the simulator, clear the existing messages, reproduce the fault once, then inspect the first error generated at that time. Treat warnings as clues, not proof; confirm any named asset in Content Manager before repairing or deleting it.
How do I capture a useful Trainz LogMate trace?
Open LogMate from the same Trainz Launcher that starts the affected installation, especially if several Trainz editions are installed.
- Return to the launcher. Close the active Driver or Surveyor session. If you are investigating a startup failure, leave Trainz itself closed.
- Clear the old log. Use
Developer > Clear Logswhere that command is available. This prevents messages from previous sessions being mistaken for the new fault. - Open LogMate. Choose
Developer > Show Logs, then leave the log window running. The command’s exact placement can differ between Trainz editions and operating systems. - Start Trainz from that launcher. Do not run a LogMate executable copied from another Trainz installation, because it may monitor the wrong build or data environment.
- Reproduce one problem. Load the affected route, session or asset and perform the shortest sequence that triggers the error.
- Preserve the result. Note the time and copy the relevant message block before clearing the log or starting another test.
The mistake we see constantly is opening LogMate after the failure. That misses startup, asset-loading and script-initialisation messages which may contain the actual cause.
Trainz and Train Simulator Classic use different logging workflows despite the shared utility name. If the product is Train Simulator Classic, use our separate LogMate procedure for that simulator.
Which LogMate messages matter?
The most useful entry is normally the first new error immediately before the visible fault, not the final line or the message repeated most often.
| Log entry | What it usually means | Best next step |
|---|---|---|
| Asset KUID, package name or script stack | The fault is associated with particular content, although a shared dependency may be the real cause. | Find the asset in Content Manager and inspect its errors, warnings and dependencies. |
| One error followed by many load failures | The later messages may be a cascade caused by the first failure. | Resolve the earliest error, restart Trainz and test again before touching the others. |
| Warnings without a matching symptom | Trainz can log compatibility, optional-resource and diagnostic warnings while continuing normally. | Do not delete or repair content solely because a warning exists. |
| Renderer, device or memory-related failures across built-in content | The problem is more likely to involve graphics settings, drivers or available resources than one downloaded asset. | Test a simple built-in route with reduced graphics settings before altering content. |
| Database or index failures affecting unrelated assets | The content database may need checking rather than individual assets being removed. | Close Trainz and use the launcher’s database-repair function. |
Read entries by timestamp and severity rather than colour, as presentation can vary between builds. Repetition shows that an error is persistent; it does not prove that the repeated component started the problem.
How do I identify a faulty Trainz asset from LogMate?
Use the KUID or asset name from LogMate as a lead, then confirm the diagnosis in Content Manager before making changes.
- Search for the KUID. An identifier displayed as
<kuid:...>can normally be searched directly in Content Manager. - Inspect its status. Check whether the asset is faulty, missing dependencies, obsolete, modified or open for edit.
- Follow the dependency chain. If several parent assets fail around one dependency, repair that shared dependency first. Deleting every parent asset only creates more missing-content errors.
- Choose the least destructive fix. Restore a missing dependency, revert an incorrectly modified built-in asset, or reinstall a known-good copy of custom content.
- Retest with a clean log. Clear LogMate, restart Trainz and repeat the same action. A fix is confirmed only when the symptom and its originating error are gone.
A script name in a stack trace may belong to a library used by many routes or sessions, so it should not automatically be blamed. Check the asset that invoked it and the dependencies immediately preceding the exception.
If a confirmed third-party asset must be removed, follow our safe Trainz content-removal process rather than deleting files directly from the user-data folders.
Why does LogMate show errors when Trainz still works?
LogMate records diagnostic events as well as faults that stop Trainz, so an error or warning is only actionable when it matches the timing and behaviour of the problem being investigated.
Routine messages can come from unused content, optional dependencies, older asset conventions or a feature Trainz skipped successfully. If the simulator loads and the affected route behaves normally, avoid changing content merely to produce an empty log.
Conversely, database errors spread across unrelated assets or a consistent failure during every launch deserve attention. Our Trainz startup and database-repair checks cover that broader case without treating every log warning as fatal.
What if LogMate records no useful error?
An empty or irrelevant trace usually means LogMate was opened too late, attached to another Trainz installation, or the problem belongs in Content Manager rather than the runtime log.
- Start LogMate before Trainz and reproduce the fault without launching unrelated routes first.
- Open it through the launcher for the exact Trainz build being tested.
- Compare the affected route with a simple built-in route. If only one route fails, concentrate on its session, scripts and dependencies.
- Check Content Manager directly for faulty or missing dependencies when an asset refuses to appear but generates no runtime error.
- After a hard crash, preserve whatever was written before relaunching. The final entry may be incomplete and may not name the component that caused the crash.
When sharing a trace, include the Trainz build, route or session name, reproduction steps, the first relevant error and a small block of surrounding messages. Review copied logs first, because local paths can expose the Windows or macOS account name.