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

[Orbita-Media]

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

Cap	0.5.9 (installed build)
OS	Windows 11 Pro, Build 26200
GPU	NVIDIA GeForce RTX 2080 Ti (driver 32.0.15.9579)
WebView2	152.0.4191.53

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 Windows: fatal 0xC000070A — camera enumeration (MF/mfksproxy) closes a handle with a threadpool wait still registered (0.5.9) #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 [Win11] Export exhausts all VRAM/RAM at 1080p/4K, causes unkillable freeze #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.

[linear]

CAP-802