views:

261

answers:

2

Hi!

I have a mixed mode application (managed and native) which has a high memory footprint. I already have found out that most of the memory is allocated by native code. I am not talking about a memory leak, but about a high memory consumption that occurs very early after the program starts and then is relatively stable.

Are you aware of any tool that shows you which C/C++ objects use the most memory? I have already tried DebugDiag 1.1 and SoftwareVerify's Memory Validator, but both tools do not give enough information to identify the C/C++ objects.

Regards

Frank

+1  A: 

AQTime's memory profiler works well for this. It's one of the few profilers I've tried that handles both native and managed code using the same profiler, including supporting mixed mode assemblies.

Reed Copsey
I have tried AQtime, but it seems to have problems with mixed mode applications. I have tried it with several different programs (including simple "Hello, world"-type programs), but when AQtime accesses them, they crash. I have contacted the manufacturer's support
fmunkert
Hrm. Works fine for me, here. I've only tried with x86-targeted mixed mode apps - maybe thats it?
Reed Copsey
A: 

Can I suggest a more "hardcore" approach?

WinDbg's !heap command can reveal a lot of important information about the native heap. start by doing the following steps:

A. launch GFlags, go to the Image File tab, type your process's name and press tab.

B. press the "Enable page heap" and "Create User mode stack trace database" and press OK.

C. start your process.

Doing the above steps will tell windows to collect memory allocation information about your process. we will use this information later.

IMPORTANT : collecting this information will make your application use more memory and probably to be slower. windows will continue collecting this information every time you'll run your process until you;ll tell it otherwise by launching GFlags and remove your selections.

attach WinDbg to your application and set the correct symbols. beside your own symbols, you'll need Microsoft's symbols. use the .symfix command and then use .reload /f to make WinDbg download the correct symbols from microsoft's symbol server (it can take several minutes).

After all the symbols are set perform the following steps:

A. !heap -stat - to see a usage summery of all your process's heaps

B. choose one heap to examine. the one with the highest committed bytes will be a good candidate if you are looking for big objects.

C. !heap -stat -h "heap handle" - to see the allocation statistics for the heap. in the output you will find how many blocks are allocated for each allocation size.

D. pick one of the higher allocation sizes and use !heap -flt s "size" to dump all the heap entries of the same size.

E. !heap -p -a "UserPtr" will print the allocation stack (along with other information). this information will not be available if you won't set the "Enable page heap" using GFlags.

That's it, use the information from the call stack and look at your source code to identify those big objects.

B.T.W

If you don't have the Debugging Tools for Windows package installed already, you can download it from here.

Maybe this approach is not as simple as you expected but it works :) Have fun.

Moshe Levi
WinDbg seems not to tell the whole truth about the process memory: my process has 121 MB committed memory according to Windows task manager. "!heap -s" says the committed memory is 33 MB and "!heap -stat" says the committed memory is 2.3 MB.
fmunkert