3

LeakTrack in DebugDiag not capturing stack traces, so not sure where to go from here.

I have a .NET application (NServiceBus process running as a windows service) that has a memory leak. Grows to about 10GB over the course of 5-6 days.

I did a procdump and basic analysis using !address –summary in WinDbg. I see a heap commit size of 8.6GB.

Next, I ran DebugDiag on the dump for managed memory. There were no red flags at all in the managed memory, so then I attempted to look at the native allocations.

So I DebugDiag (2.1.0.7), and selected

Record call stacks immediately when monitoring for leaks (AKA "FastTrack") NOTE: not recommended when monitoring longer than 15 minutes)

I then ran it for 30 minutes (contrary to the warning). When running the analysis, I get a message that it could not get the call stacks because I either I didn't run it longer than 15 minutes (I did) or that I need to set "Begin recording call stacks immediately" (I did).

So, I decided to try again. I set it to run for 2 hours this time, and did not set it to "Begin recording immediately". Same message.

enter image description here

enter image description here

Here is the virtual memory summary from the 9GB procdump (that didn't have leak detection running)

enter image description here

So what do I need to do to get call stack from DebugDiag? My culprit seems to be in the committed memory (I'm not sure I really understand reserved vs. committed in this context). But have no idea how to go about identifying what the culprit is.

Also not sure why DebugDiag thinks there is 8TB of memory (this is running on a virtual machine, not sure if that is related or not).

Matt
  • 41,216
  • 30
  • 109
  • 147
  • As far as why you see 8TB free, that is the virtual address space available to a 64-bit process. It may not be (and almost certainly isn't) backed by physical memory. – Sean Cline Dec 30 '14 at 22:07
  • You are using the wrong tool, Umdh.exe is the tool to diagnose unmanaged memory leaks. Look for missing Dispose() calls on bitmaps first. Testing the 32-bit version wouldn't hurt either. – Hans Passant Dec 30 '14 at 22:12
  • use WPRUI/experf to monitor/analyze memory usage: http://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-49-WPT-Memory-Analysis-VirtualAlloc – magicandre1981 Dec 31 '14 at 08:31
  • @HansPassant Thanks, hadn't heard of Umdh. Will give it a shot. Also - no bitmaps in this application. – Matt Dec 31 '14 at 13:38
  • @HansPassant The stack traces from umdh don't show a single entry from my application dlls. I can see in the logs at the top of the output the symbols are in fact loaded for my app. So not sure what is going on there. – Matt Dec 31 '14 at 15:44
  • That's expected when you write C# code, you didn't allocate unmanaged memory yourself. Some other code did. Probably because you called it from your C# program, you are not going to get a friendly managed stack trace from an unmanaged heap debugging tool. – Hans Passant Dec 31 '14 at 15:50
  • @HansPassant Any tips for connecting those native stacks with what, in the managed code, triggered their execution? – Matt Dec 31 '14 at 17:05
  • I might have some if I had half an idea what they look like. I gave me nothing. – Hans Passant Dec 31 '14 at 17:07

1 Answers1

0

you can use WPA (Windows Performance Analyzer) VirtualAlloc traces can be obtained by using the virtual alloc profile here is a 9 minute video explaining the analysis of a sample VirtualAlloc related issues

Understanding VirtualAlloc usage using Windows Performance Analyzer http://channel9.msdn.com/events/Build/BUILD2011/HW-977P

Addy
  • 731
  • 5
  • 15