2

Windows のネイティブ コードでメモリ リークを分離しようとしています。

テスト ケースを複数回実行し、プロセスに DebugDiag をアタッチして、疑わしいリークに関する情報を収集しました (メモリ リークは、PerfMon で複数回実行して確認しました)。

DebugDiag は、次のような疑わしいコール スタックを指摘しました。

 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>>

シンボルを適切に構成しましたが、コール スタックからさらに情報を抽出する方法を知りたいと思いました。

  1. UMDH ログには、差分ログにも (ファイル名と共に) 行番号があります。ただし、DebugDiag レポートでは、これらの関数の行番号が見つかりません。関数が非常に長い場合、行番号なしでコール スタックを見るだけではコンテキストを説明することが難しくなります。DebugDiag ログから関数 (ファイル) の行番号を抽出する方法はありますか?

  2. 私が知りたかったもう 1 つのことはmodule!function、コール スタック内の各エントリの 16 進オフセットの重要性です。

  3. コール スタックの割り当てサイズは? このコールスタックの実行ごとに解放されていない割り当てられたメモリ (したがってリーク) ですか?

  4. DebugDiag 機能に関する包括的なドキュメントへのポインタはありますか?

4

1 に答える 1