-
Notifications
You must be signed in to change notification settings - Fork 0
Troubleshooting
Start with Logs. Entries are newest first and identify the profile, app, restore result, and reason for skipped or failed work.
Local paths:
%APPDATA%\com.rique.windowautolayout\config.json
%APPDATA%\com.rique.windowautolayout\logs\windowautolayout.log
The active log rotates at 1 MiB and keeps one previous file.
Check the app header after pressing Restore now:
-
Pausedmeans a game or fullscreen app is foreground. -
Monitor missingmeans the profile target is unavailable and fallback is disabled. -
FailedorPartial successshould have per-app details in Logs.
Duplicate restore requests are intentionally rejected while one restore is running.
Check:
- Launch apps that are closed is enabled for explicit/startup restore
- executable path exists when one is configured
- process name and package identity match the installed app
- working directory and arguments are valid
- no Windows permission/elevation prompt is blocking launch
Automatic restore never starts closed apps by design.
Enable:
Restore if minimizedPull hidden/tray windowsWake running tray apps
WindowAutoLayout checks running processes and hidden windows before launching. A current OpenLaunchDeck install is shown through its single-instance --show handoff; OBS uses its Qt tray path.
- Confirm the installed WindowAutoLayout build is current.
- Confirm the OBS entry uses
obs64.exe. - Enable all three hidden/minimized recovery options.
- Remove an overly strict title/class rule.
- Capture the real OBS main frame, not a detached dock.
- Hide OBS to tray and run an explicit restore.
- Check Logs for tray activation, applied layout, and final success.
Do not click OBS before checking whether the restored surface painted by itself; that hides the original failure mode.
Keep the existing OBS process, close the prompt, and verify there is only one OBS entry in the active profile. The restore should wake the existing tray process before considering a launch.
- use a process name plus a useful title rule when one process owns several windows
- remove stale class matching unless it is necessary
- increase detection timeout for slow apps
- keep force-resize on so undersized startup/update surfaces are ignored
- recapture the real final window
- Refresh app data.
- Check the friendly monitor name and physical resolution.
- Check both profile and app-level target monitors.
- Recapture on the intended monitor if the layout was saved before monitor migration.
- Review the monitor-missing fallback in Settings.
Current builds use hardware-backed identities; normal Windows display-number changes should not redirect a saved layout.
Confirm the target display's resolution, taskbar/work area, and scale. Restore uses physical DWM frame bounds, not logical CSS pixels. Logs report expected versus actual rectangles if an app refuses the final size.
Some elevated or fixed-size windows can reject a requested rectangle. Match WindowAutoLayout's integrity level or disable force-resize for an intentionally fixed-size app.
Check:
- Automatic restore is On for the intended profile
- Recover after Show Desktop is enabled
- the target windows are still running
- a game/fullscreen window did not become foreground again
The live state should agree in the tray menu and app header.
Expected Run entry:
"<installed WindowAutoLayout.exe>" --startup-restore
Turn Start with Windows off, save, turn it on, and save again. The app also repairs the registration on launch when saved settings say startup should be enabled.
Remember that Start with Windows keeps the tray app available; Restore on launch separately controls whether a profile is restored at login.
A load failure backs up the existing config with a timestamp before a clean fallback is used. Import parsing and normalization repair duplicate/empty IDs and constrain unsafe delay and rectangle values.
Do not delete backups until the intended profiles have been recovered.
WindowAutoLayout documentation. Repository: https://github.com/Riqqqque/WindowAutoLayout