windbg vs .net memory profiler

Use this forum for questions on how to use .NET Memory Profiler and how to analyse memory usage.
Post Reply
ngajjar
Posts: 2
Joined: Tue Feb 14, 2012 12:05 pm

windbg vs .net memory profiler

Post by ngajjar » Tue Feb 14, 2012 3:14 pm

Hi
I see some memory size mismatch between data reported by windbg and .net profiler 'Native Memory'. windbg command output given below, Native Memory tab picture is attached

- Total committed memory 120,999,2 KB Vs 119,360,8 KB (windbg Vs .net profiler)
- Total Manged memory 203,455 Vs 203,572 KB
- LOH 70,999 Vs 69,386 KB
- Gen2 128,878 Vs 125,092 KB
- As per windbg native heap (i.e. HeapAlloc) is 273,488 KB. As per the .net memory help file this reported as 'Unidentified unmanaged heaps'. However I could not find it in Native Memory, infect looks like it is accounted in 'Others > unidentified'
- How to investigate who is using the memory reported 'Others > unidentified', in my case .net profiler is reporting ~550 MB here.

Few other questions are
- Why am not seeing the 'call stack' view while analysing dump file
- How to investigate further list of objects reported as Unreachable in 'Overview' tab. I my case see about 465K instances taking ~70 MB reported as Unreachable.

Thanks
-nilesh

0:000> !heapstat
Heap Gen0 Gen1 Gen2 LOH
Heap0 3242616 421768 131971140 72703216

Free space: Percentage
Heap0 16964 680 34176212 18556768 SOH: 25% LOH: 25%
0:000> !eeheap -gc
....
Total Size 0xc6aff34(208,338,740)------------------------------
GC Heap Size 0xc6aff34(208,338,740)
0:000> !heapstat
Heap Gen0 Gen1 Gen2 LOH
Heap0 3242616 421768 131971140 72703216

Free space: Percentage
Heap0 16964 680 34176212 18556768 SOH: 25% LOH: 25%
0:000> !address -summary

-------------------- Usage SUMMARY --------------------------
TotSize ( KB) Pct(Tots) Pct(Busy) Usage
38466000 ( 922008) : 43.97% 76.20% : RegionUsageIsVAD
3623f000 ( 887036) : 42.30% 00.00% : RegionUsageFree
472000 ( 4552) : 00.22% 00.38% : RegionUsageImage
861000 ( 8580) : 00.41% 00.71% : RegionUsageStack
151000 ( 1348) : 00.06% 00.11% : RegionUsageTeb
10b14000 ( 273488) : 13.04% 22.60% : RegionUsageHeap
0 ( 0) : 00.00% 00.00% : RegionUsagePageHeap
1000 ( 4) : 00.00% 00.00% : RegionUsagePeb
1000 ( 4) : 00.00% 00.00% : RegionUsageProcessParametrs
2000 ( 8) : 00.00% 00.00% : RegionUsageEnvironmentBlock
Tot: 7ffe1000 (2097028 KB) Busy: 49da2000 (1209992 KB)

-------------------- Type SUMMARY --------------------------
TotSize ( KB) Pct(Tots) Usage
3623f000 ( 887036) : 42.30% : <free>
0 ( 0) : 00.00% : MEM_IMAGE
0 ( 0) : 00.00% : MEM_MAPPED
49da2000 ( 1209992) : 57.70% : MEM_PRIVATE

-------------------- State SUMMARY --------------------------
TotSize ( KB) Pct(Tots) Usage
49da2000 ( 1209992) : 57.70% : MEM_COMMIT
3623f000 ( 887036) : 42.30% : MEM_FREE
0 ( 0) : 00.00% : MEM_RESERVE

Largest free region: Base 57c00000 - Size 04ac0000 (76544 KB)
Attachments
net-profiler.jpg
Natvie Memory tab picture
net-profiler.jpg (122.38 KiB) Viewed 9531 times

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Re: windbg vs .net memory profiler

Post by Andreas Suurkuusk » Thu Feb 16, 2012 1:48 pm

I'm sorry for the delay. I had to do some investigation before replying to this post.

There will be some discrepancies between numbers presented by WinDbg and the profiler. For instance, the profiler categorizes some memory at the start of the GC heaps as belonging to the heaps (as overhead), while WinDbg doesn't. However, some of the mismatches in your example are too big. After some investigations I have noticed that the profiler fails to identify committed memory over 2GB. This should only occur if the process is flagged as LARGEADDRESSAWARE. Is your process flagged as large address aware? Anyway, we're currently looking into this and will add a fix in a maintenance relelase of .NET Memory Profiler 4.0.

The profiler will not identify Win32 heaps (unmanaged heaps) when importing a memory dump. This is something we might consider implementing in a future version. Currently, the unmanaged heap memory is presented as Other->Unidentified.

Allocation call stacks are not available when importing memory dumps or attaching to a process. To collect call stacks the profiler must actively track all allocations, which requires that the profiler has started the profiled process itself. Since no call stacks are collected, the Call stacks view will not be available.

We currently do not present any additional information about unreachable instances. An unreachable instance has, by definition, no root path, and since no call stacks are available, no allocation information can be presented for the unreachable instances. So apart from the instance fields, there's not much information to present about an unreachable instance. Still, we are considering to view unreachable instances in a future version, to present the information we have collected.
Best regards,

Andreas Suurkuusk
SciTech Software AB

ngajjar
Posts: 2
Joined: Tue Feb 14, 2012 12:05 pm

Re: windbg vs .net memory profiler

Post by ngajjar » Fri Feb 17, 2012 10:04 am

Hi Andreas

No the process is not LARGEADDRESSAWARE. Thanks for explaining the mismatch in managed heap memory, overhead idea make sense. Some help on analyzing what's going on in win32 heap will be very helpful feature.

Ok so you are saying the win32 heap is identified by the tool as 'Other->Unidentified'. In picture we could notice that tool is reporting ~964MB as 'Other Data', In that aprox 550 MB is reported as Other->Unidentified, and remaining is consumed by DLLs. As per windbg win32 heap is ~272, that mean the profiler tool is marking other memory besides win32 heap also as Other->Unidentified.

Is there a way to find out the address of the object instance in profiler, if not it would a good idea to display object address in 'Type Details' or 'Instance Details' tab. The profiler shows an instance id in those tabs, am not sure what is the use of it for the users.

Thanks
-nilesh

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Re: windbg vs .net memory profiler

Post by Andreas Suurkuusk » Sun Feb 19, 2012 9:54 pm

You can get more information about the "Other data" node in an old blog post I wrote.

The id presented for instances is just used for identification, it is not related to the address of instance. It is currently not possible to identify the address of an instance when importing a memory dump, but this is something that will be implemented in the next version (v4.1).
Best regards,

Andreas Suurkuusk
SciTech Software AB

Post Reply

Who is online

Users browsing this forum: No registered users and 33 guests