3

Context: We are building a framework for rapid delivery of WPF applications. This framework uses Autofac as an IoC container and also uses regions from Prism v1. We are scheduling tasks with Parallel extensions from Microsoft.

We are facing the following problem: When we boot the application with empty views (so just a shell with regions and placeholder controls), the memory will remain stable for about 60 seconds and after that it will increase about every second with 4kb, then 4kb, after that 8kb. So every 3 seconds we have 16Kb added to our memory pressure.

What have we tried to track down the leak. I started out by using dotTrace but I couldn't see any difference between 2 snapshots taken 30 minutes apart. Moved on to .NET memory profiler because it gives me more information but again we cannot see any differences between 2 snapshots. We can see that a number of objects get created but they are removed too and results in a delta of 0. So I moved on to windbg but the result is the same.

Another weird thing is that when we start sysinternals dbgvw we don't see any calls being made in our applications.

Do you have any suggestions of what we might try next to find out what/who is the culprit?

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
Casual Jim
  • 1,179
  • 7
  • 13
  • What metric are you using to determine that the memory is increasing? – Kent Boogaart Apr 29 '09 at 09:26
  • I agree you need to define the metric you use for measuring memory use, also have you determined if the allocations are managed or unmanaged? – morechilli Apr 29 '09 at 09:47
  • I looked at the heap memory and the private bytes of the process. A quick look in perfmon tells me that the unmanaged memory is increasing a lot while the managed memory only increases once in a while (about every minute) with a very small amount of bytes. The unmanaged memory increases a lot faster.. Seeing if the memory is increasing I did through process explorer from sysinternals and the taskmanager initially. Our application has loads of tracing statements so we're fairly sure that it isn't application code that is running – Casual Jim Apr 29 '09 at 10:30
  • I'd look at it with process explorer or handles.exe from Sysinternals. See if you are leaking any system handles and what type they are (if you have Windows 7, the builtin Resource Explorer has this information). The behavior you describe is consistent with a handle leak I saw recently in one of my apps. – Anderson Imes Sep 05 '09 at 14:58
  • Related: [WPF Memory Leak on XP (CMilChannel, HWND)](http://stackoverflow.com/questions/1705849/wpf-memory-leak-on-xp-cmilchannel-hwnd) – Bill the Lizard Mar 15 '11 at 15:42

2 Answers2

0

If you are looking for unmanaged leaks and are using visual studio you can get surprisingly helpful information using the built in crt functions:

see an answer to a related question

Community
  • 1
  • 1
morechilli
  • 9,827
  • 7
  • 33
  • 54
-1

As it turns out it was a bug inside WPF and the workaround was to create a window handler as very first object or something. Thanks guys

Casual Jim
  • 1,179
  • 7
  • 13
  • Can you post where you found this information for others? It's not clear from your comment what the workaround was. My gut says that you were running your WCF servers in an STA thread and it couldn't finalize some resources, but it's not clear. – Anderson Imes Sep 08 '09 at 16:09
  • It was a wpf beg and that info wasn't found on the web at all unfortunately. We logged a support call with microsoft and it took them about a week to track down what the issue was. I've left that client now so I can't go and look what the workaround was unfortuantely. WCF was IIS hosted btw but had nothing to do with the issue. – Casual Jim Sep 20 '09 at 19:57
  • This is actually documented it's number 8 (CMilChannel leaks if initial HWND is destroyed on XP) in the blog post below. http://blogs.msdn.com/jgoldb/archive/2008/02/04/finding-memory-leaks-in-wpf-based-applications.aspx – Casual Jim Nov 05 '09 at 15:56