Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
#2,214 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
50/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust, tauri

Hướng nghiên cứu

Bắt đầu bằng cách tái hiện hành vi nhàn rỗi trên Windows được mô tả ở đây và theo dõi Cap.exe bằng Task Manager hoặc Process Explorer, ghi lại working set và số lượng handle trong vài giờ. So sánh mối lo ngại về vòng đời của handle trong #2115 với triệu chứng liên nền tảng liên quan trong #1589. Được xem là hoàn tất khi một tiến trình Cap chạy nền ở trạng thái nhàn rỗi không còn cho thấy mức sử dụng bộ nhớ hoặc handle tăng đều đặn.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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 #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.

Ngôn ngữ chính
Rust
Star
23k
Fork
2k
Merge trung bình
19 giờ 50 phút
Pull request đã merge (30 ngày)
72

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của CapSoftware/Cap

Tất cả issue của CapSoftware/Cap

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.