DebugDiag call stack does not display line number of functions in call stack

Question

I am trying to isolate memory leaks in native code on Windows.

I ran multiple iterations of a test case and attached DebugDiag to the process to collect information on the suspected leak (memory leak confirmed through multiple runs in PerfMon).

DebugDiag pointed out suspicious call stacks like

 Call stack sample 1

 Address   0x0f09e2c0

 Allocation Time   00:22:38 since tracking started 

 Allocation Size   8.54 KBytes 

    Function                                       Source destination
    ntdll!RtlpReAllocateHeap+19c                  ntdll!RtlAllocateHeap 
    ntdll!_except_handler4       
    ntdll!RtlReAllocateHeap+22f                   ntdll!RtlReAllocateHeap 
    sqlncli11!MpReallocZeroMemory+66     
    sqlncli11!SQLReAllocateMemoryEx+22            sqlncli11!MpReallocZeroMemory 
    sqlncli11!AllocPlex+1a4                       sqlncli11!SQLReAllocateMemoryEx 
    sqlncli11!SetADRec+2a4                        sqlncli11!AllocPlex 
    sqlncli11!SQLBindCol+217                      sqlncli11!SetADRec 
    odbc32!SQLBindCol+3c0       
    sscfdm!CSSLockSqlCursor::DoExecuteStmt+11a       
    sscfdm!CSSSqlCursor::Execute+129              sscfdm!CSSLockSqlCursor::DoExecuteStmt 
    sscfdm!CSSSqlObj::Execute+d86                 sscfdm!CSSSqlCursor::Execute 
    sscfom!CSSBusComp::SqlExecute+3a              sscfdm!CSSSqlObj::Execute 
    <<many multiple lines below>>

I have configured symbols properly, now I wanted to know how do I extract more info from call stack.

1. UMDH logs have line numbers too (with file names) in their diff logs. However in DebugDiag report I do not find any line numbers of those functions. If the functions are really very long, then it becomes difficult to describe the context by just looking at call stack without having the line numbers. Is there any way I can extract line number of function (file) from DebugDiag logs?

2. Another thing I wanted to know was the significance of hex offset with each module!function entry in the call stacks.

3. What is the Allocation size in the call stack? is it the allocated memory that has not been freed (hence the leak) per execution of this call stack?

4. Any pointers to comprehensive documentation about DebugDiag capabilities?

Answer 1

UMDH logs have line numbers too (with filenames) in their diff logs. However in debug diag report I do not find any line numbers of those functions.

Well, then go with the UMDH logs.

significance of hex offset with each module!function entry in the call stacks.

The hex offset points to a specific assembler instruction in a compiled method. It is roughly related to the line number offset in source code but may heavily be influenced by compiler optimizations.

What is the Allocation size in the call stack? is it the allocated memory that has not been freed ...

Yes

... per execution of this call stack?

No. Running the same method again may allocate a different size. Consider a function like AllocateSomeMemory(int bytes) that would depend on the parameter on how much memory is allocated.

Any pointers to comprehensive documentation about DebugDiag capabilities

Sorry, I can't mention a good site off of my head.