Great news [MFC]

Prev: CEdit problem
Next: Why exactly is C# better than C++ (was Re: Up to date MFC Book

From: Eric Margheim on 31 Aug 2006 16:46

Got an error with the new build in production. I had the pdb file out there
too so call stack tells me the following:

Call Stack:
MFC42!Ordinal6585 + 0x82
MFC42!Ordinal1585 + 0x3f
MFC42!Ordinal2027 + 0x1a
MFC42!Ordinal2028 + 0xb5
MFC42!Ordinal939 + 0x1e
PRISMRptCom!CReportAccessorFuncs3::SendSimpleMsgNoLogging(struct tagVARIANT
*,class CString,class CString,class CString,struct _Recordset * *) + 0x240
PRISMRptCom!CReportAccessorFuncs3::UpdateReportStatus(struct tagVARIANT
*,unsigned short * *,unsigned short * *,struct _Recordset * *) + 0x2a49
PRISMRptCom!CReportAccessorFuncs::UpdateReportStatus(struct tagVARIANT
*,unsigned short * *,unsigned short * *) + 0x39
PRISMRptCom!CReportAccessor::UpdateReportStatus(struct tagVARIANT *,unsigned
short * *,unsigned short * *) + 0x33
RPCRT4!NdrServerInitialize + 0x462
RPCRT4!NdrStubCall2 + 0x217
RPCRT4!CStdStubBuffer_Invoke + 0x82
OLEAUT32!VariantTimeToDosDateTime + 0x1827
ole32!WdtpInterfacePointer_UserMarshal + 0x13fa
ole32!WdtpInterfacePointer_UserMarshal + 0x13ad
ole32!ProgIDFromCLSID + 0x1fd3
ole32!ProgIDFromCLSID + 0x1dd1
ole32!WdtpInterfacePointer_UserMarshal + 0x1e5f
ole32!WdtpInterfacePointer_UserMarshal + 0x116c
ole32!WdtpInterfacePointer_UserMarshal + 0x1e6f
RPCRT4!I_RpcGetBuffer + 0x1d8
RPCRT4!I_RpcGetBuffer + 0x159
RPCRT4!I_RpcGetBuffer + 0x7f
RPCRT4!NdrConformantArrayMemorySize + 0x558
RPCRT4!MesEncodeIncrementalHandleCreate + 0xadc
RPCRT4!NdrSimpleStructMemorySize + 0x12ac
RPCRT4!NdrSimpleStructMemorySize + 0x138c
RPCRT4!NdrSimpleStructMemorySize + 0x1224
RPCRT4!NdrSimpleStructMemorySize + 0xbec
RPCRT4!NdrSimpleStructMemorySize + 0xc2d
RPCRT4!NdrSimpleStructMemorySize + 0x8de
RPCRT4!I_RpcTransGetThreadEvent + 0x39c
RPCRT4!I_RpcTransGetThreadEvent + 0x188
RPCRT4!I_RpcLogEvent + 0xe92
kernel32!GetModuleFileNameA + 0xeb

"Oleg Starodumov" <com-dot-debuginfo-at-oleg> wrote in message
news:O$JLF9SzGHA.2036(a)TK2MSFTNGP05.phx.gbl...
>
> This time symbols look correct, so 'x' and 'ln' should work,
> at least for the first function on the call stack that belongs to this
> DLL.
>
> If the results are still incorrect, there can be various reasons. E.g.:
> - the version of the DLL that is loaded into debugger is not the same as
> the one the call stack was taken for (it must be exactly the same build)
> - if some modules precede your DLL on the call stack, and they are
> built with FPO optimization, the whole call stack can be incorrect
> (in this case, correct results (for the approach we are trying to use)
> can be achieved
> usually only if the application was running on XP-SP2 and 2003-SP1)
>
> Minidumps are not subject to all these issues, and usually always give
> correct call stacks in such situations.
>
> Oleg
>
>
>

From: Eric Margheim on 31 Aug 2006 18:09

OK So how do I now take this info with function name + offset and get the
exact line?

I'm still struggling with that part.

Thanks

From: Oleg Starodumov on 1 Sep 2006 02:53

> OK So how do I now take this info with function name + offset and get the
> exact line?
>

1. Load the application into VC debugger (so that exactly the same build
of the DLL is loaded). Ensure that the DLL's symbols are loaded.

2. Look up the target function (SendSimpleMsgNoLogging) in sources.
R-click anywhere in the function's source and choose Go to Disassembly.

3. Determine the address mentioned on the call stack (add the offset
to the start address of the function, which can be found in Disassembly window).

4. In Disassembly window, R-click on that address and choose Go to Source.

Note that if the DLL was built with optimizations, source information
will not necessarily be correct (but should be close enough).

Oleg

From: Eric Margheim on 1 Sep 2006 08:26

From: Eric Margheim on 1 Sep 2006 09:45

"Oleg Starodumov" <com-dot-debuginfo-at-oleg> wrote in message
news:uqSZgNZzGHA.1256(a)TK2MSFTNGP04.phx.gbl...
>
>> OK So how do I now take this info with function name + offset and get the
>> exact line?
>>
>
> 1. Load the application into VC debugger (so that exactly the same build
> of the DLL is loaded). Ensure that the DLL's symbols are loaded.

Loaded 'c:\windows\system32\dllhost.exe', no matching symbolic information
found.
Loaded 'ntdll.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\msvcrt.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\ole32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\advapi32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\rpcrt4.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\gdi32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\user32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\shimeng.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\apphelp.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\clbcatq.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\comres.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\oleaut32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\version.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\ntmarta.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\samlib.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\wldap32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\xpsp2res.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\nview.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\shlwapi.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\shell32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\psapi.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\winmm.dll', no matching symbolic information
found.
Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1830_x-ww_7AE38CCF\comctl32.dll',
no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\rdpsnd.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\winsta.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\netapi32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\comsvcs.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\rsaenh.dll', no matching symbolic information
found.
The thread 0x980 has exited with code 0 (0x0).
Loaded 'C:\WINDOWS\system32\odbc32.dll', no matching symbolic information
found.
Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.1830_x-ww_1B6F474A\comctl32.dll',
no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\comdlg32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\odbcint.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\es.dll', no matching symbolic information found.
The thread 0x15C4 has exited with code 0 (0x0).

> 2. Look up the target function (SendSimpleMsgNoLogging) in sources.
> R-click anywhere in the function's source and choose Go to Disassembly.

Nothing happens when I choose the Go to Disassembly option. I have the
Release version running in debug under dllhost.exe like I typically do to
debug components.

> 3. Determine the address mentioned on the call stack (add the offset
> to the start address of the function, which can be found in Disassembly
> window).
>
> 4. In Disassembly window, R-click on that address and choose Go to Source.
>
> Note that if the DLL was built with optimizations, source information
> will not necessarily be correct (but should be close enough).
>
> Oleg
>
>
>
>

| Next | Last
Pages: 1 2
Prev: CEdit problem
Next: Why exactly is C# better than C++ (was Re: Up to date MFC Book