Вопрос по wpf, managed, unmanaged, memory-leaks – Обнаружение утечки памяти в смешанной среде (Managed-Unmanaged)

1

У меня есть приложение, написанное на VC ++ MFC 6.0. Недавно был обновлен до .NET 3.5 путем компиляции в vs2008 и добавил в него некоторые приложения WPF, используя управляемую и неуправляемую среду. В основном хостинг WPF в окне win32. Если я просто открываю окно приложения WPF, память продолжает расти, как 1 КБ / 10 секунд. Я пытался использовать профилировщик памяти .NET & amp; Профилировщик памяти муравьев. Но оба не помогают мне обнаружить утечки !! Я удалил все элементы управления WPF из размещенного приложения WPF. Он просто содержит страницу с рамкой. Но все же утечка случается !! Кто-нибудь, пожалуйста, помогите мне, что может привести к увеличению памяти приложения?

gahcep, Нет. Нет OnPaint () Alerter
Спасибо Дэвид, я попытался использовать GlowCode, который является профилировщиком, который может обнаружить утечки как в управляемых & amp; неуправляемый код. Это мне не помогло :( Но я посмотрю на ссылку, которую вы дали. Alerter
Используете ли вы приложение WPF с методом OnPaint в вашем приложении? gahcep
Не могу дать конкретный ответ на ваш вопрос, но я просто хочу отметить хорошую статью об отслеживании утечек памяти в .Net:codeproject.com/Articles/19490/Memory-Leak-Detection-in-NET David Brabant

Ваш Ответ

3   ответа
1

памятью в WPF - возможно, стоит прочитать:

http://www.red-gate.com/products/dotnet-development/ants-memory-profiler/learning-memory-management/WPF-Silverlight-pitfalls

Что касается ваших попыток найти утечку с помощью профилировщиков памяти, попробуйте следующее с ANTS:

1) Сделайте два снимка с интервалом в одну или две минуты (профилировщик автоматически запускает сборку мусора перед каждым снимком).

2) Убедитесь, что для базового снимка задан снимок 1, а для последнего снимка задан снимок 2.

3) Перейти к списку классов.

4) В разделе «Основные фильтры». выберите «Из текущего снимка» показать только новые объекты ».

5) Выделите самый большой класс, затем перейдите к списку экземпляров.

6) Для одного из экземпляров откройте график хранения экземпляров, который показывает цепочки ссылок, хранящих этот экземпляр в памяти.

7) Если вам повезет, вы увидите объект, удерживающий то, что он не должен, и затем вы можете исправить. Если нет, повторите шаги 5 & amp; 6 но выбирая разные классы / экземпляры.

5

вы должны определить, есть ли у вас утечка управляемой памяти или собственная утечка памяти:

Используйте эти счетчики PerfMon для этого:

Process/Private Bytes, .NET CLR Memory/# Bytes in All Heaps, .NET CLR LocksAndThreads/# of current logical Threads.

Если 1 увеличивается, но 2 остается стабильным, у вас есть собственная утечка памяти. Если 1 и 2 увеличиваются, у вас есть управляемая утечка памяти.

Если 3 неожиданно увеличивается, стеки потоков просачиваются.

Если вы обнаружили утечку управляемой памяти, вам могут помочь такие инструменты профилирования памяти .NET, как Ants, YourKit и т. Д. Так как они не помогли в вашем случае, у вас, вероятно, есть собственная утечка.

Важно: убедитесь, что вызываете сборщик мусора вручную, прежде чем смотреть на потребление памяти. Если недостаточно памяти, ГХ не запустится, и ваш процесс & apos; память увеличивается (что не является утечкой в данном конкретном случае). Вызовите GC следующим образом:

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
1

после некоторого поиска души, выяснилось, что утечка на самом деле из-за ошибки в фреймворке. Прочитайте это для больше http://social.msdn.microsoft.com/Forums/zh/wpf/thread/5b9ae245-9067-4ca4-b846-180db9f7bde5

Похожие вопросы