C# Memory-Leck, Tracking-Techniken und Tools

Question

Die App, die ich schreibe leidet sehr dramatisch aus einem Speicherleck. So gut wie das gesamte Objektmodell bleibt im Speicher, wenn ein Benutzer ein geladenes Projekt schließt. Ich weiß das, weil das Schließen eines Projekts in meiner App kaum Auswirkungen auf die Speichernutzung im Task-Manager hat und das Öffnen eines neuen Projekts es fast jedes Mal verdoppelt. Ich habe jetBrain dotTrace Memory 3.5 heruntergeladen, aber es gibt wenig (keine) Anweisungen zur Verwendung. Ich habe irgendwie herausgefunden, wie man es benutzt und es zeigt, dass das gesamte Objektmodell noch im Speicher ist, wenn ich einen Schnappschuss mache, nachdem ein Projekt geschlossen wurde. Wenn ich meinen Projektcode durchforste, sehe ich keinen Grund dafür. Kennt jemand irgendetwas, das normalerweise zu Speicherlecks in C# oder zu Tools oder Techniken zum Aufspüren des Problems führt? Es ist alles gut und gut, eine App zu haben, die zeigt, dass mein gesamtes Objektmodell immer noch in den Speicher geladen ist, aber es zeigt mir nicht, welches Objekt oder welche Variable es speichert. Danke im Voraus.

Answer 1

Erstens untersuchen, ob das Leck aufgrund Registrierung von Event-Handler sein könnte, da dies eine der einfachsten Möglichkeiten, um versehentlich Ihre Objekte zu verankern. Wenn Sie zum Beispiel eine Klasse 'Bob' haben, die eine ihrer Methoden 'OnSomeEvent' als Delegat zu einem Ereignis hinzufügt, das von einer langlebigen Komponente Ihres Systems ausgelöst wird (zB 'UserSettingsManager'), dann Objekte der Klasse 'Bob' 'werden nicht gesammelt, da sie als Event-Handler am Leben erhalten werden (dh Event-Callbacks sind keine schwachen Referenzen).

Als Alternative zu den kommerziellen Tools gibt es eine Erweiterung des Windows-Debuggers namens SoS (Son of Strike), mit der Sie verwaltete Anwendungen debuggen können. Es ist jedoch nicht die Zartbesaiteten, da es ein Low-Level-Befehlszeilen-Tool ist, das viel Vor-Lernen erfordert. Es ist jedoch sehr leistungsfähig und hat nicht so viel mit größeren Prozessen (im Hinblick auf den Haufenverbrauch) zu kämpfen wie die kommerziellen Werkzeuge.

In Bezug auf die kommerziellen Profiler hatte ich gute Erfahrungen mit Redgate's ANTS Memory Profiler (aber ich hatte Kollegen, die es hassen), so dass es sich lohnen könnte, das zu testen.

Answer 2

Die wahrscheinlich häufigste Ursache für Lecks im verwalteten Speicher sind Ereignisbehandlungsroutinen für abgemeldete Teilnehmer.

Es gibt eine Reihe nützlicher Tools, um Fehler wie diese zu verfolgen. Persönlich mag ich ANTS Memory Profiler und WinDbg/SOS. Sie möchten herausfinden, was die Objektgraphen roofiert. Mit WinDbg/SOS gibt es einen !gcroot Befehl, der Ihnen die Wurzeln eines gegebenen Objekts sagt.

Überprüfen Sie Tess' blog für Anleitungen zum Beheben von Speicherproblemen mit WinDbg/SOS.

Answer 3

diese:

http://blogs.msdn.com/b/tess/archive/2010/01/14/debugging-native-memory-leaks-with-debug-diag-1-1.aspx

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en