WinSTTDebug Mode
Gather logs and a one-click diagnostic bundle so a maintainer can fix a bug fast — straight from Settings → About → Diagnostics.
When something goes wrong, the fastest path to a fix is attaching a diagnostic bundle to your bug report. WinSTT zips its logs plus a system summary into one file from Settings → About → Diagnostics — no command line required.
What gets logged
WinSTT writes rolling logs in its app log folder. They are written at verbose level all the time, so the full trace is captured even on a normal launch — you do not have to reproduce in a special mode first.
| File | Source | Rotation |
|---|---|---|
| WinSTT.log | Tauri/Rust backend plus renderer diagnostics. | Managed by the Tauri log plugin. |
| debug.log / debug.old.log | Legacy-compatible app log names, included when present. | Rolls when configured by the app. |
| stt-server.log | Legacy-compatible engine log name, included when present. | Included only if a previous or compatibility path wrote it. |
Installed builds store logs under the WinSTT app-data log folder; portable builds use their local Data/logs folder. Use Open Logs Folder from Settings → About → Diagnostics instead of guessing the path.
The log does not contain your audio
Audio frames are processed in memory and discarded; only summary statistics (chunk count, VAD decision, transcribed-text length) reach the log. Transcribed text is logged so you can match "what I said" to the model's output. Nothing is uploaded — the log stays on your machine until you choose to share the bundle.
Gather a diagnostic bundle
Two actions in Settings → About → Diagnostics do everything. Open Settings and go to the About tab.
Opens the active log directory in File Explorer so you can inspect the current logs directly.
Zips the logs plus a system-info summary into a single .zip, then offers to
reveal it in Explorer. This is the file to attach to a bug report.
Reproduce the bug
Do whatever triggers the problem, and keep it short so the relevant lines are recent —
debug.logrolls at 5 MB, so older context can age out of the file.Save the bundle
In Settings → About → Diagnostics, click Save Diagnostic Bundle. A save dialog opens, pre-filled with
winstt-diag-<timestamp>.zipon your Desktop. Pick a location and confirm.Reveal and attach
When the zip is written, WinSTT shows a "Diagnostic bundle saved" dialog with an Open folder button. Attach the
.zipto your GitHub issue.
What the bundle contains
The archive holds every log that currently exists plus a freshly generated system summary at the zip root:
winstt-diag-<timestamp>.zip
├── WinSTT.log (Tauri/Rust app log, when present)
├── debug.log (legacy-compatible app log, when present)
├── debug.old.log (only if a rotation happened recently)
├── stt-server.log (legacy-compatible engine log, when present)
└── system-info.txt (versions, OS, CPU, RAM, GPU)system-info.txt is a plain key-value list: WinSTT / Tauri / WebView versions, platform and architecture, and portable-mode status. No settings, API keys, or tokens are written into the bundle.
If the zip is over GitHub's 25 MB limit
Attach system-info.txt plus the tail of each log inline
(Get-Content -Tail 500 "$env:APPDATA\WinSTT\debug.log"), and upload the full
bundle to a gist or a cloud-drive link.
Reading the logs yourself
Both files share the [HH:MM:SS.mmm] [scope] message format. Filter by scope to find the relevant lines.
Application log:
| Scope | What it covers |
|---|---|
| backend / winstt | Rust backend startup, model loading, and command handling. |
| ipc / relay | The bridge between Tauri commands/events and renderer windows. |
| settings | Settings persistence. Look here when a setting appears to revert. |
| hotkey | Global hotkey registration. A register false line means another app claimed the chord. |
| diag-bundle | The bundle generator itself. |
| tray-menu | Tray-menu window placement and lifecycle (show, reanchor, hide). |
Engine compatibility log, when present:
| Scope | What it covers |
|---|---|
| bootstrap | Engine wiring at startup — the first lines say which audio device, VAD, transcriber, and wake-word backend were resolved. |
| recorder.application | RecorderService lifecycle and state-machine transitions. |
| recorder.pipeline | The VAD loop, per-chunk decisions, and turn boundaries. Very chatty. |
| model_swap | Hot-swap of STT models. Failures here usually mean a quantization that is incompatible with the chosen backend. |
Verbose terminal output
The file log is always verbose, but the terminal is quiet by default so dev runs aren't flooded with per-keystroke traces. To mirror the verbose stream to the console for live tailing, launch with --verbose (or set WINSTT_VERBOSE=1):
& "$env:LOCALAPPDATA\Programs\WinSTT\WinSTT.exe" --verboseThis only changes what prints to the terminal. The bundle and the log files already hold the full trace either way.
Crash reports
If a crash escapes, WinSTT forwards a redacted exception payload to Sentry. This is opt-out at Settings → General → Anonymous crash reports; the redactor strips file paths, the home directory, and anything that pattern-matches an API key. Sentry sees the crash, not the behavior leading up to it — so it is never a substitute for the diagnostic bundle, which captures the latter.
Related
Troubleshooting
Common issues — stuck reconnecting, no paste, missing audio — and their fixes.
CLI & Signals
Every command-line flag, including --verbose.
Recording modes
Push-to-talk, toggle, listen, and wake-word — and when to use each.
Choose a model
Browse the catalog and pick the right accuracy/speed trade-off.