Identify owner of native memory used by C# application

I am working on a C# application which is designed to run in the system tray all the time. I would therefore like to minimise the amount of memory which the application uses when idle. Using Windows perfmon and the Windows Task Manager I have got some figures for idle memory usage.

• Windows XP TaskManager - Mem Usage - 96,300K
• PerfMon
  • .NET 开发者_如何学PythonCLR Memory
    • # Bytes in all Heaps - 34,513,708
    • # Total committed Bytes - 40,591,360
    • # Total reserved Bytes - 50,319,360

I think these figures mean that my application has been allocated 96MB of memory by Windows. 50MB of this has been allocated to the CLR. The CLR has handed out 40mb of this.

Is there any way to work out what the other 46mb of memory which hasn't been assigned to the CLR is being used for? I assume this will be a combination of memory used for loading DLLs into the process and memory used by this native code.

EDIT: I have download VMMap and found the following.

• Private
  • Total - 72mb
  • Managed Heap - 25mb
  • Stack - 16mb (Seems quite large)
  • Private Data - 13mb (Not sure what this is)
  • Image - 8mb (Mostly .NET DLLs)
  • Page Table - 6mb (Seems quite large)
  • Heap - 3mb

Can anyone suggest an interpretation for the Stack, Private Data and Page Table figures?

NOTE: The counters I originally quoted are now showing some bizarre figures.

• Windows XP TaskManager - Mem Usage - 43,628K
• PerfMon
  • .NET CLR Memory
    • # Bytes in all Heaps - 20mb
    • # Total committed Bytes - 23mb
    • # Total reserved Bytes - 50mb

This suggests that the CLR has reserved more memory than has been allocated to the process. Obviously this can't be true so the TaskManager must only be showing what has been paged in at the moment.

Note that the difference between the total memory usage (I'm not exactly sure what figure TaskManager is showing; Windows tools have a bad history about using different terms for equal concepts) and the "#Total reserved bytes" may also be used by CLR, just not by the managed heap (so native allocations by the CLR, loaded DLLs, etc. may also account here).

You may want to checkout Sysinternals VMMap to get more detailed information.