I am working in Visual Studio 2010 VC++. I am trying to debug a release build. I have it in release mode, and made all of the changes noted in the following link:
http://msdn.microsoft.com/en-us/library/fsk896zz(v=vs.100).aspx
As well as rebuilt the solution. The breakpoints are still complaining that the symbols have not been loaded.
When I try to debug, I have looked at the modules window and tried to hand-locate the PDBs. However, I have over 100 DLLs, half of which say "Cannot find or open the PDB file."
Do I need to manually go through and search for all of these PDB files? I started, but I checked out the code from a company repository and all of the PDBs are all over the place, it's a little bit of a mess. Also, if I can find the PDB file, sometimes the dates don't match up with the DLLs, and Visual Studio doesn't take them. I thought the PDB files were created when the project was built, so I thought they would be created again when I re-built the project, but maybe I am incorrect?
Is there any way around this problem, and is finding the PDBs the correct solution to being able to hit the breakpoints?
Related
I find it strange, because I rebuild the same code. Theoretically the dll and pdb file should be the same, because the code does not change. Even if it changes, where the breakpoints are located should not be changed.
I want to version my visual studio 2010 debug builds. I'm going to use git. Right now all the project files are in 'project' and the output binaries are put by visual studio in the directory 'project\debug'. I've read a few questions on here that have ignore lists for Visual Studio but most of them have an ignore list that ignores the binary files, like the obj exe idb pdb ilk etc.
If I want to be able to debug my exe in the future what files do I need to keep? Is there any reason to keep the obj files? Does VS use them at all during debugging or tracing a crash? I thought I should keep at least the the pdb files and the exe. So that would be project.exe, project.pdb and vc100.pdb. But what about vc100.idb, project.ilk, project.res... etc. Is there an ignore list that will ignore everything that isn't needed to keep binary builds but keep everything that is?
I want to make sure if a user sends me a crash dump or reports a problem at some point in the future that I can go back to the version that was being used and be able to debug it. I had also hoped to make the binaries and debug files available in a remote repo so that anyone else could as well. Thanks!
Don't keep binaries in version control. Instead, build from source.
Since the binaries are built from source, and you have the source versioned already, just re-build the particular version as-needed. It will both keep your version control system lean and fast, as well as not cause merge headaches (which binaries are notorious for).
So, the answer is don't keep any binaries in version control.
If you feel you really must keep them, however, then just zip them up and store them like normal files using the tag of the build they came from.
I'm going to keep project.exe and project.pdb in the branch. The other files like *.obj, *.ilk, and *.sdf are not needed. Neither are the vc100.* files. I made my decision after speaking to a number of people in person and reviewing this:
File Types Created for Visual C++ Projects
and this:
Which Visual C++ file types should be committed to version control?
Although that SO question/answer does not answer my question it gave me a lot of good information. I also looked through my project.pdb for all the file references to confirm which files in my project that I needed to keep around. I used this command from the debugging tools for windows:
srcsrv\srctool -r project.pdb
I am using visual Studio 2010, trying to build a big solution having many VC++ projects converted from older Visual Studio builds.
The problem is, it gives me this LNK1181 for the 'root' project of the solution (the project on which all other projects are dependent) but only in DEBUG mode (win32). In release mode, it does not give me this error.
I noticed that this obj file is actually not created at all when in debug mode. Though the compiler doesn't give any error when it is building that cpp file.
What could be the problem? Is it related to those property manager sheets too somehow or something else?
The project is downloaded from our Source Control System directly, and works fine on other machines so there is something wrong on mine :(.
Click on solution.
goto Build menu and clean the solution and again build the solution hopefully this action sove your issue
You probably solved this a long time ago, but when I had this exact issue, removing the source files used to create the object from the project and then re-adding them as existing items fixed the issue. Of course, this doesn't change the fact that you're using project/solution files from your repo that other people are using without issue, which is odd.
For what it's worth, I had accidentally added *.obj files to the project, and so it was throwing this error.
When I build a release version of a project in Visual Studio 2008, it creates a .pdb file, e.g. for a simple WPF project it generates a .exe and .pdb file.
I've always understood .pdb files to be for debugging, so I would expect them to be in the Debug folder but not the Release folder.
And looking around at other StackOverflow questions, it doesn't seem that pdb files work well with teh Release version anyway.
Why are .pdb files generated in the Release folder by default and how can I turn that option off?
You are right. PDB files are for debugging but you may need to debug release builds too. Saving PDBs of released builds is very important when you want to debug a customer issue and you have the crash dump file related to that issue.
By the way, generating PDB files does not harm compiler optimizations. If you don't ship it to the customer, there will be no performance implications.
It depends on the project settings. Just happens that in Release version a .pdb is also generated by default. It will not hurt you - just don't ship it to the customer.
To skip its creation go to Linker->Debugging in project settings and set "Generate Debug Info" to "No".
I asked a similar question a while ago Error Creating Debug Information - Code Won't Compile but never found a solution.
That problem seems to have evolved a bit. Now Visual Studio is creating a PDB debug file even when the application is in Release mode and debugging is turned off in Web.config. This PDB file is getting locked by Visual Studio and sometimes w3wp.exe. Compiling fails saying the PDB file is in use by another process (devenv.exe, w3wp.exe, or both). I cannot compile until I use Unlocker to release all the locks.
First off why is VS creating a debug file when in release mode?
Secondly how can I fix this? I have run a repair install on VS and re registered ASP.Net with IIS but that didn't help. I am using Windows Server 2003, VS 2008 Standard, and IIS6.
The first symptoms showed up a week or two ago when I was working on a WPF application. Until today putting the project in Release mode made the problem go away. Now it is happening even in Release mode.
Any ideas?
PDB files are created for release builds too - that is by design so you can still debug crashes in a release binary.
The PDB file is certainly not required for running. However, if it is in the same directory as the binary being run, IIS may be loading it (not really sure what IIS does here though). You can copy the binaries to a different folder (minus the PDB files) to prevent this problem.
Did you try this: http://callicode.com/Homeltpagegt/tabid/38/EntryId/24/How-to-disable-pdb-generation-in-Visual-Studio-2008.aspx?
You can also add custom after-build event to release configuration to delete the pdb file if everything else fails.