Les fuites de mémoire statiques EventHandler dans le framework

Question

Je suis en train de résoudre certains problèmes de mémoire que nous rencontrons dans notre application .NET WinForms. J'utilise SciTech's .NET Memory Profiler ainsi que dotTrace et ils semblent tous être des affectations de racine indicting par les gestionnaires d'événements statiques dans les contrôles .NET Framework. De google'ing autour, j'ai trouvé des rapports de ce here et here mais cela semble être rapporté sur la version 1.1 du .NET Framework et les corrections promises pour 2.0. Nous courons sur 2.0 et nous voyons toujours ces problèmes. Les 25 principaux délinquants de mémoire que j'ai trouvés pointent tous vers ces gestionnaires d'événements statiques et spécifiquement SystemEvents.UserPreferenceChanged. This guy est allé très loin pour trouver un moyen de se détendre ces gestionnaires. Je n'ai pas encore essayé, mais j'ai essayé la solution de contournement mentionnée dans le ticket de support de Microsoft, et aucun d'entre eux n'a fonctionné pour moi. Je connais bien le potentiel de fuites des gestionnaires d'événements (en particulier les gestionnaires statiques de longue vie), mais celui-ci est presque hors de mon contrôle. Quelqu'un a-t-il une expérience avec ceci?

Answer 1

Pour les problèmes de fuite de mémoire vraiment profonds dans le CLR, je trouve que le meilleur outil est windbg. Si vous pouvez passer la syntaxe cryptique, c'est un débogueur incroyablement efficace et un traqueur de fuite. L'inconvénient est qu'il n'est pas très intuitif à utiliser et il y a une courbe d'apprentissage très raide.

La meilleure façon d'apprendre le windbg est de le faire. Voici quelques articles qui parlent d'utiliser windbg pour localiser une fuite.

• http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx
• http://weblogs.asp.net/scottgu/archive/2006/02/02/437231.aspx

Answer 2

Je ne sais pas si WinDBG va aider ici. Il semble que ce soit vraiment un bug dans le cadre. Est-il possible de poster un simple repro? Si oui, alors je pourrais creuser dans ce que le diable se passe et voir s'il y a une solution de contournement. Sinon, votre meilleur pari serait d'ouvrir un ticket sur Connect. Ils sont plutôt bons pour revenir aux gens.

Si vous vouliez l'étudier avec WinDBG, vous pourriez étudier ce qui se passe sur le tas pour voir ce qui se passe. Commencez à regarder ce que les objets qui traînent sont enracinés. Je suppose que vous verrez à peu près ce que vous voyez dans les profileurs ci-dessus. La chose délicate avec WinDBG est qu'il peut vous dire à peu près tout ce que vous voulez - vous devez savoir quelles questions vous voulez répondre en y allant.