Use of WinDbg with MFC42 symbols and source

[Mike Mehr]

Hi all,

I am trying to use WinDbg v4.0 in Source mode with Visual C++ 6.0 code
to inspect crash dumps generated by USERDUMP.EXE (from the Debugging
Tools for Windows 2000). Our code runs under Windows NT4 SP5, as do
our development stations that we run WinDbg on for these inspections.

When I attempt to examine source code for functions in MFC42.DLL
(which show up on the call stack with names like "Ordinal6375"), the
real function name does not show up, and no source code is activated,
even though I have pointed the Source Path setting to the MFC source
code on the hard disk. I also have the relevant MFC42.PDB file in a
directory found in the Symbol Path.

Does anyone know if this problem is fixed in any more recent version
of WinDbg (6.0.x seems to be the latest)? Or whether there is any way
to get the MFC symbols to display and link to source? I understand
that the issue is one of having the symbol names stripped from the
files, but Microsoft has provided the MFC42.DEF file to show the
mapping. Are there any tools or utilities that could "stitch" the
names back together properly? Does anyone have any other suggestions
for how this might be made to work? Or have any further information
that I might use to come up with a solution? I'd appreciate hearing
about it.

We're trying to get this working to help the junior programmers new to
the staff come up to speed on debugging issues and for a deeper
understanding of the MFC framework. (We don't expect to be finding or
fixing bugs in MFC source, just looking at what is going on. :))

Thanks for any help. Feel free to contact me off-list as well.
Regards,
Mike Mehr
Systems Software Engineer
FaST Division, KLA-Tencor Corporation
mike...@kla-tencor.com

[Pat [MSFT]]

Definitely try the newer debugger regardless. It is much better at stack
walking and is Symbol server aware (see the web site), so it should be
easier for you in general. As to the MFC source pointers, it could be that
the symbols you are using are stripped (i.e. function info only, no source),
but I would check w/the new debugger first. Also, you can try setting the
'image path' to include the directory that contains the MFC dll.

Pat

"Mike Mehr" <mike...@kla-tencor.com> wrote in message
news:83949c8f.03071...@posting.google.com...

[Pat Styles [MS]]

Hi, Mike.

As you said, the symbolic information has been stripped and consequently the
debugger is unable to know the names. No version of any Microsoft debugger
uses .DEF files to help resolve symbol names. I can only presume that the
file was provided to you as a manual aid.

.pat styles

"Pat [MSFT]" <patf...@online.microsoft.com> wrote in message
news:uN$SptXTD...@TK2MSFTNGP10.phx.gbl...

[Jon Wold]

Guessing that what Mike would like is a tool that dummies up (or
enhances) a .pdb for a .dll given the dll itself and the .lib used to
link, which does provide names for export by-ordinal.

Manually, I use depends so I can sort the addresses and locate the
nearest match, then dumpbin /headers on the .lib and search for the
corresponding ordinal, then extract the decorated name and demangle via
undname -f.

Jon