TaskAnalyzer

A Windows desktop application that shows what runs on the computer, which processes look unusual and what uses the most resources. Every finding comes with its reason – the goal is not to deliver a verdict but to give enough information to judge for yourself.

TaskAnalyzer is not an antivirus. It works with heuristics, which by design produce false positives: an unsigned tool from a small developer gets points just like a genuinely suspicious file. A high score means "take a look", not "this is malware".

Running it

dotnet run --project src/TaskAnalyzer.App

Release build – one self-contained, portable exe (the same one the app store and the updater distribute):

dotnet publish src/TaskAnalyzer.App -c Release -r win-x64 -o publish

Requires Windows and the .NET 10 SDK to build. The shared updater (TomLabs.AutoUpdate.Avalonia) comes from nuget.org, so a plain git clone is enough.

TaskAnalyzer --health prints {"status":"Healthy","version":"…","name":"taskanalyzer"} – the desktop equivalent of a web app's GET /health.

Administrator rights

Without elevation the path, digital signature and command line of part of the processes (typically system processes and processes of other users) cannot be read. The app says so in the header and offers a restart as administrator. The analysis runs without it too, it just misses those processes – they are listed under Not verified.

The window

• Views in the sidebar: all processes, suspicious (score 15 and up), resource hogs, unsigned, not verified – each with a live count – and a snapshot summary (processes, total CPU, private memory, refresh interval).
• Process table sorted by risk score, then CPU; any column sorts on click. The filter box searches name, PID, path and description.
• Detail panel with every finding and its reason, path, command line, signature, parent process, user, elevation, start time, file age and size.
• Command palette (Ctrl+K): jump to any process by name or PID, switch views, run actions.
• Logs (Ctrl+L): the application log live, filterable by level and text, plus the daily log files.
• System / Light / Dark theme (Ctrl+Shift+L cycles, System follows Windows live), remembered for the next start; the version is in the header.

What it collects

Rates (CPU, disk) are computed as the difference to the previous snapshot, so the first pass is only a reference and the values appear with the second refresh.

Rules

Every rule adds points to the risk score (0–100). The score is a plain sum capped at one hundred – a deliberately simple model, so the result can be explained.

Findings RES001–RES005 (CPU, memory, disk, handles, threads) form a separate category and do not raise the score – a memory hog is not the same as a suspicious process, and mixing both into one number would only confuse. The table marks them with a purple dot.

Score levels: 60 and up high (red), 35 medium (amber), 15 low (grey), below 15 an outlined badge.

Tuning thresholds

The resource thresholds live in AnalyzerOptions – "a lot" means something else on a gaming PC than on an office laptop. A new rule is an IProcessRule implementation added to RuleEngine.CreateDefaultRules().

Caveats when reading the results

• Windows recycles PIDs. When a parent process exits, its number may go to someone else. A parent–child relation is therefore only accepted when both start times are known and the parent started first. Without that, svchost.exe would report a wrong parent all the time.
• Catalog signatures. A large part of the system files carry no embedded signature but are signed in a .cat catalog. Checking only the embedded signature would report half of Windows as unsigned.
• Kernel pseudo-processes (System, Registry, memory compression) hold thousands of handles even on a healthy system, so only their CPU usage is evaluated.

Log, settings, updates

• Log: Serilog, daily files taskanalyzer-YYYYMMDD.log in %LOCALAPPDATA%\TaskAnalyzer\logs, kept for 14 days; the level comes from LogLevel in the settings. Each process is logged once when it first reaches a medium score, so an incident leaves a trace. Command lines of other processes are never logged.
• Settings: %APPDATA%\TaskAnalyzer\settings.json (theme, refresh interval, update channel, log level and folder). TASKANALYZER_DATA_DIR points the app at another folder.
• Updates: through TomLabs.AutoUpdate from the TomLabs app store (https://apps.tomlabs.cz). The app checks at startup and every six hours, shows a banner in the status bar and verifies the signed manifest and the SHA-256 of the download. Builds from master go to the nightly channel, v* tags to stable (azure-pipelines.yml).

Structure

src/TaskAnalyzer.Core     data collection and rules, no UI dependency
  Collection/             process access, signatures, WMI
  Analysis/Rules/         the individual heuristic rules
src/TaskAnalyzer.App      Avalonia UI ("ops console" style shared with the other TomLabs desktop apps)
tests/ui-fixture          settings for scripted UI runs (see CLAUDE.md)
tools/Make-Icon.ps1       regenerates icon.png and the exe icon

The core knows nothing about the UI, so a console tool or a periodic JSON export can be built on top of it.

Not there yet

• network connections of each process and correlation with autostart entries (Run keys, services, scheduled tasks),
• checking the hash against VirusTotal,
• metric history over time and a report export,
• ending a process directly from the app.