unable to set breakpoint

[Dave Calkins]

Here's an issue for which I have a workaround, but am still curious as to
why the workaround is necessary. We're using Visual C++ 2005 (v8).

We're using a third party library for which we have the source. We build
the third party library from source in its directory structure and then copy
the resultant binaries to a different "installed" location. This
"installed" location is what gets used by our applications when linking and
compiling and contains all the headers and the built binaries.

Recently we needed to step into the third party library source to diagnose a
problem. In studio, with one of the application projects open, I opened one
of the source files in the third party library source dir and clicked the
margin to set a breakpoint. I then hit F5 to run with debugging.

When the app started the breakpoint turned to the hollow circle and the
mouse-over indicated that the breakpoint could not be set because symbols
were not loaded for the source file.

I opened the modules list, found the third party module and the window
indicated that the symbols, in fact, had been loaded.

Any ideas why I could not set the breakpoint? I also tried using WinDbg
directly and it wouldn't give me a source view after stepping into one of
the third party library function calls.

Here's the workaround. I ended up referencing the third party libraries at
their source directory location (where they were originally built) as
opposed to the "installed" location. No idea why this did it.

Any thoughts?

[Jeffrey Tan[MSFT]]

Hi Dave,

The reason is that you need a way to tell the debugger where to find the
source code.(I assume you did not add the 3rd party as a VS project into
the current solution, yes?). There maybe a source code path embeded in the
pdb file, but it is the static file system path of the original development
machine(3rd party company machine) which is obviously invalid on your
machine.

The best practise is using the source server support of VS2005. You may
first turn off "Just My Code" option and enable "Enable Source Server
Support" option in Tools > Options > Debugging > General. Also, you may
have to setup the source server with Source Server binaries from "Debugging
Tools for Windows", please refer to the articles below for details and
steps:
"Source Server Helps You Kill Bugs Dead In Visual Studio 2005"
http://msdn.microsoft.com/msdnmag/issues/06/08/UseTheSource/default.aspx
"Configuring Visual Studio to Debug .NET Framework Source Code"
http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to
-debug-net-framework-source-code.aspx

Additionally, if you turn-off "Just My Code" and try to press "F11" to step
into the 3rd party dll code, I think VS debugger will pop up a dialog for
you to select the path for the source code. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Dave Calkins]

Post by Jeffrey Tan[MSFT]
The reason is that you need a way to tell the debugger where to find the
source code.(I assume you did not add the 3rd party as a VS project into
the current solution, yes?). There maybe a source code path embeded in the

That is correct, I did not add the 3rd party library as a project in the
solution. I updated the VS directories for include files and library files
to point to the installed location where the .lib/.dll/.pdb/.h files reside.

Post by Jeffrey Tan[MSFT]
There maybe a source code path embeded in the
pdb file, but it is the static file system path of the original development
machine(3rd party company machine) which is obviously invalid on your
machine.

No, that is not correct since I compiled the 3rd party library from source
on my local machine which is the same machine I'm debugging on. I have the
3rd party library source tree on my local machine and I compiled it there.
I then copied the binaries (.dll/.lib/.pdb) to an installed location on the
same machine where they're referenced.

The breakpoint wouldn't work with that setup. When I instead referenced the
binaries in their original built location on the same machine, it worked.
In either case, any absolute source paths should be valid since the code was
built on the same machine I'm using to debug.

Post by Jeffrey Tan[MSFT]
The best practise is using the source server support of VS2005. You may
first turn off "Just My Code" option

In the options dialog the full text of that option is "Just My Code (Managed
Only)". Since this is all native C++ code this doesn't appear to apply.
Also, as I indicated, I was able to reference the libs from their original
location and the breakpoints worked fine so I don't think this option was
coming into play.

Post by Jeffrey Tan[MSFT]
enable "Enable Source Server
Support" option in Tools > Options > Debugging > General. Also, you may
have to setup the source server with Source Server binaries from "Debugging
Tools for Windows", please refer to the articles below for details and
"Source Server Helps You Kill Bugs Dead In Visual Studio 2005"
http://msdn.microsoft.com/msdnmag/issues/06/08/UseTheSource/default.aspx
"Configuring Visual Studio to Debug .NET Framework Source Code"
http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to
-debug-net-framework-source-code.aspx

I've read about the source server and perhaps need to do more reading. It
sounds like a good way to manage source, but in my situation I was able to
get it working without that and I don't understand why. Since it was able
to find the source once I referenced the binaries in their original build
location, it seems that source debugging will work just fine without a
source server, the question is just why this was needed and why it couldn't
find the source when the libs were somewhere else. If the source file
absolute path is stored in the PDB, then why couldn't it find it regardless
of where the PDB file was on disk?

