Re: tracking down error in MFC42.dll

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.


I put the .pdg file on the production server along with a debug build of the
DLL with debug information turned on. I'll see if I get an error today
what the call stack shows.

In the interim I'd like to try to use WinDbg to look into my DLL and use the
call stack info from yesterdays error, which was for a Release DLL with
debug symbols turned on.

I'm a real WinDbg neophyte so bare with me. Since dllhost.exe is the
actual process attaching to it is not going to get me where I need to go, is
this correct? Do I have to change my application to load my DLL inprocess
in order to dig into it to find out what code the call stack is referring
to?

Thanks for all your help.


.

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: Symbols not loaded for DLLs
    ... I tried WinDbg 6.5.3.7 and was able to load symbols and debug the DLL ... The only thing I had to do was set the symbol path to point to my pdb ... Debug Data Dirs: Type Size VA Pointer ...
    (microsoft.public.vc.debugger)
  • Re: tracking down error in MFC42.dll
    ... The beginning of the call stack resolves to the following: ... Run an application that uses mfc42.dll under debugger, ... The same could be done for your dll if it would be built with debug information ... If you put symbols of your dll on the target system, ...
    (microsoft.public.vc.mfc)
  • Re: How to connect to children process
    ... I'm creating code with int 3 in place that I'm willing debug. ... Then project is rebuild in VS 2003 and target DLL is copied to remote PC ... Thanks to your help I'm able now using WinDbg on local machine. ... I'm not sure if VS debugger provides any API, ...
    (microsoft.public.vsnet.debugging)
  • 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)