WPF Anwendung hat nur unter Windows XP Memory Leaks

Hi, ich habe eine .NET 4 Anwendung geschrieben, welche im Kiosk-Mode läuft. Unter anderem wird auf den Client-PCs Windows XP eingesetzt. Hierbei kann ich beobachten, dass über einen Zeitraum von 24 Stunden der genutzte Arbeitsspeicher von 60mb auf 120mb ansteigt. Unter Windows 8 kann ich das nicht feststellen.

Ich habe auf meinem Dev-PC zwei Snapshots des Heaps verglichen (Zeitraum drei Stunden). Hierbei ist nichts zu erkennen.

Wie gehe ich jetzt vor bzw. welche Möglichkeiten habe ich diesen Leak auf den Client-PCs zu finden?

nicky

Hier mal reingeguckt? https://support.microsoft.com/en-us/kb/2297328

Ja schon ausprobiert, liegt wohl nicht am Framework 🤔

Hi nicky,

aus den von dir gegebenen Hinweisen ergibt sich nicht zwangsläufig, daß es sich um einen Memory Leak handeln muß. Ob für deine Anwendung 120 MB oder 2 GB Speicher reserviert wird, ist erst ein Problem, wenn für die anderen Anwendungen keinen Speicher mehr gibt. Und die .NET-Speicherverwaltung gibt aus Effizienzgründen nicht jedes MB Speicher gleich wieder frei, solange noch genug freier Speicher existiert. Für ausführliche Erklärungen verweise ich auf die Forumssuche nach memory leak

Falls du noch andere Hinweise auf ein Memory Leak hast, solltest du mal einen Memory-Profiler verwenden.

Hi, also ich habe ein ContentControl dessen Content Eigenschaft ich rotierend mit unterschiedlichen Views überschreibe. In Rahmen meiner Fehlersuche habe ich folgendes Szenario erstellt:

• Neues View alle 5 Sekunden
• Es wird immer das gleiche View angezeigt (jedoch immer eine neue Instanz)
• Aufruf GC.Collect bei jedem View-Wechsel (nur während der Fehlersuche)

Jetzt habe ich zwei Tests gemacht:
1. View

<UserControl><Grid></Grid></UserControl>

Kein Leak!

2. View

<UserControl><Grid><TextBlock Text="Test"/><TextBlock Text="95.300.900"/></Grid></UserControl>

Speicher von 30mb auf 50mb in 5min. (Nur auf Windows XP!)

🤔 🤔 8o

Hi,
es bringt nichts Kaffeesatz zu lesen. Verwende einen memprofiler wie es MrSparkle schon empfohlen hat.

Ich habe mich jetzt mehrmals am Profiling versucht aber finde keine signifikanten Unterschiede im Vergleich zweier Snapshots. Bin mir aber auch ehrlich gesagt unsicher ob ich es richtig interpretiere.

Das Problem tritt ja nur unter Windows XP auf. Das macht es nicht grad einfacher. Ich hatte jetzt das Glück noch zwei andere Entwickler zu befragen. Der Fehler wurde nicht dem Quelltext zugeordnet und es scheint als wäre das ein Bug des Frameworks, welcher nur unter Windows XP zu Vorschein kommt.

Ich habe mich jetzt mehrmals am Profiling versucht aber finde keine signifikanten Unterschiede im Vergleich zweier Snapshots.

Wahrscheinlich, weil es keinen gibt. Ein Speicherleck würde sich dadurch bemerkbar machen, daß der verwendete Speicher immer weiter ansteigt. Dann könntest du die Stelle im Quellcode eingrenzen, die den Speicher reservert, aber nicht freigibt. Alles andere ist tatsächlich Kaffeesatzleserei.

Der Fehler wurde nicht dem Quelltext zugeordnet und es scheint als wäre das ein Bug des Frameworks, welcher nur unter Windows XP zu Vorschein kommt.

Welche Anhaltspunkte hast du für diese Vermutung?

Du solltest dich mal informieren, wie das .NET-Speichermanagement funktioniert. Das Thema wurde im Forum auch schon mehrmals besprochen.

Welche Anhaltspunkte hast du für diese Vermutung?

Ich kann den Fehler lediglich in der Kombination Windows XP + .NET 4 feststellen. Auf meinem Dev-PC [Windows 8] ist der Leak nicht nachzuvollziehen. Also meine Vermutung beruht eher auf dem Ausschlussverfahren. 🤔

Ja ich lese immer noch und bin für jeden weiteren konkreten Hinweis sehr dankbar!

Ich kann den Fehler lediglich in der Kombination Windows XP + .NET 4 feststellen.

Wie stellst du das fest? Mit dem TaskManager?

Ja. Ich rufe zum teste regelmäßig GC.Collect() auf und nehme an, dass sich der RAM dadurch nicht von 50mb auf 250mb erhöhen sollte.

Ich kann dir wie gesagt nur empfehlen, dich mal mit der Funktionsweise der .NET-Speicherverwaltung zu beschäftigen, anstatt dich von unbegründeten Annahmen leiten zu lassen.
Die Werte im TaskManager sind jedenfalls in diesem Zusammenhang nicht aussagekräftig. Siehe dazu: [erledigt] Memory leak im Loop [=> vermutlich Scheinproblem, trotzdem Besserung durch StringBuilder] und Memory Leak trotz Dispose, nullen usw..