[Win11] Cap.exe grows to 3.8GB RAM / 65k handles while idle in background (no active recording)

Inizia riproducendo il comportamento inattivo di Windows descritto qui e monitora Cap.exe con Task Manager o Process Explorer, tenendo traccia del working set e del numero di handle per diverse ore. Confronta il problema relativo al ciclo di vita degli handle in #2115 con il sintomo multipiattaforma correlato in #1589. Il lavoro è completato quando un processo Cap in background inattivo non mostra più un aumento costante dell’utilizzo della memoria o degli handle.

Summary

Cap.exe sitzt still im Hintergrund (kein aktiver Recording-/Export-Vorgang, kein sichtbares Aufnahme-Fenster) und wächst über die Laufzeit auf mehrere GB Arbeitsspeicher an. Bei einer Laufzeit von 2h08m lagen Cap.exe selbst bei 3,8 GB Working Set und 65.416 offenen Handles (zum Vergleich: GDI-Objekte 88, User-Objekte 75 – also keine UI-/Fenster-Leck-Ursache). Der WebView2-Kindprozess lag separat bei nur 138 MB.

Kein Crash, kein Freeze – der Prozess läuft stabil weiter und wächst nur. Speicher wird laut #1589 (macOS, gleiches Symptom) erst beim vollständigen Beenden von Cap wieder freigegeben.

Environment

Reproduction

1. Cap normal starten und im Hintergrund/Tray laufen lassen (Windows-Autostart oder manuell).
2. Über mehrere Stunden normal weiterarbeiten, ohne aktiv eine Aufnahme zu starten (oder nach einer abgeschlossenen Aufnahme/Session Cap einfach offen lassen).
3. Working Set von Cap.exe im Task-Manager/Process Explorer beobachten.

Beobachtung im Detail

• Kein recordings-Ordner mit kürzlich geänderten Dateien unter %LOCALAPPDATA%\Cap – zum Zeitpunkt der Messung lief keine aktive Aufnahme.
• Kein %APPDATA%\so.cap.desktop\logs-Ordner vorhanden (kein Absturz-/Debug-Log erzeugt).
• 65.416 Handles nach 2h08m ist für einen ansonsten idlen Tauri-Prozess extrem hoch und deutet auf ein Handle-Leck (Dateien, Events, Threadpool-Waits o.ä.) statt auf reines Heap-Wachstum hin – ähnliches Muster wie in #2115 beschrieben (Handle wird geschlossen, während noch ein Threadpool-Wait registriert ist), dort führt es aber zum Absturz statt zu reinem Speicherwachstum.
• Unterscheidet sich von #1761 (RAM-Explosion nur beim Export bei 1080p/4K) – hier lief kein Export.
• Das 0.5.9-Release behebt laut Changelog mehrere kleine Speicherlecks (Kamera-Enumeration, Display-/Geräte-Namen, Mic-Pegelanzeige) ausdrücklich nur auf macOS. Vermutung: dieselbe Leck-Klasse (wiederholte Hintergrund-Abfragen, die nie freigegeben werden) besteht unter Windows weiterhin, äußert sich hier aber zusätzlich als Handle-Leck.

Expected behavior

Ein im Hintergrund laufendes, nicht aktiv aufnehmendes Cap sollte über Stunden hinweg keinen wachsenden Speicher-/Handle-Verbrauch zeigen.