How to find application log files on Windows
Roaming and Local AppData, ProgramData, the install directory and Event Viewer: which one an application writes to, and how to tell which without guessing.
Windows has no single log directory. An application chooses where to write, and which of four conventions it picks depends on who it logs for, whether it runs as a service, and how it was installed. Once you know the four, a path you have never seen before is usually readable at a glance.
The four places
| Location | Expands to | Used for |
|---|---|---|
| %APPDATA% | C:\Users\you\AppData\Roaming | Per-user data meant to follow the account onto another machine |
| %LOCALAPPDATA% | C:\Users\you\AppData\Local | Per-user data tied to this machine. Most desktop apps log here |
| %PROGRAMDATA% | C:\ProgramData | One copy for every account. Services and machine-wide components |
| %PROGRAMFILES% | C:\Program Files | The install directory itself. Older software, and games |
A logs directory should not really be roaming - nobody wants yesterday’s crash dumps syncing to a new desktop - but plenty of applications put it there anyway, because that is where the rest of their per-user state already lives. Slack logs under %APPDATA%\Slack\; Visual Studio Code under %APPDATA%\Code\logs\. Both of those are Roaming.
%LOCALAPPDATA% is the more common home for anything large or machine-specific. Google Chrome writes its debug log to %LOCALAPPDATA%\Google\Chrome\User Data\chrome_debug.log, and Microsoft Teams - the current one, which ships as a Store package - writes under %LOCALAPPDATA%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\. That Packages\ tree is not a coincidence, and it is covered in why log paths differ between installer types.
%PROGRAMDATA% is where anything running as a service ends up, because a service has no user profile to write into. Docker Desktop splits along exactly that line: the desktop application logs to %LOCALAPPDATA%\Docker\log.txt while its privileged service logs to %PROGRAMDATA%\DockerDesktop\service.txt.
The install directory is the oldest convention and it has not died. Steam still keeps C:\Program Files (x86)\Steam\logs\, which is also why those files need an elevated editor to delete.
Which one an app uses
Three questions settle it most of the time:
- Does it log before anyone signs in? Then it cannot be under a user profile. Look in
%PROGRAMDATA%or the install directory. - Is there a separate service or updater? Expect two log locations, not one - a per-user one and a machine-wide one, as with Docker Desktop above.
- Did it come from the Microsoft Store? Then the per-user path is inside
%LOCALAPPDATA%\Packages\even if the documentation says otherwise.
Finding it anyway
When the application is not in the catalogue and its documentation is silent, the fastest honest method is to look at what it just touched. Reproduce the problem, then sort by modified date:
Get-ChildItem $env:LOCALAPPDATA, $env:APPDATA, $env:PROGRAMDATA -Recurse -Include *.log,*.txt -ErrorAction SilentlyContinue | Where-Object LastWriteTime -gt (Get-Date).AddMinutes(-5) | Sort-Object LastWriteTime -Descending | Select-Object -First 20 FullName, LastWriteTime
Anything written in the last five minutes is a candidate. If that comes back empty, the application is either logging somewhere unusual or not logging at all until you switch it on - a verbose or debug flag that has to be set first is common enough that the catalogue records it in an app’s notes.
%TEMP% is worth a look too. Installers in particular write there: %TEMP%\MSI*.log for a Windows Installer package, when it has been told to log at all.
The Event Log is not the same thing
Event Viewer shows the Windows Event Log, which is a structured system service applications can write into. It is not where most application logs live. A well-behaved service writes its start and stop events there and its detail to a file; a desktop application often writes nothing there at all. Check it for crashes (Application log, source Application Error) and treat the file on disk as the real log.
Search the catalogue for the application by name and it will give you the exact path, qualified by installer type and architecture, rather than the folder it probably lives in.