Post by Jeffrey Tan[MSFT]
Additionally, if you turn-off "Just My Code" and try to press "F11" to step
into the 3rd party dll code, I think VS debugger will pop up a dialog for
you to select the path for the source code. Thanks.

I was able to step in using F11 and it did not prompt for a source file. My
experience was that either it did nothing (original configuration) or worked
(after referencing the libs in their original build location).

Are you aware of a tool I can use to examine the PDB file and see what
source path is stored therein? Maybe that would help. I haven't had any
luck peeking into the PDB file to see what source is referenced.

[Dave Calkins]

I found the problem. One of those "duh!" moments :)

When I built the 3rd party library from source, I enabled generation of the
symbol (.pdb) file using the below project option.

Linker>>Debugging>>Generate Debug Info = "Yes"

However, I had neglected to also do this in the C/C++ section of the project
options shown below.

C/C++>>General>>Debug Information Format = "Program Database"

So, although a .pdb was being generated, and was being loaded (hence the
modules window showing the symbols as loaded), the .pdb did not have any
source references in it.

I discovered this by using the "strings" command which takes a binary file
and dumps out all printable strings found in the file. I noticed that the
release .PDB file (I'm debugging in a release build) lacked any reference to
the third party sources, but that the debug .PDB file had them. This led me
to comparing project options and noticing the C/C++ debug option had not
been set for the release build of the third party library.

By updating the C/C++ option, I'm not able to set a breakpoint and do
source-level debugging on the library regardless of where its located on my
machine.

Having said all this, it is interesting to note that my original workaround
was to leave the generated binaries where they were originally put by the
build process. By doing this, VS somehow found the source files. But now I
know that the .PDB didn't reference any source files. Not exactly sure how
VS found the source files at all even with the binaries in their original
location, unless it used the object file names and was able to pull source
names from those?

Post by Dave Calkins
Here's an issue for which I have a workaround, but am still curious as to
why the workaround is necessary. We're using Visual C++ 2005 (v8).
We're using a third party library for which we have the source. We build
the third party library from source in its directory structure and then
copy the resultant binaries to a different "installed" location. This
"installed" location is what gets used by our applications when linking
and compiling and contains all the headers and the built binaries.
Recently we needed to step into the third party library source to diagnose
a problem. In studio, with one of the application projects open, I opened
one of the source files in the third party library source dir and clicked
the margin to set a breakpoint. I then hit F5 to run with debugging.
When the app started the breakpoint turned to the hollow circle and the
mouse-over indicated that the breakpoint could not be set because symbols
were not loaded for the source file.
I opened the modules list, found the third party module and the window
indicated that the symbols, in fact, had been loaded.
Any ideas why I could not set the breakpoint? I also tried using WinDbg
directly and it wouldn't give me a source view after stepping into one of
the third party library function calls.
Here's the workaround. I ended up referencing the third party libraries
at their source directory location (where they were originally built) as
opposed to the "installed" location. No idea why this did it.
Any thoughts?

[Jeffrey Tan[MSFT]]

Hi Dave,

Thanks for your detailed feedback and sorry for the late response, I am out
of office yesterday.

Sorry, I am a bit confused by your following statement:
"By updating the C/C++ option, I'm not able to set a breakpoint and do
source-level debugging on the library regardless of where its located on my
machine."

I am not sure if the word "not" is a typo or not since you said you had
found the problem.

Regarding your original workaround, I suspect this is an internal algorithm
of VS debugger. Actually, the simplest way to tell the VS debugger where to
probe the source code files is setting the "Source Paths":
Right click Solution / Properties / Source Paths

This should be a simple solution without maintaining a source server.

Regarding the debug information generation in compiler and linker, the
great article below should be informative:
"generating debug information with visual c++"
http://www.debuginfo.com/articles/gendebuginfo.html

The PDB file format is undocumented, so I do not know of a tool to examine
it yet.(If anyone can share one, I'd like to hear) I think we have to use
dbghelp.dll API to check the source file information in it. Another simple
way is using the "!lmi" command in windbg, see the "Load Report: private
symbols & lines, source indexed" line below:

0:000> !lmi ntdll
Loaded Module Info: [ntdll]
Module: ntdll
Base Address: 7c800000
Image Name: ntdll.dll
Machine Type: 332 (I386)
Time Stamp: 45d70ad8 Sat Feb 17 22:02:00 2007
Size: c0000
CheckSum: bd6f9
Characteristics: 210e perf
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 22, 86a6c, 85e6c RSDS - GUID:
{93E72E10-9DC8-4F16-AA54-797E4DA8C168}
Age: 2, Pdb: ntdll.pdb
CLSID 4, 86a68, 85e68 [Data not mapped]
Image Type: FILE - Image read successfully from debugger.
C:\WINDOWS\system32\ntdll.dll
Symbol Type: PDB - Symbols loaded successfully from symbol server.

c:\LocalSymbols\ntdll.pdb\93E72E109DC84F16AA54797E4DA8C1682\ntdll.pdb
Compiler: C++ - front end [13.10 bld 4035] - back end [13.10 bld
4035]
Load Report: private symbols & lines, source indexed

c:\LocalSymbols\ntdll.pdb\93E72E109DC84F16AA54797E4DA8C1682\ntdll.pdb

Hope it helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Dave Calkins]

Post by Jeffrey Tan[MSFT]
"By updating the C/C++ option, I'm not able to set a breakpoint and do
source-level debugging on the library regardless of where its located on my
machine."
I am not sure if the word "not" is a typo or not since you said you had
found the problem.

sorry, talk about an inconvenient typo :) It was supposed to say, "I'm now
able to set a breakpoint ...", i.e. its working now and I don't need to have
the binaries in their original built locations.

