Possible database corruption and 100% CPU after Windows updates

[ArthurusDent]

It looks like whenever there was the monthly Windows update, the aw-server-rust database gets somehow corrupted. It doesn't seem to happen with normal reboots.

After the Windows update was applied and the system has rebooted, AW starts, but aw-server-rust seems to hit one thread of the CPU with 100%. The web GUI ist also much slower to respond and I sometimes get notified that connection to the server was lost. The performance problems never resolve, even after hours.

The fix is to restore the AW folders from a backup. That's why I suspect that the database gets somehow corrupted.

For some reason there are no logs available for the time during the Windows update. I've uploaded the logs after a manual start of AW after the Windows update and reboot of the system.

System:
Windows 10 22H2
ActivityWatch: v0.12.2 (rust)

Logs:
activitywatch.zip

[TimeToBuildBob]

This is very likely the same root cause as #405 — a panic inside the server (from corrupt/unexpected data after an unclean shutdown during Windows Update) poisons the Mutex lock on the datastore, causing 100% CPU on the affected thread as subsequent requests fail in a tight loop.

What probably happened:

1. Windows Update forces a shutdown while aw-server-rust is writing to SQLite
2. The WAL (write-ahead log) or journal file ends up in an inconsistent state
3. On restart, a query hits the corrupted data, triggers a panic (likely in aw-transform — see "poisoned lock: another task failed inside" #405 for the exact backtrace)
4. The Mutex is poisoned, all subsequent DB operations fail, CPU spins

Mitigations already applied in newer versions:

• 1f4f07d (PR fix: period_union with empty args #366): Fixed unwrap() on None in period_union.rs that was a common panic source
• dc70318 (PR Replace panics with results & better option types #437): Replaced many panics with proper Result types throughout the codebase

Recommended: Upgrade to v0.13.1+ which has these fixes. If the issue persists, try running sqlite3 sqlite.db "PRAGMA integrity_check;" on the database file to confirm whether corruption is present.

Normal reboots don't trigger this because the OS gives processes time to flush + close cleanly, whereas Windows Update may forcefully terminate the server mid-transaction.

[TimeToBuildBob]

This is a concerning report — database corruption after Windows updates is a pattern that suggests improper shutdown handling.

Likely cause: Windows updates force-kill processes during reboot. If aw-server-rust has uncommitted SQLite transactions (WAL mode), the WAL/SHM files may be left in an inconsistent state. On next boot, SQLite tries to recover from the WAL journal, and if the journal is corrupted, it enters a recovery loop that pegs 100% CPU.

Diagnostic steps:

1. After reproducing, check if -wal and -shm files exist alongside the database:

   dir %LOCALAPPDATA%\activitywatch\activitywatch\aw-server-rust\sqlite*
   

2. If both exist and the -wal file is large (>1MB), that confirms an incomplete transaction recovery.

Potential fixes:

• Checkpoint on shutdown: aw-server-rust should run PRAGMA wal_checkpoint(TRUNCATE) on clean shutdown to flush the WAL
• Periodic checkpoints: Run checkpoints periodically (every few minutes) to minimize data at risk
• Windows shutdown hook: Register for the Windows shutdown notification (WM_QUERYENDSESSION) to flush before force-kill

Workaround: Before Windows updates, cleanly shut down ActivityWatch via the tray icon. This ensures SQLite completes its WAL checkpoint.

The fact that restoring from backup fixes it confirms the database corruption hypothesis. If you can capture the exact error from the logs after a Windows update, that would help pinpoint whether it's WAL corruption or something else.

[TimeToBuildBob]

Update: Partial mitigations merged

Several improvements have landed that address parts of this:

• PR fix(datastore): handle commit failures gracefully instead of panicking #572 (merged 2026-03-05): Graceful error handling on database commits — prevents panics that could worsen WAL corruption
• Earlier PRs fix: period_union with empty args #366, Replace panics with results & better option types #437: Fixed other panic sources in the server

These don't fully prevent the root cause (Windows Update force-killing the server mid-transaction), but they make recovery more reliable. The server should no longer spin at 100% CPU on restart in most cases.

Workarounds until a proper Windows shutdown hook is implemented:

1. Manually close ActivityWatch before Windows updates
2. If stuck at 100% CPU: kill aw-server-rust, delete the -wal and -shm files next to the database, restart
3. Use the zip/tar release instead of AppImage if you also experience #1207

If you're still hitting this on recent versions, please share your aw-server version and any error output.