Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

PDB Path set

1 view
Skip to first unread message

Karen

unread,
Mar 24, 2008, 1:08:51 PM3/24/08
to
Hello

Im using Visual Studio 2005, I'm trying to build a release version of
an exe and this exe will be deployed on a shared drive. However I'm
doing a build on my own workspace, so the output pdb path is set in
the .vcproj file for the release mode:
$(TargetDir)/prm.pdb

the $(TargetDir) is set to a path that is my work space specific.
Once I moved the exe, the pdb, and other dlls to the shared drive
area, the exe is still looking for the pdb file in my workspace path
(which doesn't exist for people running in their PC)

Any idea how I can make this flexible? (I'm a newbie at VS8, only
recently upgraded to VS6, and we had no such problem) Am i looking at
the right place?

Appreciate your help, I really need the PDB file at run time.

-Karen

Karen

unread,
Mar 24, 2008, 1:23:45 PM3/24/08
to
Actually my question really comes down to, how do you make your exe to
read the pdb from the current directory rather than from the directory
you built it?
Thanks again

Nathan Mates

unread,
Mar 24, 2008, 1:48:47 PM3/24/08
to
In article <80231843-aeef-4e39...@u72g2000hsf.googlegroups.com>,

Karen <karen...@gmail.com> wrote:
>Actually my question really comes down to, how do you make your exe to
>read the pdb from the current directory rather than from the directory
>you built it?

A few possible tricks:

1) Use /pdbpath:none on your linker's commandline, per
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.vc.debugger&tid=7055258b-1943-4d70-83e4-dd1fc587a372&cat=en_US_20e648a8-8c61-4ea2-a166-21b816cb6397&lang=en&cr=US&sloc=&p=1
or
http://www.tech-archive.net/Archive/Development/microsoft.public.development.device.drivers/2006-11/msg00718.html

2) If you're using dbghelp.dll to load your PDB, try calling
SymSetOptions(SYMOPT_LOAD_ANYTHING);

This may help force it to load things, even if the full path
differs.

Nathan Mates


--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein

Karen

unread,
Mar 24, 2008, 3:36:25 PM3/24/08
to
Hi Thanks for the tip. I've tried the /pdbpath:none ... but i get the
following. Does it only work for certain compiler?

1>Compiling...
1>cl : Command line warning D9002 : ignoring unknown option '/
pdbpath:none'
1>stdafx.cpp
1>Compiling...
1>cl : Command line warning D9002 : ignoring unknown option '/
pdbpath:none'

On Mar 24, 1:48 pm, nat...@visi.com (Nathan Mates) wrote:
> In article <80231843-aeef-4e39-8d0e-075001118...@u72g2000hsf.googlegroups.com>,


>
> Karen  <karen.b....@gmail.com> wrote:
> >Actually my question really comes down to, how do you make your exe to
> >read the pdb from the current directory rather than from the directory
> >you built it?
>
>    A few possible tricks:
>

> 1) Use /pdbpath:none on your linker's commandline, perhttp://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg...
> orhttp://www.tech-archive.net/Archive/Development/microsoft.public.deve...


>
> 2) If you're using dbghelp.dll to load your PDB, try calling
>       SymSetOptions(SYMOPT_LOAD_ANYTHING);
>
>    This may help force it to load things, even if the full path
> differs.
>
> Nathan Mates
>
> --

> <*> Nathan Mates - personal webpagehttp://www.visi.com/~nathan/ 
> # Programmer at Pandemic Studios --http://www.pandemicstudios.com/

Nathan Mates

unread,
Mar 24, 2008, 3:56:07 PM3/24/08
to
In article <42c8ed02-f14d-4b5b...@k13g2000hse.googlegroups.com>,

Karen <karen...@gmail.com> wrote:
>Hi Thanks for the tip. I've tried the /pdbpath:none ... but i get the
>following. Does it only work for certain compiler?

It looks like you put /pdbpath:none on the commandline for the
compiler -- for C/C++ files. You need to put it on the commandline for
the *linker* instead.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/

Karen

unread,
Mar 24, 2008, 4:26:37 PM3/24/08
to
Yes thanks, just realized it too. However it still didn't find the
PDB, even though the PDB is in the same directory as the exe. Can you
think of anything else that needs to be done?

The reason I need the PDB so badly is I'm using a StackWalker code
from codeproject.com to dump real time stack trace.

