The four queries
terminal / powershell
Get-Service | Where-Object DisplayName -match 'Vendor'
Get-ScheduledTask | Where-Object {$_.TaskPath -match 'Vendor'}
Get-CimInstance Win32_StartupCommand | Where-Object Command -match 'Vendor'
Get-Service | Where-Object BinaryPathName -match 'LocalAppData'Reading the emptiness correctly
- 'Return is nothing' is the evidence you came for — service workloads must be registered to run; absence of the registry line + absence of the binary on disk = absence of the thing;
- DGL-for-displayname trick: matching by path instead of name catches self-renaming services for the (rare) tool that installs with a product-name façade it shuffles;
- Sign in again for per-user artifacts: per-account services instantiate at session boundaries; a line still visible while the folder is gone has one more sign-in to self-clean before it counts as residue;
- Event journal matter: the MsiInstaller uninstall entry (11707) timestamped within minutes of your check is the audit timestamp. Coordinate, don't React: verify service and task deletion from the same session evidence.
When all four queries print nothing, the evidence tail is clean. Cleanup tools exist to accelerate this kind of analysis, not to explain why it's unnecessary.
ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.
