Why do malloc/new capture the callstack?

Question

I have a 64bit application that runs as a service under Server 2003.

When I attach the VS Profiler or windbg I see lots of callstacks like the one below. I understand that processes spawned in the debugger (or profiler) use the debug heap etc... But this is not the case since this service is started by the OS and I am only attaching to it.

I do not understand why it is unwinding the stack. And the profiler shows that a measurable amount of time is spent doing that. Some more info:

• These are release bits built with vc9, running on Server 2003.

• System environment variable _NO_DEBUG_HEAP is set to 1.

• I am using Microsoft symbol servers.

Why is it capturing the stack trace? It seems it’s logging it.. but I can’t find where.

My objective is to verify that the app is really unwinding the stack and, if that is true, try to avoid it.

Any ideas?

---

Callstack

ntdll!RtlVirtualUnwind
ntdll!RtlpWalkFrameChain
ntdll!RtlCaptureStackBackTrace
ntdll!RtlpCaptureStackTraceForLogging
ntdll!RtlLogStackBackTrace
ntdll!RtlDebugAllocateHeap
ntdll!RtlAllocateHeapSlowly
ntdll!RtlAllocateHeap
MSVCR90!malloc
MSVCR90!operator new

Answer 1

It's possible that somebody has used gflags.exe to enable user stack trace capturing for this process or systemwide, or some other flag that requires tracking of CRT allocation operations.

You should be able to check this possibility in the registry using the info here.

Answer 2

Steve's answer is great, and eventually led to a resolution for our own server after a looong investigation. Our situation was slightly different, and the cause for the stack captures was due to a script periodically running a UMDH capture. UMDH will enable the stack collection when executed against that process for the first time. It gives the following warning:

 UMDH has enabled allocation stack collection for the current running process.