The call stacks presented by .NET Memory Profiler are collected when an instance is allocated. They present information about how and why instances are created.

The call stacks you see in WinDbg are the active call stacks for each thread in the process. These are the same threads as you see when you are debugging a process. They do no present any information about how instances are collected.

However, the active call stacks acts as roots for instances, so the do provide some useful information for a memory profiler. We have considered adding an "Active call stacks" page to the profiler, and are still considering it. But this feature will not be included in the next version of the profiler.

To search for this information, you need to run your process under the profiler. This information is not available when importing a memory dump or attaching to a process (i.e. the information does not exist in the memory dump and can therefore not be retrieved by the profiler).

Ok, essentially I was looking at memory allocation for active call stacks. We have a number of threads hanging forever in some 3rd party DLL method and we wanted to know what was the data causing this hang. Logging the data on every call would have created huge amount of data since we don't know the exact circumstances when this is happening. I was under the impression active call stack was presented in memory profiler so perhaps in a future release .