3

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
Paul R
  • 208,748
  • 37
  • 389
  • 560
Benedetto
  • 711
  • 6
  • 17

2 Answers2

8

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.

Steve Townsend
  • 53,498
  • 9
  • 91
  • 140
  • Thanks a lot Steve. That was indeed the case. GlobalFlags was being set at 0x1000 in the registry under "Image File Execution Options", which means "Create user mode stack trace database". Thanks again! – Benedetto Jan 03 '13 at 20:05
  • great, glad it's sorted out - by the way, if you can turn this off, everything will run faster ;-) – Steve Townsend Jan 03 '13 at 20:19
  • Yep. Doing that right now. Surprised not to have found references to it on Google or Stackoverflow. – Benedetto Jan 03 '13 at 20:26
  • You are blazing a trail as well as speeding up the server, that counts as a good day... – Steve Townsend Jan 03 '13 at 20:27
0

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.
bjsample
  • 45
  • 1
  • 5