Post by Jeffrey Tan[MSFT]
Regarding your original workaround, I suspect this is an internal algorithm
of VS debugger. Actually, the simplest way to tell the VS debugger where to
Right click Solution / Properties / Source Paths
This should be a simple solution without maintaining a source server.

Yes, the source paths do seem to work well when needed. Once I understood
what was going on, I renamed the source dir to "hide" it and sure enough,
when trying to step in the code VS prompted me for the source file. I added
the altered directory to the source path and it then found it on its own.

Granted, with this approach its purely filename matching which is where the
source server you mentioned earlier would come in. I haven't yet
investigated as to whether or not it would work with our revision control
system (the info I've read about it refers to VSS and I think CVS).

Post by Jeffrey Tan[MSFT]
Regarding the debug information generation in compiler and linker, the
"generating debug information with visual c++"
http://www.debuginfo.com/articles/gendebuginfo.html
The PDB file format is undocumented, so I do not know of a tool to examine
it yet.(If anyone can share one, I'd like to hear) I think we have to use
dbghelp.dll API to check the source file information in it. Another simple
way is using the "!lmi" command in windbg, see the "Load Report: private
0:000> !lmi ntdll
Loaded Module Info: [ntdll]
Module: ntdll
Base Address: 7c800000
Image Name: ntdll.dll
Machine Type: 332 (I386)
Time Stamp: 45d70ad8 Sat Feb 17 22:02:00 2007
Size: c0000
CheckSum: bd6f9
Characteristics: 210e perf
Debug Data Dirs: Type Size VA Pointer
{93E72E10-9DC8-4F16-AA54-797E4DA8C168}
Age: 2, Pdb: ntdll.pdb
CLSID 4, 86a68, 85e68 [Data not mapped]
Image Type: FILE - Image read successfully from debugger.
C:\WINDOWS\system32\ntdll.dll
Symbol Type: PDB - Symbols loaded successfully from symbol server.
c:\LocalSymbols\ntdll.pdb\93E72E109DC84F16AA54797E4DA8C1682\ntdll.pdb
Compiler: C++ - front end [13.10 bld 4035] - back end [13.10 bld
4035]
Load Report: private symbols & lines, source indexed
c:\LocalSymbols\ntdll.pdb\93E72E109DC84F16AA54797E4DA8C1682\ntdll.pdb
Hope it helps.

Yes, thanks for your help. Note that what I did was use the "strings"
command. This is a unix command which pulls out all the printable strings
from a file. You can use this (as well as many other unix shell commands)
on Windows with the help of cygwin (www.cygwin.com). So in my case, I was
able to do the below in a cygwin shell to list all source files contained in
the .PDB.

strings myfile.pdb | grep '.cpp'

[Jeffrey Tan[MSFT]]

Hi Dave,

Thanks for your the feedback and glad to see it works for you.

Yes, I believe using "strings" is a somewhat hacky way to retrieve all
printable strings in the file :-). Anyway, it is useful in our
troubleshooting world.

Actually, Mark Russinovich has written a Windows version of Strings.exe
here, so there is no need for us to rely on the Unix toolset now:
http://technet.microsoft.com/en-us/sysinternals/bb897439.aspx

Anyway, it is good to know that cygwin has this unix shell command sets on
Windows. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.