debugging with a pdb file

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

MBB - 13 Jul 2006 19:49 GMT

hello, all,

my problem: my company sells an COM component compiled in VS6 using ATL. one of
our valued customers is having some problems with a beta version of our
component; it crashes their app. they develop in VSdotNET.

i am considering the possibility of providing them with a pdb file along with
the other stuff we would normally give them to test. i understand that this
requires some trust on our part. that is not an issue in this case.

i am exploring the various makefile params needed to generate the single pdb
file and may have questions on that aspect later; but first i want to understand
better what can be accomplished with the pdb file and how i might observe that
functionality on my dev machine.

suppose i have succeeded in creating MyCOMstuff.pdb.
what must i do in a VS6 client to experience the utility of the pdb file?
assume the MyCOMstuff.dll component is registered on my system and its pdb file
is sitting in the same folder as my client exe.

now what do i do?
will i be able to step into method calls to my component?

thanks for any help on this matter.
i can't seem to find a lucid discussion of it anywhere.

Reply to this Message

William DePalo [MVP VC++] - 13 Jul 2006 20:09 GMT

> suppose i have succeeded in creating MyCOMstuff.pdb.
> what must i do in a VS6 client to experience the utility of the pdb file?
[quoted text clipped - 3 lines]
> now what do i do?
> will i be able to step into method calls to my component?

First I should point out that this is not legal advice, but as I understand
it, you may _not_ redistribute the debug DLLs that come with the compiler.
For that reason, for this to work, your client will need to have the whole
debug package installed. Further, since the PDB format changes over time, at
a minimum you will have to insure that the same development that you used to
build your product is available at your client's site.

Rather than doing the debugging at the client site, you might want to create
a mini-dump there and debug after the fact in your shop. This article may
help you get started with that:

http://www.codeproject.com/debug/postmortemdebug_standalone1.asp

Regards,
Will

Reply to this Message

MBB - 13 Jul 2006 20:46 GMT

> First I should point out that this is not legal advice, but as I understand
> it, you may _not_ redistribute the debug DLLs that come with the compiler.
> For that reason, for this to work, your client will need to have the whole
> debug package installed.

sorry if i was imprecise in my description.

i wasn't planning to distribute the debug dlls.
(and i do understand this restriction.)
i was thinking that i would give them a release build with debug info.
after all it's a release version of our component that is crashing their client.

>Further, since the PDB format changes over time, at
> a minimum you will have to insure that the same development that you used to
> build your product is available at your client's site.

i'm not sure what this means.
i would build the component in VS6 in release mode.
i would send them the component and the associated pdb file.
are you saying that their use of VS.net compiler (should i say VC7?) will
"invalidate" the pdb i made in VS6?

> Rather than doing the debugging at the client site, you might want to create
> a mini-dump there and debug after the fact in your shop. This article may
> help you get started with that:
>
> http://www.codeproject.com/debug/postmortemdebug_standalone1.asp

this seems to require that we use the net debugger.
no can do. we're strictly VS6.

Reply to this Message

David Wilkinson - 13 Jul 2006 22:24 GMT

>> First I should point out that this is not legal advice, but as I
>> understand it, you may _not_ redistribute the debug DLLs that come
[quoted text clipped - 18 lines]
> are you saying that their use of VS.net compiler (should i say VC7?)
> will "invalidate" the pdb i made in VS6?

MBB:

You certainly cannot use a VC7 .pdb file in VC6. This is the major
impediment to the holy grail of using the VC7 compiler in the VC6 IDE.

But I think it should work the other way around. In fact, I know you can
use VS.NET as the JIT debugger in VC6.

David Wilkinson

Reply to this Message

Oleg Starodumov - 14 Jul 2006 10:02 GMT

In addition to other replies:

> my problem: my company sells an COM component compiled in VS6 using ATL. one of
> our valued customers is having some problems with a beta version of our
[quoted text clipped - 8 lines]
> better what can be accomplished with the pdb file and how i might observe that
> functionality on my dev machine.

Yes, IMO it is a good practice to ship .pdb file with your component.
The main reason why it can be useful for your customers is that they will be able
to see good call stacks when the application crashes inside your component,
or in a callback made from your component.
Without symbols, and if your component's code is optimized, they are usually
not able to do that.

There are two kinds of symbols you can supply:
- public symbols (enough to get good call stacks and see meaningful function names)
- full symbols (additionally allow to see the types of all variables, values of function
parameters and local variables, and step through source code (if it is available separately))

Usually what you need is to create a .pdb file with only public symbols and ship
it to your customers with the component. For components built with VC6, you can
use Rebase tool to produce public-only .pdb files.

(But if you want your customers to really debug into your component on source level,
you need to send them an unoptimized build of your component, .pdb file with full symbols,
and also send them the source files).

For discussion of related issues, you can take a look at this article:
http://www.debuginfo.com/articles/gendebuginfo.html
(section about Rebase talks about .dbg files; for .pdb files it is used
in exactly the same way)

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]

Reply to this Message

debugging with a pdb file

Free Magazines