On Mar 24, 3:56 pm, nat...@visi.com (Nathan Mates) wrote:
> In article <42c8ed02-f14d-4b5b-a786-f728b4a00...@k13g2000hse.googlegroups.com>,


>
> Karen  <karen.b....@gmail.com> wrote:
> >Hi Thanks for the tip.  I've tried the /pdbpath:none ... but i get the
> >following.  Does it only work for certain compiler?
>
>    It looks like you put /pdbpath:none on the commandline for the
> compiler -- for C/C++ files. You need to put it on the commandline for
> the *linker* instead.
>
> Nathan Mates
> --

> <*> Nathan Mates - personal webpagehttp://www.visi.com/~nathan/ 
> # Programmer at Pandemic Studios --http://www.pandemicstudios.com/

Nathan Mates

unread,
Mar 24, 2008, 6:08:39 PM3/24/08
to
In article <6d1d5408-015a-4d5b...@a23g2000hsc.googlegroups.com>,

Karen <karen...@gmail.com> wrote:
>Yes thanks, just realized it too. However it still didn't find the
>PDB, even though the PDB is in the same directory as the exe. Can you
>think of anything else that needs to be done?

>The reason I need the PDB so badly is I'm using a StackWalker code
>from codeproject.com to dump real time stack trace.

Go back to my first posting earlier today, where I mentioned
two things to try: (1) the /pdbpath:none . And (2), flags to pass to
SymSetOptions(). You focused on #1.

For what it's worth, in my projects, my code to do the stack
walking includes this code:

