Page 1 of 1

<Other> in Private data - Native Memory tab

Posted: Wed Feb 07, 2007 5:52 pm
by Darta
I am using the Native Memory tab to disect and determine what all is part of our working set. It works wonderfully, but I need helps determining what goes into Other Data - <Other> bucket. For our app, this is about 40,684 KB - and is therefore a huge amount. We don't even know where or how to begin to troubleshoot and determine where this comes from. Can you help point us to how we can disect where this number comes from...? Also, we really don't understand how come this memory cannot be traced back and matched to a dll - affter all, who is then creating it...?

Any help is greatly appreciated!

Darta

Posted: Wed Feb 07, 2007 8:50 pm
by Andreas Suurkuusk
The "Other data -> <Other>" node represents memory that the profiler has failed to identify. This can be memory used by unmanaged resources or internal memory used by the runtime, including memory allocated using VirtualAlloc that hasn't been suballocated by functions such as HeapAlloc.

The amount of native memory is greater when running under the profiler than it is when running the application the normal way. The runtime itself probably consumes more memory when profiling since it cannot perform certain optimizations and it might keep information available for the profiler that could otherwise be discarded.

Memory usage attributed to a dll only includes the memory used by the dll file itself, not memory that is allocated by code in the dll.

The current version of the profiler does not provide any additional information about this memory, but you can download the release candidate of .NET Memory Profiler 3.0 (from http://memprofiler.com/rc). This version contains an unmanaged resources tracker that might help you identify the "other data" memory.

If you unload classes from your application (e.g. by working with dynamic AppDomains), it is possible that some memory associated with the classes doesn't get released when running under the profiler. E.g. there is no possibility for the profiler to release memory allocated by the Dispose tracker, and this memory will show up as <Other>. The attach to feature of .NET Memory Profiler 3.0 can be used to get more accurate native memory information, since attaching to a process does not affect the memory usage of the process at all.