WSL2 watcher causes continuous full Win32_Process enumeration once per second

[mgrant0]

Environment

• WinCryptSSHAgent v1.1.9
• Windows 11 Home 25H2 (10.0.26200, UBR 8973)
• WSL2 in active daily use

Summary

utils/processnotify.go subscribes with:

SELECT * FROM __InstanceOperationEvent WITHIN 1
WHERE TargetInstance ISA 'Win32_Process' AND TargetInstance.Name='wslhost.exe'

used by app/vsock.go's wsl2Watcher to detect WSL2 VM start/stop.

Win32_Process has no WMI event provider, so WMI services this subscription by
enumerating every process on the system once per second and diffing the
results. The TargetInstance.Name filter is evaluated after that enumeration,
so it does not reduce the cost.

Evidence

Captured from the Microsoft-Windows-WMI-Activity ETW provider (15s window,
agent otherwise idle):

GroupOperationId = 1277; Executing polling query select * from Win32_Process
in namespace //./root/CIMV2; ClientProcessId = 13320; IntervalMs = 1000

13 such enumerations in 15 seconds, continuously, for the lifetime of the agent.

Impact

Modest but permanent: one full process enumeration per second for as long as the
agent runs. On a laptop this is a small, constant CPU and battery cost. I want to
be upfront that this is not causing me a serious problem — I found it, with the assistance of Claude Code, while
diagnosing a much worse offender on this machine (an OEM utility running the same
kind of subscription at WITHIN 0.1, twice, which was pegging a core). This one
is roughly 20x lighter. Filing it as an efficiency improvement, not a bug.

Possible improvements, roughly in order of effort (Claude's recommedation):

1. Increase the WITHIN interval. WSL2 VM start/stop almost certainly does not
   need 1-second detection latency; WITHIN 5–WITHIN 15 would cut the cost
   proportionally, and there is already a 15s/60s polling fallback path.
2. Use __InstanceCreationEvent + __InstanceDeletionEvent rather than
   __InstanceOperationEvent. The latter also delivers modification events,
   which fire constantly for processes and are not needed here.
3. Switch to the ETW-backed Win32_ProcessStartTrace / Win32_ProcessStopTrace
   classes, which are genuinely push-based and do not poll. (Caveat: these may
   require elevation — worth verifying, since the agent runs unelevated.)
4. Alternatively, watch the Hyper-V namespace (root\virtualization\v2,
   Msvm_ComputerSystem), which has real event providers, instead of inferring
   VM lifecycle from wslhost.exe processes.

Happy to test a patch on this machine. Hope this is helpful.