Is there a way to update the PDB file with the new source location ? I have a project which links to some libraries which are built on another machine and are debug build with the PDB file. I cannot put a breakpoint in the files which are compiled in the libs. These libs take more than 4 hours to build so I dont want to buid them on my machine. Is there a way where i can make the compiler use the new source paths. I am using VS 2005 pro c++.
Thanks
Amit
Instead of modifying the .pdb files to adjust to where you have your source, you should be able to make the debugger see the new source path. Look here for instructions on doing this in Visual Studio, and here for instructions on doing this in WinDbg.
Another this StackOverflow question: Best Visual Studio 2008 Debugging Tutorial.
Is the debugger picking up the .pdb files from the wrong location? Do you have a copy of the .pdb files that match the binaries (i.e. .exe, .dll) that you are executing? Keep in mind that the .pdb files can only be used if they were created at the same time as the exact binaries you are executing.
Try the following:
Rename the (stale) .pdb file that the debugger wants to load, so the debugger will no longer try to pick it up.
Go to Tools->Options->Debugging->Symbols and add the symbol file (.pdb) location to the list.
If the debugger is already attached, right click on the module in the "Modules" list and click "Load symbols". This will re-load the symbols from the path you entered.
Also, if you know the code is exactly the same, but your .pdb file doesn't match the binaries you are using because they were created during different builds, try un-checking the following checkbox:
Tools->Options->Debugging->Require source files to exactly match the original version
Related
I have a Visual Studio 2017 C++ project which depends on ffmpeg libraries. As of now it crashes at run time because of the missing dependency avformat-58.dll. I've tried adding this file into the project by dragging it into my project but that does not suffice. I tried looking at the Add Reference screen but it is empty. What can I do?
On the advice of #HansPassant I added the dll(s) to the project as existing external files. I think there should now be an option somewhere to "Copy to output directory" but I'm not seeing it. Here is what I see when I open property pages of one of the dlls.
#sellotape Here is a screenshot of the window when I just single click.
According to this documentation https://learn.microsoft.com/en-us/windows/desktop/Dlls/dynamic-link-library-search-order I can copy the necessary dlls to any directory in the PATH environment variable. There were many dlls already in C:/Windows/System32 already so I just put the ffmpeg dlls there as well and the executable runs.
I did the following experiment: I created a statically linked C++ library solution MyLibrary (I took the code from the MSDN example: https://msdn.microsoft.com/en-us/library/ms235627.aspx.) and built it. Then I created another C++ solution MyConsoleApp, using the console application template in Visual Studio (2017). I copied the MyLibrary.lib file to the root of MyConsoleApp project and added MyLibrary.lib to Linker -> Input -> Additional Dependencies (also had to copy over the headers too of course). What I didn't do was to copy over the MyLibrary.pdb file.
I would've expected to get a linker warning about the missing .pdb file but this was not the case. Then I moved only MyConsoleApp to another machine and tried to build it again, this time getting a missing .pdb linker warning. It seems that Visual Studio is storing the .pdb files when building a solution somewhere on the machine and is able to use those .pdb files when linking other solutions on the same machine.
I would like to be able to disable this behaviour or to be able to remove the cached .pdbs so that I could be sure that when sharing work with other developers they won't get warnings that I'm not getting on my own machine.
Visual Studio doesn't cache the .pdb file. What happens here is that the absolute path to the original .pdb file is stored in the build outputs (.exe, .dll or .obj files) and Visual Studio is able to took it up based on that.
Check this answer for a way to prevent that: Remove PDB references from released file.
I have included a dll file into my project. I reference it from a library folder where also resides dll's pdb file. When I compile I see both dll and pdb copied to main project's bin folder. On small projects this works wonderfully and I can debug into the dll with no problems. Sometimes, however, in larger projects, VS keeps asking for specific cs files even though their pdb file is included in the projects bin folder. That's ok if I can find those cs files, but it's annoying.
Why is Visual Studio sometimes asking for cs files and sometimes not?
It tries its best given the information it has, but sometimes that information is incomplete. When its ready to give up, it gives you the opportunity to provide the file, just in case you know better.
PDBs generally store the path to the file, as it was when msbuild was invoked to build the DLL. If the paths have changed (e.g. you're on a different machine to where the DLL was built, or just that files on the file system have moved) then the path information doesn't do it much good.
There is a process called source indexing that can embed enough information into the PDBs so that visual studio can re-locate the source files in your source control system (so that you get exactly the correct file as it was at the time of the build) but this is usually an extra step that has to be performed to modify the PDBs after the build has occurred.
Try this (from MSDN Forum)
Tools -> Options -> Debugging -> Symbols -> Empty Symbol Cache (button)
then
Tools -> Options -> Debugging General-> Enable Just My Code (checkbox)
and start debugging again. This should solve the problem if it was initiated by accidental third party components debug symbols that doesn't contains sources but storye only file paths.
In Visual Studio 2003, if I link with a library that doesn't have its corresponding PDB file, I get a warning:
foo.lib(bar.obj) : warning LNK4099: PDB 'other.pdb' was not found; linking object as if no debug info
If the PDBs are in their original build location VS can find them, as well as if they're in the current build directory, but that seems to be it. Is there a way I can tell Visual Studio exactly where it should look for PDBs? I have a vague notion that a symbol server might work, but that seems like a lot of overhead; I'm just looking for something like link.exe /pdbpath c:\pdbs_are_right_here that adds a path to search, like /I adds an include path. Alternately, are there other paths it searches besides the current directory and the original absolute path the PDB was written to?
I believe the path to the corresponding pdb's is embedded in the libraries themselves, and you can change it into c:\pdbs_are_right_here at the build switches for your libraries (assuming they are indeed yours and not 3rd party).
For DLL's that means project properties\linker\debugging\generate program database file.
For static libraries the default name is uniform in VS2013 ('vc120.pdb'), but I think this changed in VS2015 and have no idea about VS2003. Anyway if you're working in VS2013\2012\2010 you'd have to explicitly override the name too.
This confusing feature in ReSharper claims to let you browse external sources from within Visual Studio, see External Sources (ReSharper Web Help).
But, I don't understand what values to set for the folder substitution option. (Resharper - Options - External Sources - Advanced)
When I try navigating to source, I keep getting the message:
PdbNavigator: No sources found in debugging information for in assembly
(This is almost a duplicate of Stack Overflow question Visual Studio - Attach source code to reference, but that post did not explain HOW to attach external sources.
This is tricky, and I finally figured it out:
Click "Show current path settings and PDB files binding" and look at where the PDB points to for source.
Add a folder substitution where the source code is where the PDB says the source code is (probably a path not on your computer, but on the system that compiled the DLL file and PDB). Set the target to the source you downloaded.
Here's a screenshot: