Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Need help debugging memory leak Visual Basic ActiveX-Exe using UMDH-Tools

93 views
Skip to first unread message

D_Schnell

unread,
May 5, 2004, 8:56:05 AM5/5/04
to
Hello,

I'm using the Umdh-Tools to get an snapshot from heap allocations. This is working fine.
But all calls from our application only show the offset address and not the name.

Here an example:

00000050 bytes by: BackTrace02438
ntdll!RtlDebugAllocateHeap+0x000000FD
ntdll!RtlAllocateHeapSlowly+0x0000005A
ntdll!RtlAllocateHeap+0x000008BE
ntdll!LdrpTagAllocateHeap+0x00000024
MSVBVM60!HostCreateInstance4+0x000000EC
MSVBVM60!RcmConstructObjectInstance+0x0000006F
MSVBVM60!__vbaNew+0x00000021
test!+0x007A5C34
MSVBVM60!RUN_INSTMGR::ExecuteInitTerm+0x000000E7
MSVBVM60!RUN_INSTMGR::CreateObjInstanceWithParts+0x0000019B
MSVBVM60!RUN_INSTMGR::CreateObjInstance+0x0000011C
MSVBVM60!RcmConstructObjectInstance+0x0000006F
MSVBVM60!__vbaNew+0x00000021
test!+0x00788215
test!+0x00787BCE
test!+0x00787790
MSVBVM60!CVBThreadAction::SetProjectData+0x00000097
MSVBVM60!CVBThreadAction::Start+0x000000EC
MSVBVM60!CThreadPool::Init+0x0000009A
MSVBVM60!ThunRTMain+0x0000005B
test!+0x0041B6C2

I've tried everything I could find on the web. From creating the pdb. file to include debugging information within the application.

As you can see the windows debugging informations are installed correctly into my windows\symbols directory.

Hope someone can help me with it.

Dirk Schnell

Ivan Brugiolo [MSFT]

unread,
May 5, 2004, 1:59:21 PM5/5/04
to
UMDH.exe gets the symbol path form the _NT_SYMBOL_PATH variable.

can you try to run
c:\debuggers>symchk.exe _full_path_to_test.dll -s %_NT_SYMBOL_PATH% /v /obe
and see if SymChk.exe can find the symbols of your binary ?

BTW, you should use UMDH.exe from the install path of the debugger,
in case you have some old symsrv.dll / dbgeng.dll installed somewhere else
in the path

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"D_Schnell" <anon...@discussions.microsoft.com> wrote in message
news:550C5573-EF7D-4BCF...@microsoft.com...

D_Schnell

unread,
May 6, 2004, 5:36:02 AM5/6/04
to
Thanks for your reply, I have tried symchk and it's now allright but the problem is still the same.

Looking at the following dump snapshot, you see that all calls to system or visual basic functions include the functionname.

ntdll!RtlDebugAllocateHeap+0x000000FD
ntdll!RtlAllocateHeapSlowly+0x0000005A
ntdll!RtlAllocateHeap+0x000008BE
ntdll!LdrpTagAllocateHeap+0x00000024
ole32!DefaultIBindStatusCallback::DefaultIBindStatusCallback+0x00000013
ole32!CCompositeMoniker::RelativePathTo+0x0000014A
ole32!Parse10DisplayName+0x000000EB
ole32!CDefObject::Advise+0x0000001A
ole32!CErrorChannelHook::ClientNotify+0x00000006
MSVBVM60!VBCoGetClassObject+0x00000021
MSVBVM60!COcx::CreateInstance+0x00000197
MSVBVM60!COcx::Load+0x00000028
MSVBVM60!COcx::LoadProp+0x00000030
MSVBVM60!PropLoadProp+0x00000221
MSVBVM60!RbyLoadHctl+0x00000078
MSVBVM60!RbyLoadHctlRecursive+0x0000001E
MSVBVM60!RbyLoadHctlRecursive+0x00000080
MSVBVM60!RbyLoadDeskHctlRecursive+0x00000026
MSVBVM60!CioErrLoadFormDesk+0x000000E4
MSVBVM60!CioErrLoadOnlyFormDesk+0x00000017
MSVBVM60!_LoadForm+0x00000034
MSVBVM60!RefLoadDeskCtl+0x0000001B
test!+0x007BB635
test!+0x00974E62
test!+0x0079872E
test!+0x007986F1
MSVBVM60!RbyExecuteMain+0x0000007C


MSVBVM60!CVBThreadAction::SetProjectData+0x00000097
MSVBVM60!CVBThreadAction::Start+0x000000EC
MSVBVM60!CThreadPool::Init+0x0000009A
MSVBVM60!ThunRTMain+0x0000005B

test!+0x0041AF8A

test! is my application and there is only the offset address.

Is there anyway to get the functionname into the memory dump or is there any workarround?

Thanks,

Dirk Schnell

Ivan Brugiolo [MSFT]

unread,
May 6, 2004, 1:38:31 PM5/6/04
to
If you have good symbols, UMDH will use them.
The code used by UMDH to get a human readable function name
from an address is the same code used by the debugger: SymGetSymFromAddr64.
If you are using the most recent UMDH from the same folder where
the most recent debugger tools are,
then you are using the most recent implementation of SymGetSymFromAddr64.
If you are using the system provided DbgHelp.dll, then youy mileage may
vary.

When the next debugger package will be released,
UMDH will have a -symopt:0x80000000 option,
to help people troubleshooting symbols resolutions problems.
It will print in the log the equivalent spew of `!sym noisy;.reload /f' in
the debugger.
By reading the output, you should get an idea of
why symbols resolution failed for any given module.

Your workaround for now it the following:
attach a non invasive debugger to the process
c:\debuggers>cdb -pv -p PID
set the symbols path as appropriate, then resolve the addressed
0:001>u test!+0x007BB635 l1
If the debugger is unable to resolve the addresses, then use
0:001>!sym noisy;.reload /f
and watch for errors for your module.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"D_Schnell" <anon...@discussions.microsoft.com> wrote in message

news:4197540A-1F49-4494...@microsoft.com...

0 new messages