トップ回答者
UMDH.EXEで関数名がダンプ出力されない

質問
-
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 BackTrace021C 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
・・・・・・・・・
回答
-
おそらく、以下のページを参照されているのですよね?
http://support.microsoft.com/kb/268343/jaコールスタックの関数名の出力条件がなぜ分かれているか、正確な理由は把握していませんが、「Umdh.exe を使用した UMDH ログの比較」の節にあるように、ある時点のログと次の時点のログの差分を抽出する際には関数名が出てくるとみられます。
メモリリークの検出ですから、ある基準となるタイミングでログを書き出し(スナップショットをとり)、リークを疑う操作をして、元の状態に戻ったはずのタイミングでログを書き出し(スナップショットをとり)、その差分を比較することで、元の状態に戻らず、メモリが確保されたままになっている経路を追うという使い方です。
ただ、ここでいう「VB」がどれにあたるかわかりませんが、umdh を使った手法では自分の知りたいコード、関数を特定できないかもしれません。
ランタイムがメモリ確保をしており、自分のコードによるリークを見つけられない可能性があるためです。
質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。- 回答としてマーク 山本春海 2011年1月6日 6:35