CODEWITHSUNDEEP
wpfmemory-leaksvmwarevmware-workstationmemory-consumption
Mariusz Schimke
Mariusz Schimke

Reputation: 3295

High memory usage by a WPF application on VMWare Workstation

I don't want to go too much into detail about functionality, but our application's window resizes when a child control is added to or removed from it. During stress tests performed recently we noticed high peak working set of the application in Windows task manager. The child control was added and removed every 200 ms, and so the window became higher or smaller every so. We performed these tests on VMware Workstation Pro virtual machines (Windows Server 2012, Windows 10).

After at most a couple of hours the application would always report out of memory exceptions, and said window would freeze or disappear. We noticed that the working set was normal after the crash (below 100 MB), but peak working set was always over 1 GB (~1.1 up to ~1.6 GB) at that point.

To find out whether the issue was caused by a bug in our application or not, we decided to create a single-window WPF application with only a timer that changes main window's height every 200 ms. It turned out that this application had the same issue.

The thing is that I couldn't find information concerning similar issues, so I decided to post a question here. How would you explain such behaviour?

Let me also note that:

  1. When the window was minimized, the issue would never occur.
  2. It was hard to reproduce the issue on a host (not a VM), but we happened to observe it there as well (on Windows 8).

We also performed tests on a virtual computer (WMware ESX 5.5). The crash would take place much faster when nobody was looking :-). I mean we connected to a VM from vSphere Client and opened console to start our test app on the OS. Then we switched to another tab of vSphere Client to hide the console. When we returned to it later on (let's say in half an hour), we could observe memory usage history of our test app with a slowly rising slope that fell instantly at the moment the console was displayed.

I will be grateful for any information that could help me understand the reason of this issue. Thank you.

-- EDIT --

I started my test app in two instances on a VM (Windows Server 2012) - both compiled for Any CPU, but one of them had the Prefer 32-bit check box unchecked in Visual Studio. So one started in 32-bit mode and the other in 64-bit mode. The 32-bit version crashed in an hour or so, with peak working set below 150 MB. The 64-bit version kept running. I'm wondering if this might be the way to go...

The following is problem signature of the 32-bit application version:

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

Upvotes: 0

Views: 709

Answers (1)

DotNetRussell
DotNetRussell

Reputation: 9863

When I have to track down memory leaks like the one you're describing, I always turn to WinDBG

It's free and it's very effective. It has a very steep learning curve though. It will tell you how many instances of objects are in memory and lead you to what is holding onto their references

Upvotes: 0

Related Questions