Untersuchen von Speicherleck - Commited Speicher wächst - Heap ist in Ordnung

Question

Ich untersuche ein mögliches Speicherleck in unserer C#/WPF/.NET 4.51-Anwendung.

Ich machte Schnappschüsse von der Anwendung direkt nach dem Start und nach ein paar Stunden, wenn der zugewiesene Speicher über die Spitze wuchs.

Ich überprüft die verwalteten Heap-Instanzen mit VisualStudio-Prozess-Dump-Tool. Alles sah perfekt aus.

die Deponien in WinDbg öffnen scheint dies zu bestätigen, da Heap und Stack in einer Art und Weise wächst ich es (+ 50MB) erwartet (links: Erste dump, rechts: Last-Dump):

Was reizt ich ist, dass die Größe der commited Seiten viel wuchs (links: Ersten dump, rechts: Last-Dump):

auch zeigt VMMap diesen riesigen commited Block als ‚private Daten‘ (nicht auf die Deponien im Zusammenhang Der Screenshot wurde etwa eine Stunde später aufgenommen):

Bitte korrigieren Sie mich:
Da der Heap in Ordnung ist und die privaten Bytes direkt mit VirtualAlloc() zugewiesen werden, kann ich 'unseren' verwalteten Anwendungscode von der Liste möglicher Leckkandidaten ausschließen.

Gibt es eine Möglichkeit, die Ursache des Lecks einzugrenzen?

Answer 1

Danke Alex K. für DebugDiag empfehlen, die eine große Hilfe gewesen war, wie Sie im Screenshot sehen:

Wir verwenden WPF WebBrowser (die unter Verwendung eines ActiveX-Steuerelement implementiert wird) anzuzeigen eine Webseite, auf der viel Java Script Code läuft.

Answer 2

Wir hatten ein ähnliches Problem bei der Arbeit, wir lösten es mit JetBrains Memory Profiler namens dotMemory, es zeigt Ihnen genau, wo das Speicherleck ist.

Ich glaube, sie haben eine 30-Tage-Testperiode.

https://www.jetbrains.com/dotmemory/features/

Answer 3

Aufgrund der Tatsache, dass der Haufen in Ordnung ist und die privaten Bytes mit VirtualAlloc direkt zugeordnet sind() I ‚unseren‘ verwalteten Anwendungscode aus der Liste der möglichen Leck Kandidaten ausschließen.

Sie sehen eine Steigerung von 1,5 GB in <unknown>, der Speicher über VirtualAlloc() zugeordnet ist. Dies kann Speicher von MSXML sein, jeder direkte ("native") Aufruf der Funktion oder von .NET, der seinen eigenen Heap-Manager hat (und somit nicht in die Heap Kategorie fällt, die der C++ - Heap ist).

Da Sie eine .NET-Anwendung haben, ist es wahrscheinlich .NET-Code, der für die 1,5 GB verlorenen Speicher verantwortlich ist. Wenn Sie nur die Sicherungen haben, können Sie sos mit .loadby sos clr laden und !dumpheap -stat verwenden, um zu sehen, wo Ihr Gedächtnis ist. Die Ausgabe listet die Anzahl der Objekte und die Gesamtgröße pro Klasse auf.

Der Speicher ist möglicherweise bereits aus der Sicht von .NET befreit, daher wird er als Free aufgeführt. Sie können auch sicherstellen, dass eine Garbage-Collection stattgefunden hat, andernfalls können falsche Positive auftreten.

Ein Crash-Dump zeigt Ihnen nur den Speicher zu einem bestimmten Zeitpunkt.Die verschiedenen Möglichkeiten, dies mit speziellen Speicherleck-Tools zu analysieren, haben den Vorteil, dass sie die Stack-Spuren von Allokationen verfolgen und einen besseren Einblick darüber geben, was im Laufe der Zeit passiert.