Высокое использование памяти приложением WPF на рабочей станции VMWare

Я не хочу вдаваться в подробности о функциональности, но размер окна нашего приложения изменяется при добавлении или удалении дочернего элемента управления. Во время недавно проведенных стресс-тестов мы заметили высокий пиковый рабочий набор приложения в диспетчере задач Windows. Дочерний элемент управления добавлялся и удалялся каждые 200 мс, поэтому окно становилось все больше или меньше. Мы провели эти тесты на виртуальных машинах VMware Workstation Pro (Windows Server 2012, Windows 10).

Через несколько часов приложение всегда сообщало об исключениях из памяти, и указанное окно зависало или исчезало. Мы заметили, что рабочий набор был нормальным после сбоя (ниже 100 МБ), но пиковый рабочий набор всегда был более 1 ГБ (от ~1,1 до ~1,6 ГБ) в этот момент.

Чтобы выяснить, была ли проблема вызвана ошибкой в ​​нашем приложении или нет, мы решили создать WPF-приложение с одним окном только с таймером, который изменяет высоту главного окна каждые 200 мс. Оказалось, что это приложение имеет ту же проблему.

Дело в том, что я не смог найти информацию о подобных проблемах, поэтому решил разместить здесь вопрос. Как бы вы объяснили такое поведение?

Позвольте мне также отметить, что:

  1. Когда окно было свернуто, проблема никогда не возникнет.
  2. Трудно было воспроизвести проблему на хосте (не на виртуальной машине), но мы также наблюдали ее там (на Windows 8).

Мы также провели тесты на виртуальной машине (WMware ESX 5.5). Авария произошла бы намного быстрее, когда никто не смотрел:-). Я имею в виду, что мы подключились к виртуальной машине из vSphere Client и открыли консоль, чтобы запустить наше тестовое приложение в ОС. Затем мы переключились на другую вкладку vSphere Client, чтобы скрыть консоль. Когда мы вернулись к нему позже (скажем, через полчаса), мы могли наблюдать историю использования памяти нашего тестового приложения с медленно растущим наклоном, который мгновенно падал в момент отображения консоли.

Я буду благодарен за любую информацию, которая может помочь мне понять причину этой проблемы. Спасибо.

-- РЕДАКТИРОВАТЬ --

Я запустил свое тестовое приложение в двух экземплярах на виртуальной машине (Windows Server 2012) - оба скомпилированы для любого процессора, но в одном из них флажок Prefer 32-bit не был установлен в Visual Studio. Итак, один запускается в 32-битном режиме, а другой в 64-битном режиме. 32-разрядная версия потерпела крах примерно через час, с максимальной рабочей нагрузкой ниже 150 МБ. 64-разрядная версия продолжала работать. Мне интересно, если это может быть путь...

Ниже приведена проблемная сигнатура 32-разрядной версии приложения:

Problem signature:
  Problem Event Name:   CLR20r3
  Problem Signature 01: ResizeStressTest 32.exe
  Problem Signature 02: 1.0.0.0
  Problem Signature 03: 5762641e
  Problem Signature 04: PresentationCore
  Problem Signature 05: 4.0.30319.34209
  Problem Signature 06: 5348b56b
  Problem Signature 07: 283
  Problem Signature 08: 13
  Problem Signature 09: System.OutOfMemoryException
  OS Version:   6.2.9200.2.0.0.272.7
  Locale ID:    1031
  Additional Information 1: 5861
  Additional Information 2: 5861822e1919d7c014bbb064c64908b2
  Additional Information 3: 5c1f
  Additional Information 4: 5c1f554df00553b422a8baa03b19335a

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=190175

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt
Источник

1 ответ

Когда мне нужно отследить утечки памяти, подобные той, которую вы описываете, я всегда обращаюсь к WinDBG

Это бесплатно и очень эффективно. Хотя у него очень крутая кривая обучения. Он скажет вам, сколько экземпляров объектов находится в памяти, и приведет вас к тому, что держит их ссылки

Источник
Другие вопросы по тегам