No file path given, output direct.

---

title: System-Maintenance — Lessons owner-dept: IT last-updated: 2026-07-21

System-Maintenance — Lessons

2026-02-06 — Slow computer root-caused to disk exhaustion (consolidated from Slow Computer.md)

Root cause: disk exhaustion C: (6GB) and D: (0GB) — I/O starvation, 30s file opens, intermittent key failures.

Fixes applied then:

• C: recovered 34GB free, D: 193GB free (D: defrag + C: TRIM optimize + temp clear ~0.9GB)
• Disabled startup programs: OneDrive, Acrobat Sync
• Memory 60% (~19GB/32GB) — acceptable; WSL2 ~5GB RAM, uncapped

New utility created: diskcheck — weekly disk monitor, thresholds C:<20GB / D:<50GB, alerts via notify_manager, scheduled Sundays 9am. Committed 7f578b2.

Recurrence (2026-07-21): C: back down to 7.9GB free, diskcheck.log shows no entries since 2026-02-06 despite scheduled task still Enabled. Monitor built to prevent recurrence stopped reporting silently — see STATUS.md issue #2. Exact failure mode Utility-Reliability-Standards exists to prevent: critical process (monitor itself) had no independent verifier checking it still worked.

Root cause found (2026-07-21): scheduled task’s real name DiskSpaceCheck (not diskcheck — util/comment name only), invisible to schtasks /query /tn "diskcheck" and COM GetTask('diskcheck') lookups; found only by grepping full task list by content. Get-ScheduledTaskInfo showed LastRunTime: 7/19/2026, LastTaskResult: 2147942402 (=0x80070002/ERROR_FILE_NOT_FOUND) — task fired weekly whole time, every run failed silently. Cause: task action calls bare uv (not fully-qualified path) while its RunLevel is Highest (needs elevation). Task Scheduler’s elevated-process launch doesn’t resolve Execute through user’s PATH like interactive shell does — even though uv.exe on registry-persisted User PATH, elevated scheduled action still couldn’t find it. Running uv run diskcheck manually in normal (non-elevated) PowerShell worked immediately — util itself never broken, only the unattended, elevated invocation.

General gotcha: any Windows scheduled task with RunLevel: Highest must use fully-qualified Execute path — don’t rely on PATH resolution for elevated actions. If task doesn’t need admin rights, drop RunLevel to Limited entirely instead of patching around it — removes both PATH-resolution risk and separate risk of unattended run silently hanging on UAC prompt nobody’s there to click.

Fixed + verified (2026-07-21): Talbot applied both changes in elevated PowerShell (Execute → full path, RunLevel → Limited). Verification not just “command ran without error” — manually triggered actual scheduled task (Start-ScheduledTask -TaskName 'DiskSpaceCheck'), confirmed LastTaskResult: 0 plus fresh diskcheck.log entry, closing loop on whether unattended path (not just interactive shell) now works. Also caught first fix attempt failing for unrelated reason — pasting two commands as separate lines let Set-ScheduledTask -Action $action execute before $action assigned (terminal paste-order issue); joining with ; on one line fixed it. Worth remembering: “command failed” report needs actual error checked before assuming fix itself wrong — this one sequencing artifact, not bad command.

New utility scripts placed in ad-hoc locations (2026-07-21)

Wrote MonthlyDriveCleanup scheduled task’s script to C:\Scripts\cleanup-c-drive.ps1 — Talbot corrected immediately: Windows utils belong D:\FSS\Software\Utils\Windows\, Python utils PythonUtils\<name>\, WSL-side scripts ~/utils/. Relocated file, updated Scheduled Task’s Execute action to match, re-verified task still ran (LastTaskResult: 0) from new path. Promoted to standing rule: ~/ai-config/AGENTS.md → Dev Standards → “Utility script placement.”

TotalCommander slow file load (~30s, should be <3s)

Observed intermittently; reportedly fixed after reboot. Not reproduced/confirmed — noted here in case recurs, so not re-diagnosed from scratch.