I work with very old project which was written in visual studio 2008. I have directories with .cpp files, .h files etc.
The problem is that, they deleted vsproj and sln files, and put Makefile which will compile the project.
So i compiled the project using Cygwin, and now i have also PDB file and an EXE file.
Now, i want to add features to that project. And compile it. But i dont know how to debug it!
So my friend told that all i need is a Pdb file. Ok, so i have a pdb file, but what next? I googled and didnt find clear tutorial or explanation how to do this.
I understood that VS2008 need pdb file to debug. But i havnt vsproj, or sln so i cant press F5 to debug.
I tried "attach to process", but didnt help me.
Please! How to debug with pdb when you cant open a "Solution of project"?
I have a *.dmp (dump) file of my crashed application. Now, I want to analyze the crashed process on a different machine. That is, the app crashed on one machine, and I have Visual Studio on other machine.
Now, what do I need to be able to see stack trace and all symbols of my app? Is *.exe file and the *.dmp file sufficient?
Or do I need also the source code and PDB file?
If so, should the source code and executable file be placed in the same directories structure as it is on the machine the process was running?
How to attach PDB file to crash dump file in Visual Studio?
No, you definitely need the .pdb files to get decent stack traces. By far the simplest way is to do this from the machine on which you built the program, the source code and .pdb files will be in the right place.
Next best thing is to copy the exact same executables into the exact same folder in which it was installed on the failing machine. Copy the .pdb files into that same directory, that's where the debugger looks next if it can't find them in the original build location. Once the debugger lands on a statement with source code and the .pdb wasn't stripped then it will prompt you to give the source code file location.
Next best thing is Tools + Options, Debugging, Symbols and add the path to the directory that contains the .pdb files.
In that same dialog, also turn on the Microsoft Symbol Server (http://msdl.microsoft.com/download/symbols). That gets you the symbols for the Windows DLLs and lets you accurately trace back to your own code if the crash occurred in a Windows DLL.
I create a DLL project with Visual Studio 2010. When I open my_project.dll with Notepad, I find project's path (eg. D:\Solutions\my_project\my_project_1\lib\Release\my_project.pdb)
My boss want to remove any private information about the project.
How to remove private information while creating an executable/DLL file?
Have a look at PDB Files: What Every Developer Must Know.
Anyways, you can use the /PDBALTPATH (Use Alternate PDB Path) to remove the path to the PDB file.
I'm trying to remote debug my webpart. I can successfully attach to the remote process but my breakpoints do not load. Can anyone help me?
PS I've checked the "modules" but my assembly is not loaded there.
PPS My .dll is GAC deployed and I am the admin of both the dev and server.
PPS The .pdb files are on the bin folder of the application: inetpub/.../9090/bin
I was wondering if I can force the "modules" to load a given .dll. Is it?
Is debugging enabled in the web.config of the target web application?
http://msdn.microsoft.com/en-us/library/e8z01xdh%28v=vs.80%29.aspx
UPDATE
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx
The section on PDB loading says:
The first place searched is the directory where the binary was loaded.
If the PDB file is not there, the
second place the debugger looks is the
hard coded build directory embedded in
the Debug Directories in the PE
file.If the PDB file is not in the
first two locations, and a Symbol
Server is set up for the on the
machine, the debugger looks in the
Symbol Server cache directory.
Finally, if the debugger does not find
the PDB file in the Symbol Server
cache directory, it looks in the
Symbol Server itself.
You need to move the PDB into the same folder in the GAC, or into the same path that you built the assembly from.
Use this method to enable viewing the GAC folders
http://blogs.msdn.com/b/johnwpowell/archive/2009/01/14/how-to-copy-an-assembly-from-the-gac.aspx
I have a Visual Studio (2008) solution consisting of several projects, not all in the same namespace. When I build the solution, all the DLL files used by the top level project, TopProject, are copied into the TopProject\bin\debug folder. However, the corresponding .pdb files are only copied for some of the other projects. This is a pain, for example when using NDepend.
How does Visual Studio decide which .pdb files to copy into higher level bin\debug folders? How can I get Visual Studio to copy the others too?
References are as follows: all the DLL files are copied to a central location, without their PDB files. TopProject only has references to these copied DLL files; the DLL files themselves, however, evidently know where their PDB files are, and (most of them) get copied to the debug folder correctly.
From MSDN:
A program database (PDB) file holds
debugging and project state
information that allows incremental
linking of a Debug configuration of
your program. A PDB file is created
when you compile a C/C++ program with
/ZI or /Zi or a Visual
Basic/C#/JScript .NET program with
/debug.
So it looks like the "issue" here (for lack of a better word) is that some of your DLLs are being built in debug mode (and hence emitting PDB files), and some are being built in release mode (hence not emitting PDB files). If that's the case, it should be easy to fix -- go into each project and update its build settings. This would be the default scenario, if you haven't done any tweaking of command line options.
However, it will get trickier if that isn't the case. Maybe you're all in release or debug mode. Now you need to look at the command line compile options (specified in the project properties) for each project. Update them to /debug accordingly if you want the debugger, or remove it if you don't.
Edit in Response to Edit
Yes, the DLL files "know" that they have PDB files, and have paths to them, but that doesn't mean too much. Copying just DLL files to a given directory, as others have mentioned, won't clear this issue up. You need the PDB files as well.
Copying individual files in Windows, with the exception of certain "bundle"-type files (I don't know Microsoft's term for this, but "complete HTML packages" are the concept) doesn't copy associated files. DLL files aren't assembled in the "bundle" way, so copying them leaves their PDB file behind.
I'd say the only answer you're going to have is to update your process for getting the DLL files to those central locations, and include the PDB files ... I'd love to be proven wrong on that, though!
First off, never assume anything. Clean the solution, rebuild it in debug mode, and check to see if all PDB files are created. If not, that's your problem.
If they are created, and they're not all getting copied, you can get around this by creating a post build event that manually copies the PDB files to the desired locations. This is just a workaround, of course.
The only other thing I can think of is that your solution file has become corrupt. You can open your .sln as an XML file and examine the contents. Check the configuration for the projects that are acting as expected and compare them to those that aren't. If you don't see anything, you have to repeat this at the project level. Compare working .csproj (or whatever) project files and the non-working ones.
Edit in response to edit:
If you're just manually copying stuff around, then manually copy the PDF files as well. DLL files shouldn't "know" anything about PDB files, I believe. Just stick them in the destination directory and go have a cup of coffee. Relax.
Check when you clean the solution, that it is actually cleaned.
I've seen Visual Studio leave files hanging around in bin\debug directories even after cleaning. Delete the bin\debug directory on all of your projects and rebuild.
As other posts have said, you may have a compiler/corruption issue.
But, as Will said, if the PDB files are being created, but not showing up where you want them, create a post-build step. Here is the post-build step I define for every project in my solution. It makes sure all output files are copied into a common directory.
If your project file is in \SolutionDir\ProjDir, then the first line of the post-build step will copy the output files to \Solution\Bin\Release or \Solution\Bin\Debug. The second line copies the PDB file if this is a debug build. I don't copy the PDB file for release builds.
So, \SolutionDir\Bin now contains all your output files in one location.
xcopy /r /y $(TargetPath) $(ProjectDir)..\$(OutDir)
if $(ConfigurationName) == Debug xcopy /r /y $(TargetDir)$(TargetName).pdb $(ProjectDir)..\$(OutDir)