Diagnostic Logs

Two log surfaces. Application-defined events go to Dashboard → Logs via Network::SubmitLog. The SDK also writes an exit log under %LOCALAPPDATA%\AtlasAuth\logs\ whenever it ends the process. C++, JS and Python all write it - the JS and Python bindings load the same SDK core.

Where logs actually live

Atlas writes to two places, with different lifetimes and audiences. The dashboard view is server-side and authoritative across all bindings. The on-disk exit log is written by the SDK core on Windows, so every binding writes it.

The log surfaces

Field	Type	Description	Populated when
`Dashboard → Logs`	`server-side`	Merged view of server connection events and your `SubmitLog` entries. Searchable by license / username / HWID / IP / time. The authoritative record across every binding.	always
`%LOCALAPPDATA%\AtlasAuth\logs\atlas_exit_<timestamp>.log`	`on-disk`	One file per abnormal termination. Written before the process ends. Reason + source file + line + local time.	on forced exit

SubmitLog - application-defined events

One line per call. Up to 512 characters, routed to Dashboard → Logs tagged with the current license / account, HWID, and IP. Use it to mark meaningful user actions - order placements, license upgrades, feature unlocks, or any business event worth correlating against later.

Three-binding pattern

// Emit a custom log line to the dashboard's Logs tab.
// Server-side routing - the line shows up under Dashboard → Logs,
// tagged with this app, this license / account, this HWID.
if (!Atlas::Network::SubmitLog("Order #1234 executed")) {
    std::cerr << Atlas::Data::GetErrorMessage() << "\n";
}

On-disk exit log

Every fatal-path termination writes one file before the process ends. The file lives in %LOCALAPPDATA%\AtlasAuth\logs\ with a timestamped filename. The content is a fixed four-line report:

Text

Example exit report

[Atlas Exit Report]
Time:   2026-08-04 14:23:11
Reason: .text section patched (code integrity check)
File:   <source>
Line:   482

Reason - one of the trigger strings below. Not localised; designed to be grepped and matched, not displayed.
File - the originating source module (only the basename; the full path would expose the developer's build environment).
Line - the originating line number.

Exit reason reference

The strings the SDK writes to disk when it terminates. They are not the same as the dashboard's server-side English messages.

Reason → meaning

Field	Type	Description	Populated when
`import init failed`	`string`	Hashed Windows API resolution failed at startup. Heavily hooked or sandboxed environment.	—
`API key not configured`	`string`	`Startup()` called with `Atlas::API_KEY` empty or set to the placeholder string.	—
`login failed: server unreachable`	`string`	TCP connect to the auth server timed out or was refused before login completed.	—
`login failed: invalid license format`	`string`	License string rejected locally before being sent to the server.	—
`debugger detected (IsDebuggerPresent)`	`string`	A debugger is attached. Also queues a ban report against the license or HWID.	—
`IAT hook detected`	`string`	Patched import found in the process IAT. Anti-tamper trip. Often caused by AV / EDR software hooking `VirtualAlloc`, `CreateThread`, etc.	—
`.text section patched (code integrity check)`	`string`	The compiled code section was modified after the image loaded. Runtime patcher, debugger write, or in-process injection.	—
`session token missing or corrupt`	`string`	Session token was zeroed or corrupted after a successful login. Memory scraper or manual tamper.	—
`heartbeat stalled: watchdog not alive (mutual liveness)`	`string`	The SDK heartbeat threads cross-check each other - one side stopped responding inside its timeout.	—
`server requested termination (TERMINATE command / account HB TERMINATE)`	`string`	Auth server sent a kill command. User banned, session revoked, license expired, or admin-initiated remote kill from the dashboard.	—
`ecdh: server signature verify FAILED (nulled server?)`	`string`	The server's handshake signature didn't verify against the pinned keys. Protects against nulled servers returning fake OK responses.	—
`connection lost: heartbeat send failed`	`string`	The persistent connection to the auth server dropped mid-session. Network interruption or server restart. A related reason, `connection lost: network error during heartbeat (check your internet)`, means the network itself failed.	—

What else sits in %LOCALAPPDATA%\AtlasAuth\

The local app data folder holds more than just the logs subdirectory. On a developer machine (any host with VS, MSBuild, VS Code, JetBrains, LLVM, or MinGW detected), the SDK also installs a per-build auto-update helper. End-user machines only get logs\ and, after a tamper trip, pending_bans.dat.

Cache folder contents

Field	Type	Description	Populated when
`logs\`	`subfolder`	The exit logs above. The folder always exists on a machine running an Atlas-built application, end users included.	always
`README.txt`	`text`	Full technical doc for the cache folder and the auto-update helper. Written the first time the cache dir is created on a dev machine.	dev machine only
`commit.sha`	`text`	Last release tag successfully pulled by the auto-update helper. Compared on every build.	dev machine only
`installed.flag`	`text`	Presence = developer acknowledged the auto-update dialog. Suppresses the dialog on subsequent launches.	dev machine only
`declined.flag`	`text`	Presence = developer removed the auto-update helper. It is not reinstalled while this file exists. Delete to opt back in.	dev machine only
`manage_autoupdate.bat`	`batch`	Double-click to install or remove the auto-update helper. Detects current state and prompts for the appropriate action.	dev machine only
`pending_bans.dat`	`binary`	Ban reports queued locally when a tamper check trips (DPAPI-protected). Loaded at the next `Startup()` and reported to the server, so a report survives the process being killed.	after a tamper trip
`dev_marker.json`	`json`	Written by the npm install hook, and by pip when it installs from the source distribution. Marks a developer install.	dev machine only
`pending_update_notice`	`text`	Marker dropped by the auto-update helper when a fresh `Atlas Auth.lib` was downloaded. The next `Startup()` shows a MessageBox with the SHA and timestamp, then deletes the marker.	after each update

Reading the dashboard Logs tab

Filter to the event window - pick the timestamp from the user's report. The dashboard carries the surrounding heartbeat and request frames that the on-disk log does not.
Tag - every event is tagged with license, username, HWID, IP, app. Use these to correlate one user's report against many.
Kind - server-side events use English labels (SUCCESS, DENY, DISCONNECT, BAN, WARN, ERROR, ADMIN). Custom SubmitLog entries sit alongside with your own text.
Cross-check with on-disk - when a process ends with no clean disconnect in the dashboard, read the exit log on that machine for the internal reason (any binding).

Was this page useful?