Ich habe eine eigenständige WPF-Anwendung unter .NET 3.5. Gelegentlich erstarrt das Display für einige Sekunden. Dies ist am deutlichsten auf Bildschirmen, auf denen häufig etwas aktualisiert wird. Hier ist ein Video , das das Problem zeigt.
Während das Display eingefroren ist, bleibt die Benutzeroberfläche reaktiv ( Video ).
Ich bin auf andere Posts mit ähnlichen Problemen gestoßen, die es einem SW / HW-Rendering-Problem zuschrieben. Um sicher zu sein, habe ich das HW-Rendering komplett deaktiviert, habe aber immer noch das Problem.
Ich habe während des Einfrierens einen Dateimonitor ausgeführt, um zu sehen, ob ein außergewöhnlicher Dateizugriff oder eine bestimmte Aktivität stattfindet, aber nichts ist ungewöhnlich.
Schlussbemerkung: Die Zielplattform ist ein kleiner Touchscreen-PC ohne viel Arbeitsspeicher oder PS (512 MB). Ich sehe dieses Problem nur auf dem Ziel , niemals auf meinem Entwicklungs-PC, der viel mehr Ressourcen hat.
AKTUALISIEREN
Ich dachte, ich hätte das Problem behoben, indem ich einen Animationscode entfernt habe, aber es hat nicht funktioniert. Ich stoße immer noch auf das Problem und ich bin am Ende meines Seiles.
Hier sind noch einige Dinge, die ich versucht habe:
Ich bin hier wirklich ratlos und habe eine Prämie hinzugefügt. Wie bereits erwähnt, tritt das Problem nur auf dem Ziel-PC auf ( Link ).
Der Schuldige war der folgende Methodenaufruf:
%Vor%Dies wurde meiner Anwendung hinzugefügt, weil es in .NET 3.5 ein Speicherleckproblem gepatcht hat. Diese Problemumgehung finden Sie hier . Wenn ich diesen Aufruf lösche, verschwinden die Rendering-Probleme.
Ich nahm den Anruf entgegen und behob das Speicherleck auf eine andere Weise (indem ich die Storyboard-Animation entfernte und stattdessen den Code verwendete)
Ich neige dazu, entweder .NET GC oder die OS-Auslagerungsdatei zu vermuten, wenn diese Art von Verhalten auftritt.
Bei ersterem könnten Sie versuchen, die .NET-Leistungsindikatoren auf verdächtige Aktivitäten zu überwachen.
Wenn das Gerät eine Auslagerungsdatei hat, können Sie es deaktivieren und sehen, ob sich das Verhalten ändert.
Wie andere bereits gesagt haben, wäre ein Profiler (oder etwas, das die Verzögerung zu verzögern versucht - sogar den Debugger anzuhängen und zu unterbrechen, wenn er auftritt) eine gute Möglichkeit, mehr Informationen zu erhalten.
Haben Sie versucht, die Anwendung auf dem getesteten System zu profilieren? Verwenden eines Arbeitsspeichers und / oder Leistungsprofils?
Sie können einige gute Informationen aus dieser Art von Test erhalten: einige .Net Profiler Und hier ist einer für WPF: WPF-Profiler von Microsoft