none
UMDH.EXEで関数名がダンプ出力されない RRS feed

  • 質問

  • UMDH.EXEを使ってVBアプリケーションのメモリリークを調べようとしています。

    マイクロソフトのサポートページで紹介されている方法で試しにnotepad.exeのダンプファイルを出力したのですが、マイクロソフトのページで紹介されているような関数名が入ったダンプが出力されません。

    シンボルファイルはダウンロードされているようなのですが、なにが悪いのか分かりません。

    umdh で -gオプション追加しても同じです。(マイクロソフトで紹介されている-dは使えませんでした)

    NTSD システム デバッガでld notepadをしたらシンボルファイルは読み込まれているような感じでした。

    lmコマンドではいまいち説明されているような内容ではなかったですが。

    どなたかご存じの方いらっしゃたらご教示ください。

    ちなみにWindows7 Pro、windowsXp Proの両方で試してみても同じです。

    以下、その時の手順とnotepadのダンプファイル(一部)です。

    ----------------------------------------------------------------------------------------------------------------------------

    【準備】

    1)マイクロソフトのHPからWDKをダウンロード。

    2)Debugging Tools for Windowsをインストール。

    3)環境変数PATHにDebugging Tools for Windowsのインストールフォルダを
      追加。 C:\Program Files\Debugging Tools for Windows (x86)


    4)環境変数_NT_SYMBOL_PATHにsymsrv構文をセットする。

    SRV*D:\localsymbols*http://msdl.microsoft.com/download/symbols
    (symsrv*symsrv.dll*D:\localsymbols*http://msdl.microsoft.com/download/symbolsも試してみた)


    5)シンボルファイル(pdbファイル、又はdbgファイル)をマイクロソフトシンボルサーバーからダウンロード。

      symchk /r c:\windows\system32 /s %_NT_SYMBOL_PATH%

      %_NT_SYMBOL_PATH%で指定したフォルダにはシンボルファイルがダウンロードされている。

    (Ntdll.dll やkernel32.dllもダウンロードされている)


    【ダンプ出力】

    1)ヒープ割り当てのダンプを作成するためにカーネルに割り当ての追跡を実行するようOSに伝える。

    gflags -i notepad.exe +ust


    2)notepad.exeを起動

    3)コマンドプロンプトからtlistでnotepad.exeのPIDを取得する(メモする)

    4)ヒープダンプを取得する。
    コマンドプロンプトから
    umdh -p:3808 -f:D:\HEAPDUMP\notepad3808-1.log

    ----------------------------------------------------------------------------------------------------------------------------

    その時のダンプファイル(抜粋)です。

    //
    // UMDH: version 6.1.7650.0: Logtime 2010-12-03 15:21 - Machine=PJ-SS-I9 - PID=4288
    //

    // Debug privilege has been enabled.
    // OS version 6.1
    // Umdh OS version 6.1
    //
    // Preparing to dump heap allocations.
    // Only allocations for which the heap manager collected a stack are dumped. Allocations whithout stack are ignored.
    // The stack trace for an allocation is dumped as a list of addresses. They will be resolved to function names at compare time.
    //
    // Connecting to process 4288 ...
    // Process 4288 opened handle=28.
    // Loaded modules:
    //     Base Size Module
    //              3F0000    30000 C:\windows\system32\NOTEPAD.EXE
    //            77C80000   13C000 C:\windows\SYSTEM32\ntdll.dll
    //            77940000    D4000 C:\windows\system32\kernel32.dll
    //            75FF0000    4A000 C:\windows\system32\KERNELBASE.dll
    //            77B10000    A0000 C:\windows\system32\ADVAPI32.dll
    //            77E00000    AC000 C:\windows\system32\msvcrt.dll
    //            76650000    19000 C:\windows\SYSTEM32\sechost.dll
    //            768C0000    A1000 C:\windows\system32\RPCRT4.dll
    //            77AC0000    4E000 C:\windows\system32\GDI32.dll
    //            76580000    C9000 C:\windows\system32\USER32.dll
    //            760D0000     A000 C:\windows\system32\LPK.dll
    //            760E0000    9D000 C:\windows\system32\USP10.dll
    //            778C0000    7B000 C:\windows\system32\COMDLG32.dll
    //            76A70000    57000 C:\windows\system32\SHLWAPI.dll
    //            74D60000   19E000 C:\windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16661_none_420fe3fa2b8113bd\COMCTL32.dll
    //            76C70000   C49000 C:\windows\system32\SHELL32.dll
    //            70580000    51000 C:\windows\system32\WINSPOOL.DRV
    //            76AD0000   15C000 C:\windows\system32\ole32.dll
    //            766F0000    8F000 C:\windows\system32\OLEAUT32.dll
    //            752D0000     9000 C:\windows\system32\VERSION.dll
    //            766D0000    1F000 C:\windows\system32\IMM32.DLL
    //            77BB0000    CC000 C:\windows\system32\MSCTF.dll
    //            75D50000     C000 C:\windows\system32\CRYPTBASE.dll
    //            74BE0000    40000 C:\windows\system32\uxtheme.dll
    //            747F0000    13000 C:\windows\system32\dwmapi.dll
    //            77A20000    83000 C:\windows\system32\CLBCatQ.DLL
    //            71FB0000    F9000 C:\windows\system32\ime\imejp10\imjptip.dll
    //            743D0000    3C000 C:\windows\system32\OLEACC.dll
    //            71EF0000    B8000 C:\windows\system32\imjp10k.dll
    //            71E90000    5E000 C:\windows\system32\ime\shared\imetip.dll
    //            71E80000     B000 C:\windows\system32\ime\shared\imecfm.dll
    //            71E20000    5C000 C:\windows\system32\ime\imejp10\imjpapi.dll
    //            71DF0000    23000 C:\windows\system32\ime\shared\imjkapi.dll
    //
    // Process modules enumerated.
    // Debug library initialized ...
    DBGHELP: ntdll - public symbols 
             D:\localsymbols\ntdll.pdb\8F28FABF69C045F193E62056E642DF5C2\ntdll.pdb

    *- - - - - - - - - - Start of data for heap @ 1600000 - - - - - - - - - -

    REQUESTED bytes + OVERHEAD at ADDRESS by BackTraceID
         STACK if not already dumped.

    *- - - - - - - - - - Heap 1600000 Hogs - - - - - - - - - -

    18 bytes + 18 at 16007E0 by BackTrace0
    B14 bytes + 1C at 1600810 by BackTrace0
    8FC bytes + 1C at 1601340 by BackTrace0
    3C bytes + 1C at 1601C58 by BackTrace0
    30 bytes + 18 at 1601CB0 by BackTrace0
    78 bytes + 18 at 1601CF8 by BackTrace0
    78 bytes + 18 at 1601D88 by BackTrace0

    21C bytes + 1C at 1601E18 by BackTrace710F4
     77CFB2B4
     77CEC2B0
     77CED523
     77CECBDE
     77CE9048
     77CDB365


    42 bytes + 1E at 1602050 by BackTrace71148
     77CFB2B4
     77CE2983
     77CE28BD
     77CDF546
     77CDF699
     77CECC51
     77CE9048
     77CDB365


    78 bytes + 18 at 16020B0 by BackTrace7119C
     77CFB2B4
     77CE1154
     77CDF546
     77CDF699
     77CECC51
     77CE9048
     77CDB365


    10 bytes + 18 at 1602140 by BackTrace711F0
     77CFB2B4
     77CE1A7C
     77CEAA99
     77CEAA08
     77CEA97E
     77CE01AE
     77CDF699
     77CECC51
     77CE9048
     77CDB365


    ・・・・・・・・・

     

     

     

     

     

    2010年12月6日 7:48

回答

  • おそらく、以下のページを参照されているのですよね?
    http://support.microsoft.com/kb/268343/ja

    コールスタックの関数名の出力条件がなぜ分かれているか、正確な理由は把握していませんが、「Umdh.exe を使用した UMDH ログの比較」の節にあるように、ある時点のログと次の時点のログの差分を抽出する際には関数名が出てくるとみられます。

    メモリリークの検出ですから、ある基準となるタイミングでログを書き出し(スナップショットをとり)、リークを疑う操作をして、元の状態に戻ったはずのタイミングでログを書き出し(スナップショットをとり)、その差分を比較することで、元の状態に戻らず、メモリが確保されたままになっている経路を追うという使い方です。

    ただ、ここでいう「VB」がどれにあたるかわかりませんが、umdh を使った手法では自分の知りたいコード、関数を特定できないかもしれません。
    ランタイムがメモリ確保をしており、自分のコードによるリークを見つけられない可能性があるためです。


    質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。
    • 回答としてマーク 山本春海 2011年1月6日 6:35
    2010年12月11日 16:12
    モデレータ