Log Files

Log Files

Emutastic writes a small set of diagnostic log files while it runs. They exist because most problems get reported from release builds where there's no debugger attached — a log file is often the only way to see what the app was doing when something went wrong. If you file a bug report, the relevant log from the table below is usually the most useful thing you can attach.

Every log is size-capped and rotates automatically — none of them can grow out of control. The cap is 2 MB per log (the main emulator.log gets 5 MB). When a log hits its cap it is renamed to a single backup (.1, or emulator.old.log) and a fresh file is started, so the worst case for any log is roughly double its cap on disk. The entire set together stays in the tens of megabytes.

All logs are safe to delete at any time. The app recreates them as needed.

Where they live

Almost everything is in the Logs folder inside your data folder (in Portable Mode, that's PortableData\Logs next to the .exe). Two exceptions, kept where they are so existing instructions and bug-report habits keep working:

• controller-diag.log — next to Emutastic.exe
• import_debug.log — in the data folder root

The logs

File	What it records	Max size
emulator.log	Everything during a game session: core loading, video/audio setup, controller polling, achievement activity, window teardown. The first log to check when a game won't launch, shows a black screen, or crashes.	5 MB
ra.log	RetroAchievements data traffic — API calls, cache activity, and parse failures for the Achievements tab, friends, and leaderboards.	2 MB
cloudsync.log	Cloud save sync activity — uploads, downloads, conflicts, and cleanup, whether triggered from Preferences or automatically around a game session.	2 MB
cores.log	Core downloads and update checks — which URLs were fetched and whether they succeeded.	2 MB
screenscraper.log	Artwork and metadata lookups against ScreenScraper, including quota and login problems.	2 MB
import_debug.log	ROM import flow — console detection, archive extraction, and the artwork backfill that runs after import.	2 MB
controller-diag.log	Controller detection and hot-plug events — which devices were found and what they identified as.	2 MB
recording_debug.log	Gameplay recording lifecycle — capture setup, encoding, and teardown.	2 MB
vulkan_debug.txt	Low-level Vulkan renderer activity for the systems that use it. Only appears when those systems run.	2 MB
ui_freezes.log	One line whenever the UI thread stalls for half a second or more, with the window that was active.	2 MB
startup_timings.log	How long each startup phase and navigation click took.	2 MB

Which ones are permanent and which are temporary

The logs fall into two groups:

Long-term diagnostics — these stay. They cover the subsystems that talk to the outside world (cores, artwork, achievements, cloud sync) or depend heavily on your specific setup (controllers, imports, emulation itself). When something breaks in those areas, the cause is almost always environmental — a network hiccup, an unusual ROM, a particular controller — and these logs are how that gets diagnosed remotely:

emulator.log, ra.log, cloudsync.log, cores.log, screenscraper.log, import_debug.log, controller-diag.log

Temporary instrumentation — these exist to hunt specific classes of bugs that are still being polished, and will likely be removed (or disabled by default) as the app matures:

• ui_freezes.log and startup_timings.log watch for UI responsiveness problems. Once stutter reports stop coming in, the watchdog behind them goes away.
• vulkan_debug.txt is verbose renderer tracing left over from bringing up the Vulkan presentation path; it gets quieter or disappears as that code stabilizes.
• recording_debug.log covers the recording feature, which is newer than most of the app; it follows the same path once recording has been boring for a few releases.

Nothing in any log contains personal information — file paths on your own machine and your RetroAchievements username are the most identifying things that appear.