BOOL libSuccess = SymInitialize(g_hProcess, useSearchPath, true);
if(libSuccess)
{
DWORD curOpts = SymGetOptions();
#ifdef DEBUG
curOpts |= SYMOPT_DEBUG;
#endif
curOpts &= ~SYMOPT_DEFERRED_LOADS;
curOpts &= ~SYMOPT_EXACT_SYMBOLS;
SymSetOptions(curOpts | SYMOPT_LOAD_LINES | SYMOPT_LOAD_ANYTHING | SYMOPT_NO_PROMPTS | SYMOPT_CASE_INSENSITIVE | SYMOPT_AUTO_PUBLICS);
// [Re]load symbols for all files
SymRefreshModuleList(g_hProcess);
[...]

The LOAD_ANYTHING flag is what I was pointing out earlier.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/

Jochen Kalmbach [MVP]

unread,
Mar 25, 2008, 1:21:57 PM3/25/08
to
Hi Karen!

> The reason I need the PDB so badly is I'm using a StackWalker code
> from codeproject.com to dump real time stack trace.

Have you specified the "SymBuildPath" option!
Then the current directory and the directory of the EXE is already in
the search path!
Then it should find your PDB!

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

Karen

unread,
Mar 25, 2008, 2:13:28 PM3/25/08
to
Thanks, I've also done #2 now. Still did not load it. This is what I
have. I also added a unch of options, but on the list that loaded, it
still didn't load the pdb.
I don't see anywhere else ...


DWORD symOptions = this->pSGO(); // SymGetOptions
symOptions |= SYMOPT_LOAD_LINES;
symOptions |= SYMOPT_FAIL_CRITICAL_ERRORS;
symOptions |= SYMOPT_LOAD_ANYTHING;
symOptions |= SYMOPT_NO_PROMPTS;
symOptions |= SYMOPT_CASE_INSENSITIVE;
symOptions |= SYMOPT_AUTO_PUBLICS;
// SymSetOptions
symOptions = this->pSSO(symOptions);
char buf[StackWalker::STACKWALK_MAX_NAMELEN] = {0};
if (this->pSGSP != NULL)
{
if (this->pSGSP(m_hProcess, buf,
StackWalker::STACKWALK_MAX_NAMELEN) == FALSE)
this->m_parent->OnDbgHelpErr("SymGetSearchPath",
GetLastError(), 0);
}
char szUserName[1024] = {0};
DWORD dwSize = 1024;
GetUserNameA(szUserName, &dwSize);
this->m_parent->OnSymInit(buf, symOptions, szUserName);


the pSGO() and pSSO() are declared and defined as follows

// SymGetOptions()
typedef DWORD (__stdcall *tSGO)( VOID );
tSGO pSGO;

// SymSetOptions()
typedef DWORD (__stdcall *tSSO)( IN DWORD SymOptions );
tSSO pSSO;

pSGO = (tSGO) GetProcAddress(m_hDbhHelp, "SymGetOptions" );
pSSO = (tSSO) GetProcAddress(m_hDbhHelp, "SymSetOptions" );

On Mar 24, 6:08 pm, nat...@visi.com (Nathan Mates) wrote:
> In article <6d1d5408-015a-4d5b-bd91-0d27353af...@a23g2000hsc.googlegroups.com>,

> <*> Nathan Mates - personal webpagehttp://www.visi.com/~nathan/ 
> # Programmer at Pandemic Studios --http://www.pandemicstudios.com/

Karen

unread,
Mar 25, 2008, 2:15:36 PM3/25/08
to
Hi, forgive me for not understanding these windows OS development
options ... where would SymBuildPath be specified?


On Mar 25, 1:21 pm, "Jochen Kalmbach [MVP]" <nospam-

Jochen Kalmbach [MVP]

unread,
Mar 25, 2008, 2:57:22 PM3/25/08
to
Hi Karen !

> Hi, forgive me for not understanding these windows OS development
> options ... where would SymBuildPath be specified?

I thought you are using the StackWalker from CodeProject, aren't you?

http://www.codeproject.com/KB/threads/StackWalker.aspx

If you use the default constructor, then this option is already
activated. If not, you need to be sure to set "SymBuildPath"!

Karen

unread,
Mar 25, 2008, 3:39:26 PM3/25/08
to
On Mar 25, 2:57 pm, "Jochen Kalmbach [MVP]" <nospam-

Jochen.Kalmb...@holzma.de> wrote:
> Hi Karen !
>
> > Hi, forgive me for not understanding these windows OS development
> > options ... where would SymBuildPath be specified?
>
> I thought you are using the StackWalker from CodeProject, aren't you?
>
> http://www.codeproject.com/KB/threads/StackWalker.aspx
>
> If you use the default constructor, then this option is already
> activated. If not, you need to be sure to set "SymBuildPath"!
>

Hi, yes I'm using the default constructor. Just one concern, we use
vs2005, so I guess we'll use dbghelp.h that shipped with vs8. Will
there be things I need to concern with? I won't be able to manipulate
the SymOptions from above posts in StackWalker code anymore?

#if _MSC_VER >= 1300
#include <dbghelp.h>
#else
// inline the important dbghelp.h-declarations...
typedef enum {
SymNone = 0,
SymCoff,
SymCv,
SymPdb,
SymExport,
SymDeferred,
......

Jochen Kalmbach [MVP]

unread,
Mar 25, 2008, 4:27:20 PM3/25/08
to
Hi Karen!

> Hi, yes I'm using the default constructor. Just one concern, we use
> vs2005, so I guess we'll use dbghelp.h that shipped with vs8.

No. Normally, you are using the dbhelp.dll which wa shipped with the OS,
Please download the latest "Debugging Tools for Windows" and use th
edbhelp.dll from there!

> Will
> there be things I need to concern with? I won't be able to manipulate
> the SymOptions from above posts in StackWalker code anymore?

By default, the correct path is already set, you don't need to set
additions options...

Karen

unread,
Mar 25, 2008, 4:44:40 PM3/25/08
to
On Mar 25, 4:27 pm, "Jochen Kalmbach [MVP]" <nospam-

Thank you for your quick turnaround ... I already got the dbghelp.dll
from Debugging Tools for Windows. The only reason it's not dumping
stack because it's not reading the pdb from the same directory. For
example, the deployed directory contains:
prm.exe
prm.pdb
...


however it was still trying to load the entire path of the prm.pdb
that is hardwired in the exe, i.e. $(TargetDir)/prm.pdb
where $(TargetDir) is my workspace path.

This works OK in my PC but won't work in user's pc. As a temporary
workaround, I mirrored the directory structure in the user's PC and
put the PDB there, i.e.
C:\view\CrashMar2008\PRM\bin\edg rw\prm.pdb

(As described in the posts above)

So I put in the linker options /pdbpath:none and the LOAD_ANYTHING
option. Still no luck.

Again, I had no such issues in VS6, I don't understand why VS8 is like
this. In VS6 we've also give similar directory structure as the pdb
path.


Thanks very much for your help... I really wish I can resolve this so
I'm not intruding the user's PC =(

0 new messages