Where Unity crash logs actually live — editor, builds, and mobile
A crash leaves different artifacts than a normal session — different files, different locations, generated only when the process dies. Windows crash folders, macOS system reports, Android logcat, and iOS crash logs, organized as a request you can hand a tester.
- unity
- crash
- qa
The logs from a game running normally and the artifacts a crash leaves behind are not the same files. Editor.log and Player.log get rewritten every session, but crash dumps and system crash reports only appear when a crash actually happens, in a different location. Where the normal log files live is covered in a separate post; this one is only about what's left after the process dies.
An editor crash and a player crash are different events
There's a distinction worth making first, and it's the thing people searching this topic mix up most.
- An editor crash is the Unity Editor process itself dying. Editor.log only holds what happened up to that point — the actual cause lives in a separate crash report.
- A player crash is the built game dying. Separately from Player.log, each platform writes a crash report to its own fixed location.
Both cases produce the same confused question: the log file looks fine, so why isn't the crash cause in it? The answer is simple — the log and the crash report were never the same file to begin with.
Windows — the crash folder
On Windows, the path depends on whether the Unity Editor process or a built Player crashed. Unity 6.6's log-file manual lists %TMP%\Unity\Editor\Crashes\ as the Editor default and notes that -crash-report-folder can override it. The same version's Windows.CrashReporting.crashReportFolder API reference lists %TMP%\<CompanyName>\<ProductName>\Crashes\ for Player crash reports. Because Unity versions and launch options can differ, query that API in the Player for the actual path.
%TMP%\Unity\Editor\Crashes\ (Unity 6.6 Editor default)
%TMP%\<CompanyName>\<ProductName>\Crashes\ (Unity 6.6 Player default)
The crash artifacts generated can vary by Unity version and configuration. A separate process is what actually writes into this folder — that's next post's topic. When asking a tester for this, first identify whether the Editor or Player exited, then ask for the latest matching Crashes folder.
macOS — the system crash reporter
On macOS, it isn't Unity's own crash folder — the OS's system crash reporter handles it, and the location is the same whether the editor or the player crashed.
~/Library/Logs/DiagnosticReports/
Reports land as .ips files, named with the process name and a timestamp. Go to Folder in Finder gets you there directly, and Console.app can read them too.
Android — logcat is the practical answer
On a native (engine-level) crash, Android writes a detailed report under /data/tombstones/. That path is hard to reach without root, though. In practice, dumping logcat right after the crash is the answer that actually works.
adb logcat -d > crash.txt
A native crash shows up in the log with the signal and a backtrace attached. Unity's -androidChainedSignalHandlerBehavior argument configures the native crash-handler chain. The legacy value was removed in Unity 6.6, so check the documentation for your Unity version before using it.
iOS — Xcode Organizer
On iOS, distinguish logs from a connected device from reports for distributed builds. For a connected device, use Window → Devices and Simulators → select the device → View Device Logs in Xcode. Crash reports from TestFlight or App Store builds are available in the Crashes section of Xcode Organizer; TestFlight reports do not depend solely on custom file logging. On the device, you can also find and share reports under Settings → Privacy & Security → Analytics & Improvements → Analytics Data. See Apple's guide to acquiring crash reports and diagnostic logs.
Summary — what to ask a tester for
| Platform | Crash artifact | How to request it |
|---|---|---|
| Windows | The Editor or Player Crashes folder | Identify the process and Unity version, then collect the latest folder |
| macOS | ~/Library/Logs/DiagnosticReports/*.ips | Pin down the newest file by timestamp |
| Android | logcat (tombstone if rooted) | adb logcat -d dumped right after |
| iOS | Xcode Organizer reports for distributed builds, or device logs | Use Organizer's Crashes section or Devices and Simulators |
All four platforms share one trait — the artifact disappears or gets overwritten once the moment passes. Android's logcat buffer is circular, so it gets overwritten if you wait; Windows and macOS reports pile up with every relaunch, making the old one harder to find. Collecting it right after witnessing the crash matters more than memorizing the path.
Our own Rekon sidesteps this whole collection procedure — one hotkey the moment someone sees something wrong captures the preceding video, logs, and game state. That said, a hard crash that kills the process instantly leaves no time to press a hotkey. For that case, the table above is still the only lead you have.