Re: tracking down error in MFC42.dll


Call Stack:
MFC42!Ordinal6585 + 0x82
MFC42!Ordinal1585 + 0x3f
MFC42!Ordinal2027 + 0x1a
MFC42!Ordinal926 + 0x56
PRISMRptCom!DllUnregisterServer + 0x32fd4
PRISMRptCom!DllUnregisterServer + 0x2c299
PRISMRptCom!DllUnregisterServer + 0x641e

The beginning of the call stack resolves to the following:

mfc42!CFixedAlloc::Alloc + 0x82
mfc42!CString::AllocBuffer + 0x3f
mfc42!CString::ConcatCopy + 0x1a
mfc42!operator+ +0x56

How did you resolve this?


1. Found the same version of mfc42.dll (it comes with Win2003 SP1).

2. Determined the addresses of the exported functions mentioned on the
call stack (Ordinal*). (I used WinDbg to do that, but the same can be done
with Dumpbin, Depends, etc.)

3. Run an application that uses mfc42.dll under debugger, downloaded symbols
for mfc42.dll from the MS symbol server, and used the debugger to determine
what function names correspond to the given addresses ('ln' command in WinDbg
is very convenient for that (and VS2005 has a similar command), in older VC
debuggers simply select the given address in Disassembly window and see
what function it belongs to).

The same could be done for your dll if it would be built with debug information
(so in general it is recommended to generate debug information for release builds too)

This part of the call stack is correct, so if necessary, it should be
possible to recover the name of the first function that belongs to your component
(it will be possible if your component was built with debug information).

This was with a release version that did not have debug info. I'm
attempting to duplicate with a debug version. If I can what tools do I
need to determine what function was the last function called within my code?


If you put symbols (.pdb) of your dll on the target system (in the same directory with the dll),
you will probably get the correct call stacks automatically. If symbols were not available
by some reason, use the same approach as above - determine the location of
DllUnregisterServer in your dll, and use it (and debugger on your local machine)
to calculate the function addresses and find the function names.

Oleg
http://www.debuginfo.com/






.

Relevant Pages

  • Re: How to connect to children process
    ... Main problem is amount of manual operations required per debug cycle. ... connection to DLL with debugger takes sensible amount of time and manual ... Is the main problem that the debugger keeps symbols file loaded ... AFAIK that's how VS2003 debugger works, but WinDbg should usually ...
    (microsoft.public.vsnet.debugging)
  • Re: Need Help Debugging
    ... you should use straight and plain ADPlus.VBS from the debugger package. ... debug info loaded, etc... ... does that avoid using the stack ?!? ... which is our custom CRITICAL_SECTION class. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: AD+ crash logs and .dmps Part II
    ... This a .dll provided by an online payment verification ... The Debugger docs have some basic info but overall, understanding ... details the formation and usage of the stack. ...
    (microsoft.public.inetserver.iis.security)
  • Re: tracking down error in MFC42.dll
    ... (I used WinDbg to do that, but the same can be done ... The same could be done for your dll if it would be built with debug ... If you put symbols of your dll on the target system (in the same ... what the call stack shows. ...
    (microsoft.public.vc.mfc)
  • Re: How to connect to children process
    ... AFAIK that's how VS2003 debugger works, ... unload symbols completely after the dll ... Also, when setting breakpoint on the needed function (in WinDbg), ... I'm creating code with int 3 in place that I'm willing debug. ...
    (microsoft.public.vsnet.debugging)